Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752798AbbKJMky (ORCPT <rfc822;w@1wt.eu>);
	Tue, 10 Nov 2015 07:40:54 -0500
Received: from imap.thunk.org ([74.207.234.97]:51958 "EHLO imap.thunk.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751757AbbKJMkw (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 10 Nov 2015 07:40:52 -0500
Date: Tue, 10 Nov 2015 07:40:43 -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] Re: [KERNEL] Re: Kernel 4.3 breaks
 security in systems  using capabilities
Message-ID: <20151110124043.GC3717@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: <20151106155303.GB6160@thunk.org>
 <20151106175619.GA19491@ikki.ethgen.ch>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151110115526.GA2958@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: 2465
Lines: 53

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.

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

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.

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.  Or maybe adding a new securebit which disables
ambient capabilities.  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.

C2 by 92!

						- Ted

P.S.  What's C2 by 92?  The only government mandate that was less
successful than GOSIP.  :-)  See
https://freedom-to-tinker.com/blog/felten/stupidest-infotech-policy-contest/#comment-15049
for more details.
--
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/