mount: new option to set security context of root inode of in-memory filesystems

[cgzones]

By default the root inode of a in-memory filesystem, like ramfs or tmpfs, gets the default security context for that filesystem type. (E.g. via a fs_use_trans1/2 statement in a SELinux policy.) For SELinux file context definitions are path based, so whether /srv/data is a sub-directory of the root filesystem or the root directory of a nested filesystem, it should have the same context. Thus when mounting a in-memory filesystem the root node has most likely the wrong context and needs to be relabeled. This for example affects mount units within systemd (systemd/systemd#24917).

Some possible solutions (with an addition of a new mount(8) command line flag):

• 1. mount(8) relabels the mountpoint after the mount(2) syscall, via selabel_lookup(3) and setfilecon(3). This however would be non-atomic.
• 2. mount(8) adds a rootcontext= option to the mount flags containing the current context of the mountpoint directory.
• 3. introduce a new mount(2) option, rootcontextauto?, on which LSMs can e.g. set the context of the new root inode to the context of the mountpoint.

Current example behavior:

$ matchpathcon /var/test
/var/test       system_u:object_r:var_t:s0
$ mkdir -Z /var/test
$  ls -ladZ /var/test
drwxr-x---. 2 root root root:object_r:var_t:s0 4096 Oct  4 19:29 /var/test
$ mount -t tmpfs tmpfs /var/test
$ ls -ladZ /var/test
drwxrwxrwt. 2 root root root:object_r:tmpfs_t:s0 40 Oct  4 19:30 /var/test
$ restorecon -vn /var/test
Would relabel /var/test from root:object_r:tmpfs_t:s0 to root:object_r:var_t:s0

[karelzak]

The ideal solution would be to talk with the kernel/SELinux guys :-) (not sure if anyone is on GitHub)

I'd like to avoid FS-specific solutions -- for example, automatically adding rootcontext= when ramfs of tmpfs detected. It would be better to keep things in users' hands. It means the user has to specify that any automation is wanted. Keeping such a thing in the kernel (like your rootcontextauto) would be the best for userspace, but I have doubts kernel guys will agree ...

Maybe we could introduce some placeholder string that will be interpreted by libmount, for example, rootcontext=auto, and then replace auto with context from getfilecon_raw(mountpoint) and call mount(2) with (for example) rootcontext=root:object_r:var_t for /vat/test.

[cgzones]

The most obvious place in the kernel seems to be the set_mnt_opts LSM hook, in particular https://github.com/SELinuxProject/selinux-kernel/blob/abe3c631447dcd1ba7af972fe6f054bee6f136fa/security/selinux/hooks.c#L794-L802:

if (rootcontext_sid) {
	rc = may_context_mount_inode_relabel(rootcontext_sid, sbsec,
					     cred);
	if (rc)
		goto out;

	root_isec->sid = rootcontext_sid;
	root_isec->initialized = LABEL_INITIALIZED;
}

but that hook is unaware of the mountpoint, so its context is not available.

I am not sure whether a special value, auto?, would suffice, as the string auto is not a valid SELinux context, but might be valid for some other LSM (AppArmor, Smack, a future one).

/cc @pcmoore @WOnder93

[karelzak]

My suggestion was to interpret rootcontext=auto in libmount (userspace), so replace "auto" with a current mountpoint SELinux context. Maybe it would be possible to do the same in the kernel, but I have doubts kernel devels will agree with it :-)

Note that libmount already translates mount contexts from human-readable to raw format, see
https://github.com/util-linux/util-linux/blob/master/libmount/src/context_mount.c#L339, so react to "auto" should be relatively simple.

[pcmoore]

Sorry for the delay, my network access has been limited lately.

@cgzones, it might be a good idea to bring this to the SELinux mailing list as it might get more attention there. At the very least I would need to spend a little time looking at the existing mount hooks (they are pretty messy due to the existence of both the "old" and "new" styles of mounting filesystems) to see if this is possible.

[cgzones]

https://lore.kernel.org/selinux/CAJ2a_DcrGQ1d1EU2OqeUWNukz1_kgbY4EQ0ZjeVuGbxX-bEthA@mail.gmail.com/