Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities

From: Austin S Hemmelgarn
Date: Mon Nov 09 2015 - 14:03:12 EST

On 2015-11-09 12:23, Klaus Ethgen wrote:
Hash: SHA512

Am Mo den 9. Nov 2015 um 17:28 schrieb Austin S Hemmelgarn:
Having some scripts in the process is definitively a nightmare to
control. That should be prevented wherever possible. And usually it is
as the scripts might be used for computing some values that are used
later in privileged stuff.
It's still unavoidable in a number of cases. It's easy to re-write scripts
to fit any local configuration. It's not anywhere near as easy to re-write
a compiled program to account for any local configuration.

I would not only say that it is avoidable, it is the worst that can
Scripts will always be necessary unless you have a purpose built system that never gets updated or relocated, and never has any changes to the hardware (and guess what, you use scripts constantly if you use the command-line, option syntax and configuration files are technically domain-specific scripting languages).

Usually a shell is calling a binary to do the real work. So it should
even never ever needed to have some raised privileges for the shell.
Unless you need the binary to be run with some privileges and can't reasonably use capabilities on it (for example, it's a lot of work to maintain a system with no set{u,g}id binaries on it and keep the software up-to-date on it as well).

Good example are all that userspace python tools that throw all that
stack traces around the users ears (I don't know if that saying exists
in English...) instead of giving proper error messages.
This is debatable. While the app should be giving a user friendly error
message, getting a stack-trace and the exception name (and the exceptions
are usually sanely named) is still far better than just getting something
like 'Segmentation Fault', or just returning the error in the return code.
There is no added security from not providing the stack-trace because there
is no data leaked by it (it contains no information about the contents of
variables, and function names and included libraries can easily be seen by
just looking at the python program itself).

My pointing to that python problem is not about security then about how
lazy some developer are. And lazyness and security is nothing that can
go together.
That depends on what you mean by lazy. Scripts can't do core-dumps (there is no practical way to do a core-dump from a script and still be reasonably easy to debug), so they have to do something to provide data so developers can debug it. By having such things just dump a stacktrace, the developers are making it easier for stuff like ABRT and whatever Ubuntu uses for automated bug reporting to actually report things, which in turn makes handling bug reports more efficient (and a desire for efficiency is _not_ the same as being lazy).
By the way, guys, can we start to _not_ add every one in this discussion
to the Cc? Currently I get every mail twice. One from the list and one
>from Cc. I still leave all Ccs intact with this mail but I would prefer
to just reply to the list. If anybody is not reading the list and would
like to get the mail, please insist.
If you're getting duplicates with the same Message-ID header, then your
mail-server is (arguably) broken.

I do not know any mailserver that cares about message-ids. Even more,
which one is the original one if they differ in body? (as they do for
example in this list.)

It it even more broken as some (surely broken) MUAs reuse message ids.

It should be delivering exactly one copy of a message with a given
Message-ID: header (this is really a de-facto standard,

I wouldn't say so.
The Message-ID header is supposed to be unique for the lifetime of the message (which effectively means almost forever for stuff on LKML, as it's archived). If you are getting multiple copies of a message with the same Message-ID header and different content in the message, then something is very broken, and if a MUA is reusing Message-ID's, then someone needs to file a bug against that MUA.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature