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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CANT5p=rqE5n6nyCs8pUWPaaj3=nasGKDOy9nV7_RDG04G0AzyA@mail.gmail.com>
Date: Thu, 29 Feb 2024 14:21:55 +0530
From: Shyam Prasad N <nspmangalore@...il.com>
To: NeilBrown <neilb@...e.de>
Cc: Matthew Wilcox <willy@...radead.org>, Kent Overstreet <kent.overstreet@...ux.dev>, 
	James Bottomley <James.Bottomley@...senpartnership.com>, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, lsf-pc@...ts.linux-foundation.org, 
	Christian Brauner <christian@...uner.io> ,Stéphane Graber <stgraber@...raber.org>, 
	Steve French <smfrench@...il.com>
Subject: Re: [LSF TOPIC] beyond uidmapping, & towards a better security model

On Wed, Feb 21, 2024 at 7:45 AM NeilBrown <neilb@...e.de> wrote:
>
> On Wed, 21 Feb 2024, Matthew Wilcox wrote:
> > On Tue, Feb 20, 2024 at 07:25:58PM -0500, Kent Overstreet wrote:
> > > But there's real advantages to getting rid of the string <-> integer
> > > identifier mapping and plumbing strings all the way through:
> > >
> > >  - creating a new sub-user can be done with nothing more than the new
> > >    username version of setuid(); IOW, we can start a new named subuser
> > >    for e.g. firefox without mucking with _any_ system state or tables
> > >
> > >  - sharing filesystems between machines is always a pita because
> > >    usernames might be the same but uids never are - let's kill that off,
> > >    please
> >
> > I feel like we need a bit of a survey of filesystems to see what is
> > already supported and what are desirable properties.  Block filesystems
> > are one thing, but network filesystems have been dealing with crap like
> > this for decades.  I don't have a good handle on who supports what at
> > this point.
>
> NFSv4 uses textual user and group names.  With have an "idmap" service
> which maps between name and number on each end.
> This is needed when krb5 is used as kerberos identities are names, not
> numbers.
>
> But in my (admittedly limited) experience, when krb5 isn't used (and
> probably also when it is), uids do match across the network.
> While the original NFSv4 didn't support it, and addendum allows
> usernames made entirely of digits to be treated as numerical uids, and
> that is what (almost) everyone uses.
>

This may not always be a fair assumption. In today's world, Linux
systems need to co-exist with other systems.
I would take an example of the Linux SMB, which in many ways is
similar to NFS in this context. The difference here is that the
servers (or clients) that we need to interact with deals with variable
length identifiers. Traditionally, it has been Windows SIDs. In more
recent terms, Azure identity service (Microsoft Entra) has moved on to
even more generic identifiers.

I actually agree with Kent on this point (on the ability to map UIDs
to variable length identifiers). We are making an assumption here that
there is a global numerical identifier that all identity providers
provide, and that it fits in 32 or 64 bit space, which may not always
be true. Linux SMB ecosystem (kernel SMB client/server, samba etc) is
having to map these identifiers in a lot of hacky ways. And I don't
think this problem is limited just to SMB filesystems.

Having native support in the kernel to at least map UID/GID to a
variable length identifier (using user namespaces) would really help.
Of course, it can be done in a backward-compatible way, where existing
systems can survive without any changes to their design.

> It is certainly useful to mount "my" files from some other machine and
> have them appear to have "my" uid locally which might be different from
> the remote uid.  I think when two different machines both have two or
> more particular users, it is extremely likely that a central uid data
> base will be in use (ldap?) and so all uids will match.  No mapping
> needed.
>
> (happy to be prove wrong...)
>
> NeilBrown
>
>
> >
> > As far as usernames being the same ... well, maybe.  I've been willy,
> > mrw103, wilma (twice!), mawilc01 and probably a bunch of others I don't
> > remember.  I don't think we'll ever get away from having a mapping
> > between different naming authorities.
> >
> >
>
>


-- 
Regards,
Shyam