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] [thread-next>] [day] [month] [year] [list]

Message-ID: <lgsh46klnmhaqsgzguoces452gbuzpzpg6jqr3cndblhpq34ez@jm2kobculj2p>
Date: Thu, 22 Feb 2024 06:53:44 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: 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>
Subject: Re: [LSF TOPIC] beyond uidmapping, & towards a better security model

On Thu, Feb 22, 2024 at 09:45:32AM +0100, James Bottomley wrote:
> On Wed, 2024-02-21 at 22:37 -0500, Kent Overstreet wrote:
> > 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.
> 
> if userns root can alter a suid root binary that's bind mounted from
> the root namespace then that's a security violation because a user in
> the root ns could use the altered binary to do a privilege escalation
> attack.

That's a completely different situation; now you're talking about suid
root, where root is _outside_ the userns, and if you're playing tricks
to make something from a user from outside the ns that is not
representable in the ns visible in that ns, and now you're making that
something suid, of course you're going to have trouble defining self
consistent behaviour.

So I'm not sure what point you were trying to make, but it does
illustrate some key points.

Any time you're creating a system where different agents can have
different but overlapping views of the world, you're going to have some
really fun corner cases and it's going to be hard to reason about.

(if you buy me a really nice scotch somitem I'll tell you about fsck for
a snapshotting filesystem, where for performance reasons fsck has to
process keys from all snapshots simultaneously).

So such things are best avoided, if we can. For another example, see if
you know anyone who's had to track down what's keeping a mount alive,
then the something was a systemd service running in a private namespace.

Systems where we can recursively enumerate the world are much nicer to
work with.

Now, back to user namespaces: they shouldn't exist.

And they wouldn't exist, if usernames had started out as a recursive
structure instead of a flat namespace. But since they started out as a
flat namespace, and only _later_ we realized they actually needed to be
a tree structure - but we have to preserve for compatibility the _view_
of the world as a flat namespace! - that's why we have user namespaces.

And you get all sorts of super weird corner cases like you just
described.

So let's take a step back from all that, and instead of reasoning from
"what weird corner cases from our current system do we have to support"
- instead, just seem what we can do with a cleaner model and get that
properly specified. A good model helps you make sense of the world even
in crazy situations.

With that in mind, back to your bind mount thing: if you chroot(), and
you try to access a symlink that points outside the chroot, what
happens?