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

[Klaus Ethgen]

  Hi Ted, hy others in this discussion,

Am Di den 10. Nov 2015 um 13:40 schrieb Theodore Ts'o:
> On Tue, Nov 10, 2015 at 12:55:27PM +0100, Klaus Ethgen wrote:
> > > You can tell other people that they write privileged programs in the
> > > wrong programming language if you like.
> > 
> > Hey, it is not about programming languages. I never said something in
> > that direction!
> > 
> > I brought python programs for a bad example in programming and how
> > developers work. But that example can be made in any language. Moreover,
> > as python is a script language, I would not like it at all, having any
> > raised capabilities. And that is also valid for perl that I like much
> > more.
> 
> And that's the fundamenal problem.  Saying that you can only be secure
> if **no** scripting languages can be used for **any** privileged
> operations is something that _might_ work for you, but it doesn't work
> for the 99.99999999999% of the Linux systems out there, many of which
> have shell scripts to configure networking, or any host of other
> things.  Arguably, it's why Posix capalities have utterly failed as
> far as usage except for a very, very, very, tiny, limited market.

But this is use case 1 of two that I described earlier. And this is the
main use case that is addressed by the ambient capabilities. I'm fine
with that. That is nothing that I would object.

What I want to get fixed is the second use case of capabilities that was
completely ignored by the design of ambient capabilities. It is about
_raising_ explicitly single capabilities for _unprivileged_
binaries/users.

> Scripting languages are just too fundamental to Unix and Linux
> systems.  And I while I won't speak for Linus here, I suspect this is
> one of the places where he'll tell you that this is a prime example of
> why many security people are crazy (or in his colorful language,
> M***** Monkeys).

Might be. I like his colorful language. ;-)

> You can, after all, simply make any computer 100% secure by the
> applied use of thermite --- but the computer won't be very useful
> afterwards.

That is true too. But I can try to make it as secure as possible.

> If you want to create a patch, my recommendation would be to do one
> that turns off ambient capabilities as a CONFIG option, and hide it
> under CONFIG_EXPERT.

Would be an approach. Another is to have a kernel command line switch.

> Or maybe adding a new securebit which disables ambient capabilities.

That already exists. But it is not workable for overall system than only
for user namespaces.

However, that two approaches have a big disadvantage that they also
disallow the first use case.

I attached a very simple patch to this mail that introduces a new
capability to enable ambient capabilities. It will not break use case
one but it will give the control back to the admin to control the raised
capabilities for unprivileged binaries and/or users.

However, it is a fast and minimal hack that I want to test before it
gets into any accepted kernel. Please see it as an request for approval.

I was surprised how easily capabilities can be implemented in a secure
way. So I do not expect any security problem from the patch. In fact, it
uses the same way as the securebit stuff to disable them.

> Whether or not that will be acceptable upstream, I don't know, mainly
> because I think a strong case can be made that such a patch has an
> audience of one, and adding more complexity here for an idea which has
> been time-tested over decades to be a failure is just not a good idea.

I wouldn't tell the implementation until now to be a failure. It helped
a lot to keep a system sane. It is true that all distributions ignored
capabilities completely but I don't think that is due the design.

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