From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763057AbbA3VkT (ORCPT ); Fri, 30 Jan 2015 16:40:19 -0500 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:55359 "EHLO relay4-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754549AbbA3VkR (ORCPT ); Fri, 30 Jan 2015 16:40:17 -0500 X-Originating-IP: 173.246.103.110 Date: Fri, 30 Jan 2015 13:40:07 -0800 From: Josh Triplett To: Casey Schaufler Cc: paulmck@linux.vnet.ibm.com, Iulia Manda , gnomes@lxorguk.ukuu.org.uk, serge.hallyn@canonical.com, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, peterz@infradead.org, mhocko@suse.cz, LSM Subject: Re: [PATCH v2] kernel: Conditionally support non-root users, groups and capabilities Message-ID: <20150130214007.GA2613@jtriplet-mobl1> References: <20150129184311.GA6404@winterfell> <54CAC5EE.8060107@schaufler-ca.com> <20150130003228.GJ19109@linux.vnet.ibm.com> <54CADDA4.4040602@schaufler-ca.com> <20150130013600.GM19109@linux.vnet.ibm.com> <54CAEB93.5090508@schaufler-ca.com> <20150130191302.GA19744@cloud> <54CBDFF4.1070503@schaufler-ca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54CBDFF4.1070503@schaufler-ca.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 30, 2015 at 11:48:04AM -0800, Casey Schaufler wrote: > On 1/30/2015 11:13 AM, josh@joshtriplett.org wrote: > > On Thu, Jan 29, 2015 at 06:25:23PM -0800, Casey Schaufler wrote: > >> On 1/29/2015 5:36 PM, Paul E. McKenney wrote: > >>> Casey Schaufler wrote: > >>>> As for LSMs, I can easily see putting in the security model from the old > >>>> RTOS on top of a NON_ROOT configuration. Won't that be fun when the CVEs > >>>> start to fly? > > The security model is "there's one process on this system". (Expect > > patches for CONFIG_FORK=n and CONFIG_EXEC=n at some point.) > > Ok. Why not use Bada? If you're asking about that particular OS: perhaps because it's proprietary, and also dead now (as of early 2013 according to Wikipedia)? From a quick look, it also looks much larger than desired. Leaving aside all the other reasons to not run a non-Linux OS, which I'd hope most people on these lists don't need much convincing of. More generally, why not run some random tiny RTOS? Because they're mostly proprietary, and not Linux, and with few exceptions don't live nearly as long as Linux, and don't have as many expert developers as Linux... > >>>> Do you think you'll be running system services like systemd on top of this? > >>>> Anyone *else* remember what happened when they put capability handling into > >>>> sendmail? > >>> Nope, I don't expect these systems to be using LSM, systemd, or sendmail. > >>> I think that many of these will instead run the application directly > >>> out of the init process. > >> Where an "application" might be something like CrossWalk, > > No, not a chance. If you're running a web runtime, you're on a much > > larger system, and you're going to be less concerned about shaving > > kilobytes; you're also going to want many of the kernel facilities for > > sandboxing code. > > > > The kinds of applications we're talking about here run entirely in one > > binary, serving a few very narrow functions. We're not talking > > "automobile IVI system" here; we're talking "two buttons and an output", > > or "a few sensors and an SD card". > > Linux is an insane choice for such a system. Why would you > even consider it? Linux was once an insane choice for supercomputers with thousands of CPUs. SMP support once had to be added, and it was significant enough to warrant bumping the major version number, back when that had significance. *Today*, Linux is a challenging choice for a tiny embedded system. We're trying to fix that. Why write yet another driver when Linux has one? Why reimplement code and risk rediscovering yet another bug Linux solved long ago? Why not use a system that scales, such that if you need more functionality, you can turn on a few more options without rewriting all your code for another environment? Why not use an OS that will definitely run on your next piece of hardware too, without needing a total rewrite? I would hope that I'm preaching to the choir here. Let's take a step back from the philosophy for a moment, and go back to reviewing code and patches. - Josh Triplett