noroot clarifications

[kmk3]

(Continued from #5062)

@WhyNotHugo on Oct 10:

This is a very clear explanation, thanks.

No problem.

The user inside the sandbox ends up being the same one as on the host (e.g.:
same UID), which explains why the xdg-desktop-portal's checks works --
because the current user owns the root of the sandbox's file-system and
therefore the portal can read its contents.

That just makes firejail ignore subsequent noroot commands.

This is one of those items where I think that Firejail's interface can
improve dramatically: because every time I try to reason about this, I no
longer understand what's going on until I go back and read your previous
explanation again.

It's just a bit of a puzzle to reason about:

• The default runs as root and creates users in the sandbox.
• Most profiles include noroot to negate this default behaviour into using
  a namespace with external users inside of it. This makes UIDs mismatch
  between the host and he sandbox.
• We include ignore noroot to negate the above negation.

I'm not sure what you mean here.

firejail always runs as root to setup the sandbox and then switches back to the
current user them before running the program.

The UIDs and GIDs in the user namespace map to the same ones exact outside of
the namespace, the difference with noroot is that only some values are copied
into the user/group map files. The other users/groups are ignored when copying
and so they do not exist in the user namespace.

The effect is similar to deleting an existing supplementary group from
/etc/group and then trying to access a directory that is owned by the same
group ID.

So ignore noroot could be though of as !!root, where root is the
command that creates the root user (and others) inside the namespace (e.g.:
the current default).

When a new process is created, it inherits the existing user/group map.
Nothing is "created". That is probably the case for other unix-like operating
systems as well. noroot just "whitelists" some users and groups before
starting the new process.

Doesn't it make more sense to remove noroot from the profiles entirely
unless strictly necessary?

The main intent of the noroot command is likely "no root user (UID 0) inside
of the sandbox". The confusing part is that it also drops other users and
supplementary groups.

Note that an empty profile allows everything by default and that noroot is
consistent with the other no commands restricting things. Though unlike the
other no commands (which mostly block access to specific resources), it is a
whitelisting command, in the sense that it only keeps a specific subset of
values and drops the rest.

Relates to:

• profiles: blink-common-hardened: disable noroot to fix saving files #6920