Date:	Fri, 30 Jan 2015 13:04:28 -0800
From:	Josh Triplett <josh@...htriplett.org>
To:	Casey Schaufler <casey@...aufler-ca.com>
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>
Subject: Re: [PATCH v2] kernel: Conditionally support non-root users, groups
 and capabilities

On Thu, Jan 29, 2015 at 06:05:53PM -0800, Casey Schaufler wrote:
> 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.

I recall those same discussions when they happened; the portions of the
discussion I saw were less concerned about the ability to turn *off* the
security model, and more concerned that you could entirely *replace* the
UNIX security model with something more complex that could grant
permissions where you thought you'd denied them.

Referencing one of the mails from that discussion
(http://lwn.net/2001/1108/a/cs-hooks.php3 , which for the record I
entirely agree with your position and arguments in), the three concerns
expressed against authoritative LSM hooks were:
>    1. It is more invasive.
>    2. It increases the likelihood that modules can accidentally
>       undermine the base logic.
>    3. It increases the likelihood that the LSM patch will introduce an
>       error into the base kernel.

1) This patch is far less invasive.
2) There's no "accidentally" here; this is a config option to
   *intentionally* turn off the base logic.
3) Again, this patch is much simpler, single-purpose, and easier to
   review.

So, by all means, let's have this discussion again, but let's not frame
it in the context of authoritative versus restrictive LSM hooks, which
is an entirely different argument.

> > 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.

This is a configuration option in the middle of the "potential
application compatibility problems" menu, also known as CONFIG_EXPERT.
Any and all options there can and will disable parts of core kernel
functionality.  This option is intended to support purpose-built
applications that know full well what they're getting themselves into by
turning it off.

> > 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.

We've successfully booted kernels and simple userspaces with this patch
in qemu.  The userspace environment for this kind of kernel would
typically have init=/application, little to no filesystem, likely a
read-only filesystem if any, and reboot-on-panic as an application
supervision mechanism.

> >> 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.

I would hate to see that too.  Distributions know better than to enable
this kind of option in a distro kernel; give them a little credit.  So,
someone using this option will have to manually build a kernel with this
option intentionally disabled.  This option isn't a loaded and
pre-pointed footgun; it would take non-trivial effort to shoot yourself
in the foot with it.

And, in fact, any normal distribution will fail to work out of the box
with this option disabled, making it even more difficult to misuse.  If
you could switch to another user ID, but then that user ID was still
root-equivalent, that would be quite dangerous; here, any attempt to
switch to a non-root user ID (or group ID, or reduced set of
capabilities) will fail up front with ENOSYS.

- 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