Received-SPF: pass (google.com: domain of linux-kernel+bounces-70081-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Sat, 17 Feb 2024 15:56:40 -0500
From: Kent Overstreet <kent.overstreet@linux.dev>
To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, 
	lsf-pc@lists.linux-foundation.org
Subject: [LSF TOPIC] beyond uidmapping, & towards a better security model
Message-ID: <tixdzlcmitz2kvyamswcpnydeypunkify5aifsmfihpecvat7d@pmgcepiilpi6>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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?

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?

Cheers,
Kent