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

[josh@joshtriplett.org]

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. 

So far that "longstanding position" consists of you griping that we're
not implementing authoritative LSM hooks for you and re-fighting that
battle for you.  Patches for authoritative LSM hooks did indeed get
refused long ago, which is an excellent reason for us to not recast this
patch to reimplement them that way.

If it does turn out that the security maintainers in the kernel are open
to the idea of authoritative LSM hooks, by all means I would encourage
you to revisit such hooks.  But there's a significant difference between
"add the ability to disable access controls" and "add a framework that
allows replacing the user/group security model with arbitrary access
controls", and it's not at all obvious that the "right" solution for the
former is an implementation of the latter; it also seems entirely
plausible that the kernel community remains opposed to the latter, which
does not necessarily rule out the former.

Given that, it would be helpful to hear feedback from more of the
community.

> 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 would expect that any security module would need to depend on NON_ROOT
(or MULTIUSER as v3 may end up calling it, per Geert Uytterhoeven's
suggestion).  A kernel configuration with this option turned off
intentionally does not *have* user/group access controls.  The intent of
this option isn't "turn standard access controls off so they get out of
the way of non-standard access controls"; the intent is "turn all access
controls off because there will never be unprivileged processes on this
system".

So, on that basis, it sounds like v3 should add a dependency from
SECURITY to MULTIUSER.

- Josh Triplett