Received-SPF: pass (google.com: domain of linux-kernel+bounces-70112-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Sat, 17 Feb 2024 17:54:19 -0500
From: Kent Overstreet <kent.overstreet@linux.dev>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, 
	lsf-pc@lists.linux-foundation.org
Subject: Re: [LSF TOPIC] beyond uidmapping, & towards a better security model
Message-ID: <7gcfxbtwrylgamcbcnft37atyo34vqvbkxr2fp3k26le7vblob@ncqr7dopb2qk>
References: <tixdzlcmitz2kvyamswcpnydeypunkify5aifsmfihpecvat7d@pmgcepiilpi6>
 <ZdEzwTrJV-aQ1CqV@casper.infradead.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZdEzwTrJV-aQ1CqV@casper.infradead.org>

On Sat, Feb 17, 2024 at 10:31:29PM +0000, Matthew Wilcox wrote:
> On Sat, Feb 17, 2024 at 03:56:40PM -0500, Kent Overstreet wrote:
> > AKA - integer identifiers considered harmful
> 
> Sure, but how far are you willing to take this?  You've recently been
> complaining about inode numbers:
> https://lore.kernel.org/linux-fsdevel/20231211233231.oiazgkqs7yahruuw@moria.home.lan/
> 
> > 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'.
> 
> Waitwaitwait.  You start out saying "they are paths" and then you use
> '.' as the path separator.  I mean, I come from a tradition that *does*
> use '.' as the path separator (RISC OS, from Acorn DFS, which I believe
> was influenced by the Phoenix command interpreter), but Unix tends to
> use / as the separator.

To me, / indicates that it's a filesystem object, which these are not.
Languages tend to use : as the path separator for object namespacing -
heirarchical paths, but not filesystem paths.

> One of the critical things about plan9 that means you have to think
> hard before transposing its ideas to Linux is that it doesn't have suid
> programs.  So if I create willy/root, it's essential that a program
> which is suid only becomes suid with respect to other programs inside
> willy's domain.  And it doesn't just apply to filesystem things, but
> "can I send signals" and dozens of other things.  So there's a lot
> to be fleshed out here.

My proposal is that a user is superuser only over direct sub-users; so
in your example, willy.root would only be superuser over willy.root.*;
it's just your normal willy user that's superuser over all your
sub-users.

That means that our 'root' user doesn't fit with this scheme - the
superuser over the whole system would be the "" user.

Or perhaps we just map our existing users to be sub-users of root?

root
root.willy
root.kent?

User namespacing in this scheme just becomes "prepend this username when
leaving the namespace", so this might actually work; bit odd in that in
this scheme there's nothing implicitly special about the 'root'
username, so that becomes a (mild) wart... easily addressed with
capabilities, though.