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

From: Klaus Ethgen
Date: Mon Nov 02 2015 - 14:16:30 EST

Hash: SHA512


Am Mo den 2. Nov 2015 um 19:50 schrieb Andy Lutomirski:
> >> I read recently about patch 58319057b7847667f0c9585b9de0e8932b0fdb08
> >> which made it into kernel 4.3 recently. And I have to say that I was
> >> shocked on how could such a patch that breaks normal use of capabilities
> >> make it into the kernel.
> >>
> >> Usually I have set very own crafted capabilities set to files instead of
> >> having them SUID root. With that, I have a comparable set of inheritable
> >> capabilities set for limited users. That allows me to nearly drop all
> >> SUID binaries and replace it by only giving the processes the
> >> capabilities they need but only if the users are allowed to act with
> >> that capabilities. Especially, and that is important, it inhibit any
> >> leak of rights to any forked process, be it indented or by a security
> >> problem of the binary.
> >>
> >> With the patch above, any process that is spawned by such a program will
> >> inherit the raised capabilities if it has no own filecapabilities set.
> >> Even worse, even every user made tool can be target for such
> >> escalations! That drives the benefits in security of capabilities over
> >> SUID ad-absurdum.
> Can you describe what it is that you think changed in 4.3 that breaks
> anything? The behavior of inheritable capabilities shouldn't have
> changed.

Well, the think that changed is that the ambient capabilities can be set
by any process if the pI and pE are matching for a process. But then,
that capabilities are inherited via execve to even programs that don't
have any capability setting. That allows every subprocess to (mis-)use

> >> Let me add here, that I disagree with Andy Lutomirski about the
> >> usefulness of capability inheritance in kernels before that patch. They
> >> was fully usefull to only allow selective capabilities if both, the
> >> binary and the user was allowed to use it. I never want to have any
> >> capabilities for processes that I did not allow them to have. Even
> >> worse, I never want any capabilities allowed for any shell. It is
> >> horrible to even think about such a possibility!.
> >>
> >>> Users with nonzero pA are unlikely to unintentionally leak that
> >>> capability. If they run programs that try to drop privileges, dropping
> >>> privileges will still work.
> >>
> >> Even that is naiv. There are only few programs out there that do
> >> actively drop privileges. Most are agnostic about capabilities. But this
> >> crappy patch introduce a need for _every_ tool to drop all capabilities
> >> right after start to stay in a secure system.
> >>
> I don't know what you mean. Concrete examples are welcome.

Am Mo den 2. Nov 2015 um 19:52 schrieb Linus Torvalds:
> >> With the patch above, any process that is spawned by such a program will
> >> inherit the raised capabilities if it has no own filecapabilities set.
> Do you actually have a real example of this?

Very simple example:
~> getcap =mount
/bin/mount = cap_dac_override,cap_sys_admin+ei
~> ls -l =mount
- -rwxr-xr-x 1 root root 40000 Sep 17 15:55 /bin/mount
~> getpcaps $$
Capabilities for `5509': = cap_dac_override,cap_net_raw,cap_sys_rawio,cap_sys_admin+i

What allows me to use mount for mounting shares with user flag without
the need of having a SUID mount. Nice and with a good security level.
Even if the binary has some flaw that allows to exec some unrelated
stuff, there is no harm as after execve, all capabilities are set to 0.
With the alternative approach of having /bin/mount SUID root (as it is
normally), root rights would spread to unrelated tools in such a case.

With pA set (what can be even done in mount itself), the security
problem would be the same as havin mount SUID root.

> The ambient capabilities stay empty unless you explicitly raise them.
> So your old workflow shouldn't actually have any change in it at all.

Ok, As I understand, that pA has to be set explicitly but that doesn't
prevent such problems. For example if someone has managed to break into
my account (in the example above), he can set it himself.

> And if your old workflow gave a capability to something you don't
> trust, and that then decides to now uses the ambient capabilities,
> what does that change? It had the capability already.

Well, not really. With the former approach, the capabilities in pI can
only be used with a specific tool that the admin allowed to inherit.
With pA, every tool can inherit that.

And please ask if I described something not understandable as my main
language is not english. I even might be wrong in understanding the pA.
but I don't think so currently.

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