Date:	Thu, 29 Jan 2015 18:05:53 -0800
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	josh@...htriplett.org
CC:	Iulia Manda <iulia.manda21@...il.com>, gnomes@...rguk.ukuu.org.uk,
	serge.hallyn@...onical.com, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, paulmck@...ux.vnet.ibm.com,
	peterz@...radead.org, mhocko@...e.cz,
	LSM <linux-security-module@...r.kernel.org>,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v2] kernel: Conditionally support non-root users, groups
 and capabilities

On 1/29/2015 4:43 PM, josh@...htriplett.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.manda21@...il.com>
>>> Reviewed-by: Josh Triplett <josh@...htriplett.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists