Message-ID: <20151105101953.GA15293@ikki.ethgen.ch>
Date:	Thu, 5 Nov 2015 11:19:54 +0100
From:	Klaus Ethgen <Klaus+lkml@...gen.de>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Richard Weinberger <richard.weinberger@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Christoph Lameter <cl@...ux.com>,
	Andy Lutomirski <luto@...nel.org>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	Kees Cook <keescook@...omium.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems
 using capabilities

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

Hi,

sorry for the delay.

Am Mo den  2. Nov 2015 um 20:45 schrieb Andy Lutomirski:
> > 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.
> 
> That's true.  I don't see why it's a problem, given that the parent
> can already use or mis-use it however it wants, and the child won't
> get the capability without explicit action by the parent.

Well the parent can but usually is not aware of to what it gives this
ambient capabilities to.

Exactly here is the point. There are many applications out there that
needs to be SUID root. Many of them only cause the developer has
something inside like "if getuid() != 0". So in future I suspect many of
such tools that even don't need to give capabilities to childs, are
setting all available capabilities in ambient capabilities before
starting do do something.

With the present way, that was no problem (for OSS). You take away the
SUID, set the capabilities and if the tool complains about not being
root, look into the code and remove that stupid thing. With ambient
capabilities, no one will see that the tool is doing such stupid thing
as setting all capabilities unless some trouble is seen.

And I don't see that as hypothetical. I know many developer who are
misusing sudo as it is introduced by ubuntu by doing:
"sudo less /etc/hosts"
"sudo cd /bla"
"sudo ls"

and so on. Do you really expect such developer being sensitive to use
capabilities carefully? I don't. With the capabilities until now there
was a great tool for the admin to limit damage that can be done with
SUID by replacing it with proper capabilities. Now, with the new ambient
capabilities, that is again leveled. Now the admin looses many control
over what applications are allowed to do.

I know that distributions do not use capabilities at all. But admins
does; at least the ones who cares.

> >> 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.
> 
> That all sounds fine, except that, if you find a security flaw (in
> mount of all things -- mount really shouldn't be exposed to untrusted
> input in the first place, and if you find a flaw that lets you coerce
> mount into execing unrelated things, you can probably also coerce
> mount into acting directly on your behalf, but that's irrelevant
> here.)

Well, see above. I do not expect mount developer are that stupid. But
examples are fping or pmount.

> > With pA set (what can be even done in mount itself), the security
> > problem would be the same as havin mount SUID root.
> 
> No, the security problem would be the same as if you compromised
> whatever set pA in the first place.  In your example, that process (a)
> doesn't actually exist and (b) wouldn't have full root rights anyway.

Well, yes, not fully the same.

> > 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.
> 
> If your mount binary used prctl to set CAP_SYS_MOUNT in pA, then its
> children would have CAP_SYS_MOUNT.  Similarly, if your mount binary
> used, say, dlopen(), then the shared library would have CAP_SYS_MOUNT
> regardless of what the kernel did.

Yes, there is no solution for libraries. I have to admit that I was not
aware of it. But the solution could not be to level the problem to all
binaries. The solution would be to /maybe/ find a way for that too.
Although I do not know if that would be a good idea.

> So I still don't see the problem.

I hope I was able to show the problem above.

Nevertheless, I see that there are two usecases for capabilities. One to
remove SUID at all and set several capabilities explicitly as I do and
second the usecase you described in the commit.

But even your use case has oversees some thinks. It might be ok to
spread capabilities to clear defined processes that are aware of having
such capabilities. But at the latest when a shell is involved that might
proceed many initialisation scripts, the possible damage is
incalculable.

I can live with that ambient capabilities if it is selectable while
compiling the kernel (even then, distribution kernels might be
vulnerable). But overall it is a nightmare, I think.

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

iQGcBAEBCgAGBQJWOy1EAAoJEKZ8CrGAGfas9BgL/2jPL1EAI9PCnyRuqualPV4N
yYiw2eYyYma8p/gAiU90KhGmz9e4EUo/vLsaEl/pw1Tax5xkpzZncxa/LRXD7Qs6
o+/svhBG7ANlwnRqx5E71kTSPe5UDvsmn1DdOcLdN4x0jedxED6CKzO5QB7f5nxo
W9TvlPLCdeuW3dD78AaoSTNS+kleeAlko3Dq+EPYeQPgBdTtCNwbCKIiDympEj9g
MUGGALo6mH4RLhxgtQ7UKnsVZFCXV79YPXg3qtj/fdiuAbrKMsm0HnCz0/IxMydD
n+tFzwBh7hw0AKgKkvyFeSkvqGgQN0uQcUiwWvIIcGNrPJ2nNVSABhjM3SL7b5Up
F2nZesFJtdFLqsqzmIYu1W3+5yOwJ2Khicje3y6tU6Yehu3BDQsPPacwZYO05YLT
xCSQAIvINUigcCV2dIfZRDGU3ekXpRFhlDNVFfs38wtaHkuWTawnrWkrMQ8TqXBH
QJr63liAxlaj/5SFBmU0sDnR/fFYXIFlu9yVK7b0xw==
=A5kj
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists