masking /proc/cmdline might result in "VFS: Mount too revealing" logged by kernel

[learnwayback]

When trying to mask paths like:

--proc /proc
--dev-bind /dev/null /proc/cmdline
--remount-ro /proc/cmdline

--proc /proc
--ro-bind /dev/null /proc/cmdline

--proc /proc
--ro-bind-data 3 /proc/cmdline
(with exec 3</dev/null)

--proc /proc
--ro-bind /path/empty_file /proc/cmdline

It works but results in dmesg spam of

VFS: Mount too revealing

which suggests something went wrong somewhere?

My goal is to mask sensitive locations such as in: https://github.com/moby/moby/blob/master/daemon/pkg/oci/defaults.go

[rusty-snake]

Can you give a full minimal commandline? I can not reproduce with (Fedora 43)

bwrap --proc /proc --dev-bind /dev/null /proc/cmdline --remount-ro /proc/cmdline --bind /usr /usr --bind /lib64 /lib64 /usr/bin/ls -l /

[learnwayback]

--unshare-all is used

It's unclear when exactly these messages are triggered, it doesn't appear to be immediately consistently.
Over time they just spawn. They are absent when not masking.

Seems unlikely that random software is going to be trying to remount /proc/cmdline or something

[rusty-snake]

I still can not reproduce it. Can you give a full minimal command. What are you running inside bwrap?

[learnwayback]

A chromium browser is sufficient to trigger it multiple times.

[rusty-snake]

Which is expected behaviour. Chromium makes heavy usage of namespaces for its sandboxing.

In short, the requirements for an (unprivileged) user namespace to be able to mount a new instance of a procfs are:

• unshared mount and pid namespaces
• an existing procfs without any mounts beneath it

If your (unprivileged) user+mount namespace has only access to a procfs which some paths overmounted (masked) or made read-only (ro-bind) the kernel will deny this mount. Otherwise "chromium" could just umask these paths by mounting a new instance of procfs.

(netblue30/firejail#3647 (comment))