linux-kernel - Re: [LSF TOPIC] beyond uidmapping, & towards a better security model

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 17 Feb 2024 17:54:19 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Matthew Wilcox <willy@...radead.org>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	lsf-pc@...ts.linux-foundation.org
Subject: Re: [LSF TOPIC] beyond uidmapping, & towards a better security model

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.