Re: [PATCH v2] kernel: Conditionally support non-root users, groups and capabilities

[Josh Triplett]

On Fri, Jan 30, 2015 at 11:48:04AM -0800, Casey Schaufler wrote:
> On 1/30/2015 11:13 AM, josh@xxxxxxxxxxxxxxxx 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/