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

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Thu, Jan 29, 2015 at 06:25:23PM -0800, Casey Schaufler wrote:
> On 1/29/2015 5:36 PM, Paul E. McKenney wrote:
> > On Thu, Jan 29, 2015 at 05:25:56PM -0800, Casey Schaufler wrote:
> >> On 1/29/2015 4:32 PM, Paul E. McKenney wrote:
> >>> On Thu, Jan 29, 2015 at 03:44:46PM -0800, Casey Schaufler wrote:
> >>>> On 1/29/2015 10:43 AM, Iulia Manda wrote:
> >>>>> There are a lot of embedded systems that run most or all of their functionality
> >>>>> in init, running as root:root. For these systems, supporting multiple users is
> >>>>> not necessary.
> >>>>>
> >>>>> This patch adds a new symbol, CONFIG_NON_ROOT, that makes support for non-root
> >>>>> users, non-root groups, and capabilities optional.
> >>>>>
> >>>>> When this symbol is not defined, UID and GID are zero in any possible case
> >>>>> and processes always have all capabilities.
> >>>>>
> >>>>> The following syscalls are compiled out: setuid, setregid, setgid,
> >>>>> setreuid, setresuid, getresuid, setresgid, getresgid, setgroups, getgroups,
> >>>>> setfsuid, setfsgid, capget, capset.
> >>>>>
> >>>>> Also, groups.c is compiled out completely.
> >>>>>
> >>>>> This change saves about 25 KB on a defconfig build.
> >>>>>
> >>>>> The kernel was booted in Qemu. All the common functionalities work. Adding
> >>>>> users/groups is not possible, failing with -ENOSYS.
> >>>>>
> >>>>> Bloat-o-meter output:
> >>>>> add/remove: 7/87 grow/shrink: 19/397 up/down: 1675/-26325 (-24650)
> >>>>>
> >>>>> Signed-off-by: Iulia Manda <iulia.manda21@gmail.com>
> >>>>> Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> >>>> v2 does nothing to address the longstanding position of
> >>>> the community that disabling the traditional user based
> >>>> access controls is unacceptable. 
> >>>>
> >>>> If the community has abandoned that position, and I see no
> >>>> reason to believe that is true, the correct implementation 
> >>>> is to rework the LSM from an additional controls model to
> >>>> an authoritative hook model.
> >>>>
> >>>> Speaking of the LSM, what is your expectation regarding the
> >>>> use of security modules in addition to "NON_ROOT"? Is it
> >>>> forbidden, allowed or encouraged?
> >>> I am guessing that people who remove uids and gids from their
> >>> kernels would tend not to add LSM.  From what I understand, these
> >>> kernels are designed for special-purpose applications that have
> >>> very limited and stylized interactions with the outside world.
> >>> Applications that, back in the day, would have been written to
> >>> run on bare metal without any OS whatsoever.
> >> Linux is still going to be too big for those applications. Taking
> >> the UID, GID and capability processing out is, at 25k, hardly significant.
> >> Yes, you'll save some processing time, but the benchmarks I've run in the
> >> dim dark past indicated that the impact is actually trivial. I would of
> >> course invite the advocates of this patch to produce numbers. No, if you
> >> are looking to switch from a RTOS to a Linux kernel, UID processing isn't
> >> going to be your first (second, or third) concern.
> > 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.

Even more bluntly, it is not me that you need to convince, and I would
expect them to be profoundly unimpressed by your interesting suggestion
that they drop back to BSD 2.8 and PDP11s.

> >> 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?
> >>
> >> 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, which is going to pull
> in all sorts of fun services that no one will want to maintain or change for the
> environment. Resulting in all sorts of security issues. It would be inappropriate
> for me to sit aside and let you go in that direction unwarned. I'm not going to
> try to stop you, because I know that's futile. Let me know what I can do to help
> when the time comes.

I have no idea what sort of application framework they will choose.
But of course, there will be all sorts of security issues no matter
what technology they choose.  After all, it is not like we are lacking
in security issues in the current non-Linux installed base.  Or in the
Linux installed base, for that matter.

							Thanx, Paul