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 <[email protected]> > > Reviewed-by: Josh Triplett <[email protected]> > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
