Re: Kernel 4.3 breaks security in systems using capabilities

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3604 bytes --]

On 2015-11-07 06:02, Klaus Ethgen wrote:
> Am Fr den  6. Nov 2015 um 19:18 schrieb Serge E. Hallyn:
>> A piece of system configuration software needs to do some
>> networking setup with some privilege, including calling scripts.  It can
>> either do so as root or not at all - polluting every program that will end
>> up getting called with fI is not only ugly but simply doesn't work (because
>> scripts).  Saying that the whole thing must be written as self-contained
>> executable that never needs to be re-execed is frequently unrealistic.
>> So this allows a piece of software to run with reduce privilege, and it
>> is an improvement over the previous state of affairs.
>
> 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.
>
> However, that usecase has one more flaw I think. It is the human nature.
>
> Someone that create a tool made for running as root or especially SUID
> is usually careful to do so. If they know right now that the tool is
> never run as root, then they don't care about many thinks that needs to
> get addressed for root stuff.
>
> 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).
>
>> I would have been happy if there had been a default-off PR_ENABLE_AMBIENT
>> prctl which required a new CAP_ENABLE_AMBIENT capability to turn on, but
>> the current set of rules which removes bits from pA whenever doing an
>> action which capability-aware software does something which it would have
>> reasonably expected to drop privilege is a nice safeguard.
>
> Well, not really. You can only prevent ambient capabilities to be given
> to tools you don't want to have any capabilities by setting that tool
> SUID or setting just one random capability for it.
>
> 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.  It should be delivering exactly one 
copy of a message with a given Message-ID: header (this is really a 
de-facto standard, GMail, Yahoo, and most other mail-providers do this, 
as does Exchange.  Postfix does not, but it's pretty easy to work around 
with some filtering and procmail).



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]