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

From: Klaus Ethgen
Date: Fri Nov 06 2015 - 08:58:47 EST

Hash: SHA512


Am Do den 5. Nov 2015 um 23:08 schrieb Serge E. Hallyn:
> On Thu, Nov 05, 2015 at 11:01:07AM -0800, Andy Lutomirski wrote:
> > On Thu, Nov 5, 2015 at 9:48 AM, Klaus Ethgen <Klaus+lkml@xxxxxxxxx> wrote:
> > > Hash: SHA512
> > >
> > > Am Do den 5. Nov 2015 um 18:34 schrieb Serge E. Hallyn:
> > >> > Am Do den 5. Nov 2015 um 17:15 schrieb Serge E. Hallyn:
> > >> > > I think if you follow your idea to its logical conclusions, you end
> > >> > > up wanting set SECURE_ALL_BITS | SECURE_ALL_LOCKS, which will include
> > >> > > SECURE_NO_CAP_AMBIENT_RAISE, disabling ambient capabilities.
> > >> >
> > >> > That I did miss out and seems to be the solution for the problem. So
> > >> > adding cap_secure_all_bits,cap_secure_all_locks=ep to every binary that
> > >> > gets other caps should solve it?
> > >>
> > >> No that doesn't work, you have to use prctl to set those bits. If you
> > >> can get your system to be fully rootless, you can have init or initramfs
> > >> do this for you. It'll mean that root and setuid-root binaries have no
> > >> automatic privileges beside owning host (proc/sys) files.
> > >
> > > So this is not helping much. But for me it is at least an idea to how to
> > > have abient capabilities _and_ full control for admin. It would be an
> > > un-capability but at least would allow the admin to change the
> > > behaviour.
> > >
> > > Another one, that would be much better would be something like
> > > cap_ambient_cap capability to explicitly allow the use of ambient
> > > capabilities.
> > >
> > > I have to say that I do not know much about prctl. Just reading the man
> > > page currently. But this seems to be about the second way of taking away
> > > rights from UID 0 instead of explicitly giving rights to selective
> > > binaries.
> Not exactly. It's restoring the full unadulterated use of posix
> capabilities.

- -v

> > OK, everyone, take a deep breath please.
> >
> > Somewhere very high up on my personal list of generally applicable
> > security advice: do not turn security knobs for the warm fully
> > feelings. Let me repeat that in all caps: DO NOT TURN SECURITY KNOBS
> >
> > When a whole bunch of us designed and iterated on how ambient caps
> > would work, we were very careful that they would *not* break
> > pre-existing assumptions that SUID programs could make.

I never talked about capabilities _and_ SUID, I always talked about
capabilities _instead_ of SUID. I want to get rid of the SUIDs.

> > Securebits
> > are very different: they very much do break pre-existing assumptions.
> ... thought i was clear about that.

What I read about, that ist clear for me too.

> > See, for example, CVE-2014-3215 [1], which is a local privilege
> > escalation made possible a because setuid binary turned security knobs
> > for the warm fuzzy feelings.

Hmm.. That is exactly what I fear about ambient capabilities too. Maybe
I am a bit more paranoid than the author of ambient capabilities but I
droved good with that paranoia level in the past.

> > So, no, barring a really good reason and a very convincing argument
> > about why it would be safe, I won't ack any attempt to add xattr knobs
> > to change privilege evolution rules like that. If you really want to
> > turn knobs to make your system feel safer and be safe at the same
> > time, please learn exactly what all the knobs do first and, while
> > you're at it, please think carefully about how they interact.

Well, I think I have a good understanding about capabilities. I just
think that we talk at cross purposes.

I never ever talked about using capabilities in _combination_ with SUID.
That was brought to the line by others and, how I read the patch that
brought ambient capabilities in, the main reason for it.

But that left out completely the, I think more important, usecase of
_removing_ SUID completely and _replacing_ it with very tight capability
setting. And that is what I always talked about.

I did not know about that "security bits", shame on me. But I do not
think that they are any kind of solution for the problem that ambient
capabilities brought into the kernel. Nor do I think that they change
any about the second usecase I always talked about.

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