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

[Austin S Hemmelgarn]

On 2015-01-30 14:48, 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:
> > > > A few K here, a few K there, and pretty soon you actually fit into the
> > > > small-memory 32-bit SoCs.  I do not believe that the processing time
> > > > is the issue.
> > > And UNIX, with UID and GID processing, used to run in 64K of RAM,
> > > without swap or paging. Bluntly, there are many other places to look
> > > before you go here.
> > And we're looking in all those places too.  Each patch is worth
> > evaluating independently.  We've *already* gone here, the code is
> > written (and being revised based on feedback), and "go work over there
> > out of my backyard" is not going to work.  One of these days, we're
> > going to run in 64k again.
>
> Oh good heavens. Don't take this personally. I don't.
>
> > > > > 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?
>
> > > > > 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?

Because there are weird people out there who want to do embedded 
development in Python, and insane people out there who want to do it in 
Perl, and people who want to do real-time stuff but can't for some 
reason learn to use something sensible for that like RTEMS or FreeRTOS.

Also, Linux isn't as crazy as some other choices.  Many ATM's and cash 
registers (at least in the US) run Windows with all of the software 
running with administrator privileges , and I've seen my fair share of 
minimalistic systems running DOS.  While Linux may not be the _best_ 
choice for such use cases, it by far is not the worst.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature