Subject: Re: [bug#75810] [PATCH v6 00/16] Rootless guix-daemon

From: Ludovic Courtès <[email-masked]>
Date: Sun, 23 Mar 2025 15:30:29 +0100

Hello,

Reepca Russelstein <[email-masked]> skribis:

> The handle is a purely user-space sequence of bytes, and is not
> namespaced whatsoever.  In other words, the first "half" (that is,
> name_to_handle_at) is completely optional, as long as you have a good
> idea of what sort of handle values to try.  This means that, if a
> process has this capability in the root user namespace, they can
> potentially access every file of any filesystem that has at least one
> file visible to them.  Note that "filesystem" here is not the same thing
> as "mount point", so this means that if you have a bind mount from the
> root filesystem in the container (or the root filesystem itself in the
> container is on the out-of-container root filesystem), a process in the
> container but with CAP_DAC_READ_SEARCH in the root user namespace could
> access *every file on the real root filesystem*.  This is how an exploit
> for Docker named "shocker" worked
> (http://stealth.openwall.net/xSports/shocker.c), caused by Docker
> leaving CAP_DAC_READ_SEARCH available by default in privileged
> containers.

Ouch. I think the conceptual quagmire stemming from the accumulation of
features retrofitted on the otherwise simpler 1970 Unix model doesn’t
help: mount points, file systems, namespaces,
shared/locked/private/slave subtrees, “capabilities”, ACLs, etc.
It’s intractable.

> I of course hope that the kernel's relaxing of the rules to also allow
> open_by_handle_at in some situations in non-root user namespaces has
> been carefully thought through to not open any holes like this, but it
> would be good to keep an eye on it regardless.

Indeed. :-/

Ludo’.

PS: Just sent v8.