Confined user show policy issue: mounting external devices in GUI does not work in KDE / (toolbox doesn't work either)

[py0xc3]

A few days after solving #1917 , I had to go back to sysadm_u for two reasons:

1)

Users with staff_u (I assume the same for user_u) are no longer able to make use of externally mounted devices (CD/DVDs, USB storages, and so on): KDE has a button for mounting and unmounting devices that are mounted by the user for temporary use (as any GUI environment). The mounting takes place in /run/media/<username> when the user does such a mount. This is intended by Fedora & KDE.

When I click this button, everything seems to work at first glance: the directory /run/media/<username>/<device ID> is created and the device is mounted. However, the staff_u user cannot open/access anything because the directories /run/media/<username>/ & subordinated paths have the default label and are thus not accessible by staff_u .

Major problem: the directories are created temporary (within a tmpfs). At each boot, /run/media/<username>/ is created when the first device is mounted. The subdirectories inherit the issue.

However, I assume the solution is the same as for #1917 : when /run/media/<username>/ is created at the time of the first user-mount, it needs to be created with user_home_dir_t (not user_home_t) so that its subdirectories get the appropriate label. This needs to occur automatically when the directory is created in /run/media/ - so at each boot.

I will add a ls -laZ /run/media/<username> & ls -laZ /run/media/<username>/<device> output once I have a USB device available.I have currently no possibility to make a more sophisticated report with outputs from a staff_u account. I create the ticket to have it documented. However, I guess the issue is quite clear and easy to reproduce.

2)

toolbox does not work in staff_u as well: it breaks at the time of toolbox enter. It always works at sysadm_u. It always breaks at staff_u. Again, this is only to have it documented (I wanted to write a more sophisticated report weeks ago). If someone has time and the possibility, feel free to check it out and open a new ticket about it. Otherwise I will do it at some time.

Sorry for the "quick and dirty" report.

[py0xc3]

Sorry for the late reply, I thought I have an eligible external USB device at home... I was wrong :)

Here is the information I promised above:

# Default state after booting & logging in (before KDE GUI is used to mount the external USB device)

user@fedora:~$ ls -laZ /run/media/
total 0
drwxr-xr-x.  2 root root system_u:object_r:mnt_t:s0       40 Feb  9 13:15 .
drwxr-xr-x. 50 root root system_u:object_r:var_run_t:s0 1340 Feb  9 13:18 ..

# After the KDE GUI was used to mount the external USB device in a staff_u user

user@fedora:~$ ls -laZ /run/media/
total 0
drwxr-xr-x.  3 root root system_u:object_r:mnt_t:s0       60 Feb  9 13:18 .
drwxr-xr-x. 50 root root system_u:object_r:var_run_t:s0 1340 Feb  9 13:18 ..
drwxr-x---+  3 root root system_u:object_r:mnt_t:s0       60 Feb  9 13:18 user
user@fedora:~$ ls -laZ /run/media/user/
total 4
drwxr-x---+ 3 root root system_u:object_r:mnt_t:s0         60 Feb  9 13:18 .
drwxr-xr-x. 3 root root system_u:object_r:mnt_t:s0         60 Feb  9 13:18 ..
drwxr-xr-x. 4 root root system_u:object_r:unlabeled_t:s0 4096 Dec 16 23:07 <device UUID>
user@fedora:~$ ls -laZ /run/media/user/<device UUID>/
ls: cannot open directory '/run/media/user/<device UUID>/': Permission denied

# Root output (at the time as the user gets the above "permission denied" with the same command)

root@fedora ~]# ls -laZ /run/media/user/<device UUID>/
total 24
drwxr-xr-x. 4 root   root system_u:object_r:unlabeled_t:s0      4096 Dec 16 23:07 .
drwxr-x---+ 3 root   root system_u:object_r:mnt_t:s0              60 Feb  9 13:18 ..
drwxr-xr-x. 4 user   root unconfined_u:object_r:unlabeled_t:s0  4096 Jan 28 18:09 someFolder
drwx------. 2 root   root system_u:object_r:unlabeled_t:s0     16384 Dec 14 23:04 lost+found

[zpytela]

@py0xc3 What is the mount device filesystem, how it was created, what is its content? It looks a filesystem with extended attributes, but no SELinux context.
Is some mount-related user setting in place for the device?

[py0xc3]

I can try to make a more sophisticated test in the next days/weeks if necessary. The device was definitely either ext4 or btrfs. It was created manually by parted on Fedora. I have a machine with unconfined_u and one with sysadm_u. Based upon what I see, I guess the stick was created with the unconfined_u system. But I intentionally tested external devices from different origins. When we want to make confined users available to the general public, using foreign external devices is unfortunately a basic requirement. The device was mounted as it is default for user mounts in KDE: put the stick into the slot, click on the USB stick in the sidebar and then click on mount. So what most users would do. Content was average files, e.g., documents. The issue is, Fedora's use cases and the behavior of average users makes it necessary to be able to use external devices that are from others. With this in mind, I am not sure if it makes sense to keep considering staff_u and user_u for the goals of the SIG. The goal is finally that we make "confined users" usable by average users. The question is indeed if that is possible in this respect: most systems still do not use confined users and thus create no proper labeling. Unless there are yet unconsidered mitigations [1], I tend to go back to the original plan of the SIG to make only sysadm_u "ready" for average users: it still offers the majority of security of "confined users" while a smooth user experience remains possible. It at least mitigates the risk scenarios from within the user account that we initially aimed for. [1] Now that you say it, it seems indeed that the only way (to make external devices of foreign origins as deployable as it is expected from users) is to change the contexts when mounting. That seems indeed like a bad idea for multiple reasons. I don't see a way to bypass that need :( not sure if you have an idea? However, for now I think the restrictions of KDE (login delay, shutdown/reboot, logout) and bluetooth are bigger issues than this one. Also, I will create another ticket when I have time (more critical than this one as well imho) because even with sysadm_u, it is not possible to do video conferencing in Firefox (at least MS teams & Zoom -> denial on "chr_file video*" / "comm=VideoCapture name=video*"; I will consolidate the logs and denials when I have time).