Date:	Wed, 11 Nov 2015 11:14:34 +0100
From:	Klaus Ethgen <Klaus+lkml@...gen.de>
To:	Theodore Ts'o <tytso@....edu>,
	Andy Lutomirski <luto@...capital.net>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	Kees Cook <keescook@...omium.org>,
	Christoph Lameter <cl@...ux.com>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Richard Weinberger <richard.weinberger@...il.com>,
	Austin S Hemmelgarn <ahferroin7@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks  security in
 systems  using  capabilities

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

Am Mi den 11. Nov 2015 um  3:04 schrieb Theodore Ts'o:
> On Tue, Nov 10, 2015 at 02:19:08PM +0100, Klaus Ethgen wrote:
> > > 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.
> 
> Actually, you did.  To quote from an earlier message, "I would not
> only say that it [administrative shell scripts running with privilege]
> is avoidable, it is the worst that can happen."  That's a pretty
> strong objection in my book.  And it's why discussing thing with you
> is a bit frustrating.

Sorry, that I was misleading. I always told that in context of second
usecase. In the first usecase that is about reducing capabilities
instead of raising them, shells are already meant and used with all
rights.

The problem with shell scripts only (mostly) arise in the second
usecase.

I still keep my speaking that I will not object the first usecase.

> > 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.
> 
> That works fine with ambient capabilities.  You can raise a single
> capability with an unprivileged executable without any problems.  The
> problem is that you seem willing to trust that executable to have the
> capability via an fscap setting, and not misuse it.  *But* at the same
> time you don't trust that executable to take an explicit set to allow
> any of its children to use that executable.

Yes.

> That's a wierd thing to both simultaneously trust and distrust.

Particular, I trust nobody (not even myself sometimes). But giving
privileges is needed for some tasks. Ambient capabilities raise that to
a new level.

> After all, suppose you give some process CAP_DAC_OVERRIDE, so it can
> read any file on the system.

Particular, I would only give that capability (as the others) in
exchange to being SUID.

> How can you trust that it won't do
> anything bad with that power?  The only way you can do that is by
> carefully auditing the code to make sure it won't do anything untoward
> with that bit (either deliberately/maliciously or due to some
> programming bug).

Right. I do that from time to time. But unfortunately my time is
limited.

So keep in mind, I use capabilities to _limit_ rights to the lowest set
that former had have SUID bit set.

> If you are going to do that level of auditing, then
> you can also check to make sure it's not trying to explicitly
> manipulate the processes's capability mask to set the bit in the
> ambient capability mask (which is just another malicious use of the
> capability).

Well, you audit one version. What if the developer sees: "Oh, there is
one new shiny thing in kernel, called ambient capabilities. Lets set
them to all my capabilities. That looks great", after you audited the
code..?

> Arguably, auditing this is much *less* effort than
> making sure that the process isn't going to abuse CAP_DAC_OVERRIDE.

No, auditing is hard work. And I simply have not the manpower to do it
for every tool for every new version. As I believe, nobody has.

> As far as complaint that you can't set securebits for the entire
> system, sure you can.  Just move /sbin/init to /sbin/init.real, and
> replace /sbin/init with a program which sets
> SECURE_NO_CAP_AMBIENT_RAISE and SECURE_NO_CAP_AMBIENT_RAISE_LOCKED,
> and then exec's /sbin/init.real.  Done!  No kernel patch needed.  :-)

Yea, that could work. But it is far more hacky than doing it right in
the kernel.

However, a kernel patch brought in that, in my eyes, security mess.
There was already an additional patch on request of Andrew Morgan. I
believe he had good reasons for asking for this. However, I don't see
where my objection is less serious than his apart the fact that he is a
well known kernel hacker and I am just a paranoid nobody.

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

iQGcBAEBCgAGBQJWQxUEAAoJEKZ8CrGAGfasUtsL/jehWjS5u4IAUlOSGcoEM3zl
OJjA+Ez9CE6TGykkAwhJLlP3zmUsI/hn+09XNqSHFtezfycmp7tjRjWIsiNvb42Z
cMTpkUryBPpnOgrdZlr+YxmCyzO4jQs/5qly/MKBiR67GhquS0jlLKOWWRRT1Nkv
SpT8zEuGKB0O1SKY3FTKgSyxARA5eBNB4dqKYc7EFBYCWdPtYlOnDOMet+07dJp5
v7Acn506V0n30TztMQBIFovoX14yyT7nz/v3Td6yk6M7TxL8HXm2G4dDc2w/wPD7
msLEPTOS+WZ/M7DrYS8jIYwPGmW7as7FuOcPtjicGK9YBppEQJSygRHivxtUsD2b
TRrdD1TyPenPOWERg2DmbpHMyOyaydH09ZbE1EaMxYwW4yVHVUo5oMsjzQZNjvEJ
vv1ciZygaQe7c5uzVyMyHmrmuwtJn70tuPGB0boO4JnZgL6AvyVCqNyQ9aMU5OKc
OFvFdHxWnqiXHPjgBapevHVgUPKtTPV7q7vgUUyj7w==
=nf3o
-----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