Received-SPF: pass (google.com: domain of linux-kernel+bounces-71475-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <141b4c7ecda2a8c064586d064b8d1476d8de3617.camel@HansenPartnership.com>
Subject: Re: [LSF TOPIC] beyond uidmapping, & towards a better security model
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Kent Overstreet <kent.overstreet@linux.dev>, 
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, 
	lsf-pc@lists.linux-foundation.org
Cc: Christian Brauner <christian@brauner.io>, =?ISO-8859-1?Q?St=E9phane?=
	Graber <stgraber@stgraber.org>
Date: Mon, 19 Feb 2024 09:26:25 -0500
In-Reply-To: <tixdzlcmitz2kvyamswcpnydeypunkify5aifsmfihpecvat7d@pmgcepiilpi6>
References: 
	<tixdzlcmitz2kvyamswcpnydeypunkify5aifsmfihpecvat7d@pmgcepiilpi6>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

On Sat, 2024-02-17 at 15:56 -0500, Kent Overstreet wrote:
> AKA - integer identifiers considered harmful
> 
> Any time you've got a namespace that's just integers, if you ever end
> up needing to subdivide it you're going to have a bad time.
> 
> This comes up all over the place - for another example, consider
> ioctl numbering, where keeping them organized and collision free is a
> major headache.
> 
> For UIDs, we need to be able to subdivide the UID namespace for e.g.
> containers and mounting filesystems as an unprivileged user - but
> since we just have an integer identifier, this requires complicated
> remapping and updating and maintaining a global table.
> 
> Subdividing a UID to create new permissions domains should be a
> cheap, easy operation, and it's not.
> 
> The solution (originally from plan9, of course) is - UIDs shouldn't
> be numbers, they should be strings; and additionally, the strings
> should be paths.
> 
> Then, if 'alice' is a user, 'alice.foo' and 'alice.bar' would be
> subusers, created by alice without any privileged operations or
> mucking with outside system state, and 'alice' would be superuser
> w.r.t. 'alice.foo' and 'alice.bar'.
> 
> What's this get us?

I would have to say that changing kuid for a string doesn't really buy
us anything except a load of complexity for no very real gain. 
However, since the current kuid is u32 and exposed uid is u16 and there
is already a proposal to make use of this somewhat in the way you
envision, there might be a possibility to re-express kuid as an array
of u16s without much disruption.  Each adjacent pair could represent
the owner at the top and the userns assigned uid underneath.  That
would neatly solve the nesting problem the current upper 16 bits
proposal has.

However, neither proposal would get us out of the problem of mount
mapping because we'd have to keep the filesystem permission check on
the owning uid unless told otherwise.

> Much better, easier to use sandboxing - and maybe we can kill off a
> _whole_ lot of other stuff, too. 
> 
> Apparmour and selinux are fundamentally just about sandboxing
> programs so they can't own everything owned by the user they're run
> by.
> 
> But if we have an easy way to say "exec this program as a subuser of
> the current user..."
> 
> Then we can control what that program can access with just our
> existing UNIX permission and acls.
> 
> This would be a pretty radical change, and there's a number of things
> to explore - lots of brainstorming to do.
> 
>  - How can we do this without breaking absolutely everything?
> Obviously,
>    any syscalls that communicate in terms of UIDs and GIDs are a
>    problem; can we come up with a compat layer so that most stuff
> more
>    or less still works?
> 
>  - How can we do this a way that's the most orthogonal, that gets us
> the
>    most bang for our buck? How can we kill off as much security model
>    stupidity as possible? How can we make sandboxing _dead easy_ for
> new
>    applications?

So all of the above could be covered by a u16 kuid array with the last
element exposed to the user as the uid.  However, there are still
problems even with that approach: the unmapped uid/gid is something
some containers rely on and, as I said above, the mount mapping still
would have to be admin assigned.

James