lkml.org 
[lkml]   [2015]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Kernel 4.3 breaks security in systems using capabilities
From
Date
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).


[unhandled content-type:application/pkcs7-signature]
\
 
 \ /
  Last update: 2015-11-09 17:41    [W:0.442 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site