On 1/29/2015 4:43 PM, j...@joshtriplett.org 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.mand...@gmail.com> >>> Reviewed-by: Josh Triplett <j...@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.
The reason for bringing up authoritative hooks is that they allowed for a configuration like the one you have implemented. That fact was presented as an important reason why authoritative hooks could not be allowed. The point is not that I wanted authoritative hooks. The point is that the community opposed the very configuration you have implemented. I mention the authoritative hooks argument because that's where the issue was discussed. And if I felt sufficient strongly about bringing back authoritative hooks I wouldn't whinge to you about it. I'd go do it, and make a proper job of it. There are bigger and more important fish frying in the LSM community just now. > 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. My concern is that you've got a very specific configuration that is going to have all sort of application compatibility problems. I'm all for that as an experimental environment, but I don't think it's anywhere near ready or perhaps appropriate for upstream. > Given that, it would be helpful to hear feedback from more of the > community. Oh, I agree. I would also be curious about the user-space environment you hope to support with this kernel. >> 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". Pretty limiting, and completely inappropriate for any system that gets connected as a part of the Internet of Things. So I'm back to thinking that while this may be a fun experiment, it doesn't belong as a supported upstream configuration. I hate thinking of Ubuntu running on top of this kernel, but someone will want to try it, you can bet. > So, on that basis, it sounds like v3 should add a dependency from > SECURITY to MULTIUSER. Your goals, your call, of course. If it's not generally useful though ... > - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
