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

[Klaus Ethgen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

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

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

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

iQGcBAEBCgAGBQJWN7Z5AAoJEKZ8CrGAGfasHPcL/jmGC8tSMcxsSLnSB89rxEJf
CaWVwxw+zlhSzaXgLRoip7VaXFMnKEjOfigQ7gehKAqg1lu4aIDmEznHKbGq20Eo
o8FcXV7uqUlicEhmxLunYIjQeFWFip7JPvl1retbvOVsa1xqXVXXPOUZID+2e63S
DbKG1lG4jRGVatW6xjHjOY56AHN0hErnG1g3ONBAz9Ri5QwfxC0UhVlopfSYy13x
M20raMn0VedkJM4dbpOjGskakMij/5OmlY/t3tBiLBcFXS4JzQzkpYw2VJagLzfZ
9DDGIHA7+qTBWBDdy6ZEnR3QTbOozMUj0WBXa9dOukzLm+BtP6ik8v8DAdbdtJmx
6jn7WdMMXs4FpvmvT3y3MYeRm4Rn3qJNZTMe6b77RryzxLf5CIMTYW1rSr9bCRwp
te6bA7IKmGoKbD2Ge4n5PqFVpoVVVqZN0SPiW2dO/cDQ7WM+hb6yEeeYdBlO1gF4
Hw3oPeCLkm0+6R//dqeq1Q6mtIgYxL45Nxlvh4uhpg==
=qWwm
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/