From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752252AbbKKKyu (ORCPT <rfc822;w@1wt.eu>);
	Wed, 11 Nov 2015 05:54:50 -0500
Received: from imap.thunk.org ([74.207.234.97]:53726 "EHLO imap.thunk.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751059AbbKKKyt (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 11 Nov 2015 05:54:49 -0500
Date: Wed, 11 Nov 2015 05:54:41 -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] Re: [KERNEL] [PATCH] Kernel 4.3 breaks  security in
 systems  using  capabilities
Message-ID: <20151111105441.GA20241@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: <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>
 <20151111020420.GD3717@thunk.org>
 <20151111101433.GA16765@ikki.ethgen.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151111101433.GA16765@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

On Wed, Nov 11, 2015 at 11:14:34AM +0100, Klaus Ethgen wrote:
> > 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..?

But the developer can also change what files they look at; in fact,
they are *more* likely to make that kind of changes during the normal
course of development; not deliberately or maliciously, but as part of
adding a new feature to their program.  If you don't have time to
audit to make sure they aren't using some new capability feature
(which you can do using the simple application of "grep"), you don't
have time to audit to make sure they haven't changed something which
will cause their use of CAP_DAC_OVERRIDE to be dangerous.

Which is why I maintain it is very wierd that you are paranoid about
the first concern, but are blithely unconcerned about the second,
which is more likely.  And it is *because* you are the one who have
this extremely strange and selective paranoia, and most other people
won't, it seems fair (to me) that you are the one that has to pay the
extra cost of working around the problem.  After all, if you're this
paranoid, you must building all of your binaries from scratch, too.

(Or else you have to trust lots of package maintainers or distro
release engineers.  I'll remind you that some of the more catastrophic
security problems have come from Debian maintainers, some of which
made patches in code they didn't completely understand, and which had
nothing to do with elevated privileges.)  So the cost of patching init
to set the securebit should be in the noise for you.

Cheers,

						- Ted