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

From: Klaus Ethgen
Date: Sat Nov 07 2015 - 06:03:01 EST

Hash: SHA512

Hi Guys,

Am Fr den 6. Nov 2015 um 19:18 schrieb Serge E. Hallyn:
> On Fri, Nov 06, 2015 at 06:56:20PM +0100, Klaus Ethgen wrote:
> > Am Fr den 6. Nov 2015 um 16:53 schrieb Theodore Ts'o:
> > > In the light of that, using things like ambient capabilities, or using
> > > setuid binary that immediately drops all caps that it needs, is
> > > probably the best we're going to get.
> >
> > I do never want that! Even to think about such a way to give any shell
> > raised rights is horrible! And that horrible idea is it that makes all
> > the ambient capabilities that bad.
> I sympathize with your point of view, but Christoph's use case really was
> a good one.

I don't think so. Read on...

> 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.

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.

> 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.

- --
Klaus Ethgen
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <Klaus@xxxxxxxxx>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
Version: GnuPG v1

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at