Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752258AbbKKCEe (ORCPT <rfc822;w@1wt.eu>);
	Tue, 10 Nov 2015 21:04:34 -0500
Received: from imap.thunk.org ([74.207.234.97]:53210 "EHLO imap.thunk.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752219AbbKKCEb (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 10 Nov 2015 21:04:31 -0500
Date: Tue, 10 Nov 2015 21:04:20 -0500
From: "Theodore Ts'o" <tytso@mit.edu>
To: Andy Lutomirski <luto@amacapital.net>,
        Serge Hallyn <serge.hallyn@ubuntu.com>,
        Kees Cook <keescook@chromium.org>, Christoph Lameter <cl@linux.com>,
        "Serge E. Hallyn" <serge@hallyn.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Richard Weinberger <richard.weinberger@gmail.com>,
        Austin S Hemmelgarn <ahferroin7@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [KERNEL] [PATCH] Kernel 4.3 breaks  security in systems  using
 capabilities
Message-ID: <20151111020420.GD3717@thunk.org>
Mail-Followup-To: Theodore Ts'o <tytso@mit.edu>,
	Andy Lutomirski <luto@amacapital.net>,
	Serge Hallyn <serge.hallyn@ubuntu.com>,
	Kees Cook <keescook@chromium.org>, Christoph Lameter <cl@linux.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Richard Weinberger <richard.weinberger@gmail.com>,
	Austin S Hemmelgarn <ahferroin7@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
References: <20151106181820.GB16749@mail.hallyn.com>
 <20151107110246.GA7230@ikki.ethgen.ch>
 <5640C999.5050807@gmail.com>
 <20151109172340.GF3714@ikki.ethgen.ch>
 <5640EDB4.70407@gmail.com>
 <20151109212937.GA17624@ikki.ethgen.ch>
 <CALCETrUE5FwqtCBMq8+K6owwTn0vhdHjO0TzoMKhN6_vaNSRhw@mail.gmail.com>
 <20151110115526.GA2958@ikki.ethgen.ch>
 <20151110124043.GC3717@thunk.org>
 <20151110131907.GB2958@ikki.ethgen.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151110131907.GB2958@ikki.ethgen.ch>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3065
Lines: 57

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.

> 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.  That's a wierd thing to
both simultaneously trust and distrust.

After all, suppose you give some process CAP_DAC_OVERRIDE, so it can
read any file on the system.  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).  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).  Arguably, auditing this is much *less* effort than
making sure that the process isn't going to abuse CAP_DAC_OVERRIDE.


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

    	 			  	    - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/