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

[Kent Overstreet]

On Thu, Feb 22, 2024 at 01:33:14AM +0100, James Bottomley wrote:
> On Wed, 2024-02-21 at 18:01 -0500, Kent Overstreet wrote:
> > Strings are just arrays of integers, and anyways this stuff would be
> > within helpers.
> 
> Length limits and comparisons are the problem

We'd be using qstrs for this, not c strings, so they really are
equivalent to arrays for this purpose.

> 
> > 
> > But what you're not seeing is the beauty and simplicity of killing
> > the mapping layer.
> 
> Well, that's the problem: you don't for certain use cases.  That's what
> I've been trying to explain.  For the fully unprivileged use case,
> sure, it all works (as does the upper 32 bits proposal or the integer
> array ... equally well.
> 
> Once you're representing to the userns contained entity they have a
> privileged admin that can write to the fsimage as an apparently
> privileged user then the problems begin.

In what sense?

If they're in a userns and all their mounts are username mapped, that's
completely fine from a userns POV; they can put a suid root binary into
the fs image but when they mount that suid root will be suid to the root
user of their userns.

> 
> > When usernames are strings all the way into the kernel, creating and
> > switching to a new user is a single syscall. You can't do that if
> > users are small integer identifiers to the kernel; you have to create
> > a new entry in /etc/passwd or some equivalent, and that is strictly
> > required in order to avoid collisions. Users also can't be ephemeral.
> > 
> > To sketch out an example of how this would work, say we've got a new
> > set_subuser() syscall and the username equivalent of chown().
> > 
> > Now if we want to run firefox as a subuser, giving it access only
> > .local/state/firefox, we'd do the following sequence of syscalls
> > within the start of the new firefox process:
> > 
> > mkdir(".local/state/firefox");
> > chown_subuser(".local/state/firefox", "firefox"); /* now owned by
> > $USER.firefox */
> > set_subuser("firefox");
> > 
> > If we want to guarantee uniqueness, we'd append a UUID to the
> > subusername for the chown_subuser() call, and then for subsequent
> > invocations read it with statx() (or subuser enabled equivalent) for
> > the set_subuser() call.
> > 
> > Now firefox is running in a sandbox, where it has no access to the
> > rest of your home directory - unless explicitly granted with normal
> > ACLs. And the sandbox requires no system configuration; rm -rfing the
> > .local/state/firefox directory cleans everything up.
> > 
> > And these trivially nest: Firefox itself wants to sandbox individual
> > tabs from each other, so firefox could run each sub-process as a
> > different subuser.
> > 
> > This is dead easy compared to what we've been doing.
> 
> The above is the unprivileged use case.  It works, but it's not all we
> have to support.

There is only one root user, in the sense of _actual_ root -
CAP_SYS_ADMIN and all that.
> 
> > > > > 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.
> > > > 
> > > > Not sure I follow?
> > > 
> > > Mounting a filesystem inside a userns can cause huge security
> > > problems if we map fs root to inner root without the admin blessing
> > > it.  Think of binding /bin into the userns and then altering one of
> > > the root owned binaries as inner root: if the permission check
> > > passes, the change appears in system /bin.
> > 
> > So with this proposal mount mapping becomes "map all users on this
> > filesystem to subusers of username x". That's a much simpler mapping
> > than mapping integer ranges to integer ranges, much easier to verify
> > that there aren't accidental root escpes.
> 
> That doesn't work for the privileged container run in unprivileged
> userns containment use case because we need a mapping from inner to
> outer root.

I can't parse this. "Privileged container in an unprivileged
containment"? Do you just mean a container that has root user (which is
only root over that container, not the rest of the system, of course).

Any user is root over its subusers - so that works perfectly.

Or do you mean something else by "privileged container"? Do you mean a
container that actually has CAP_SYS_ADMIN?

> > > > And it wouldn't have to be administrator assigned. Some
> > > > administrator assignment might be required for the username <->
> > > > 16 bit uid mapping, but if those mappings are ephemeral (i.e. if
> > > > we get filesystems persistently storing usernames, which is easy
> > > > enough with xattrs) then that just becomes "reserve x range of
> > > > the 16 bit uid space for ephemeral translations".
> > > 
> > > *if* the user names you're dealing with are all unprivileged.  When
> > > we have a mix of privileged and unprivileged users owning the
> > > files, the problems begin.
> > 
> > Yes, all subusers are unprivilidged - only one username, the empty
> > username (which we'd probably map to root) maps to existing uid 0.
> 
> But, as I said above, that's only a subset of the use cases.  The
> equally big use case is figuring out how to run privileged containers
> in a deprivileged mode and yet still allow them to update images (and
> other things).

If you're running in a userns, all your mounts get the same user mapping
as your userns - where that usermapping is just prepending the username
of the userns. That part is easy.

The big difficulty with letting them update images is that our current
filesystems really aren't ready for the mounting of untrusted images -
they're ~100k loc codebases each and the amount of hardening required is
significant. I would hazard to guess that XFS is the furthest along is
this respect (from all the screaming I hear from Darrick about syzkaller
it sounds like they're taking this the most seriously) - but I would
hesitate to depend on any of our filesystems to be secure in this
respect, even my own - not until we get them rewritten in Rust...