Closed py0xc3 closed 11 months ago
zpytela
commented
1 year ago The default_t type is assigned to filesystem objects that do not match any pattern in file-context configuration. Please assign correct label to the target objects.
Additional question: would using staff_u for a login shell with role transition to sysadm_r (or other ones) on sudo execution would work for you?
py0xc3
commented
1 year ago The labels are all default. It seems if non-root files are created outside ~, they are not assigned a proper label (which means, not assigned a label corresponding to the creator). However, I am wondering why everything works fine if I use midnight commander ("mc") [1] in a kde-konsole [2] within the same KDE-GUI: its privileges/profiles are the same. I have seen that the labels are different in the non-~ directories, but I didn't link it to the issue because copy/cut & paste always worked with "mc".
I just tested with "mc" and evaluated the root logs: The very first time when I used "mc" to move a file (a file that makes dolphin crash) in this KDE session, it logged a comparable dbus-broker denial as dolphin, but the denial did not cause an issue: "mc" did not crash and moving the file works fine as well. In all later tries to move files that make dolphin crash with "mc", no avc denials are logged, and as before, everything worked fine. Interesting behavior.
Concerning the question: Unfortunately, no. I would prefer staff_u, if
not user_u, as well. I have considered sysadm_r already, but I have to
work much in a few folders outside ~, and many applications need the
same access as well. This would be thus no longer practical. There are
some other limitations, too (e.g., staff_u cannot > /dev/* in a terminal).
[1] https://en.wikipedia.org/wiki/Midnight_Commander [2] https://konsole.kde.org/
py0xc3
commented
1 year ago I have been playing with potential mitigations for the two related issues: one one hand, the fact that SELinux seems to not create appropriate labels automatically for files/folders that are created by non-root user accounts outside their own home dir (even if they own the superordinated dirs). On the other hand, the issue that I still need to use permanently sysadm_u for productive working because of permanent work with folder/files outside my home.
I cannot just put the folders/files into my ~ for several reasons
(ironically primarily security reasons). However, I was trying to mount
the folders into my ~ with mount --bind /outside-home-path/ ~/within-home-path. However, when creating new files, now seemingly
within ~, SELinux did still assign the labels as if I had created the
files outside ~. It remains impressive how hard it is to distract
SELinux. Yet, do you maybe have another idea that could work to achieve
that?
I assume it would also mitigate the issue of the ticket, and might present a solution for people who have to work outside their ~ directories while working in confined user accounts. Just in case it proves not realistic to make SELinux create appropriate labels automatically in the mentioned circumstances.
Another question: I am not fully aware of the difference between "user_home_dir_t" and "user_home_t". Is it worth to try to change the superordinated folder outside ~ to "user_home_dir_t" in order to make SELinux label everything below this path the way it labels user files in ~ for the very user?
py0xc3
commented
11 months ago I found the origin of the inappropriate automatic labeling and thus the unintended SELinux denials: the superordinated directory outside ~ that does belong to the user just like ~ needs to be user_home_dir_t (with "dir" in the middle; just like ~) instead of user_home_t. This will ensure that auto-labeling is done properly in subordinated paths so that everything works and remains aligned.
The issue that dolphin breaks in operations (which are still possible even with the improper auto-labeling when user_home_dir_t is not set - as it is proven by, e.g., mc) seems to occur just because dolphin does not consider the output it gets in this situation and thus the dolphin issue is not related to this topic as long as dolphin is not intended to officially support confined user accounts.
Another advantage achieved that way is that I can now also downgrade my user privileges to staff_u and user_u.
However, there is nearly no documentation available of the dynamics/differences of user_home_dir_t and user_home_t, and nearly nothing about user_home_dir_t at all. I am not sure if that would be something to forward upstream?
However, this labeling solves the topic for me. I assume it does not need a general adjustment for Fedora because this use case/situation does not appear on default Fedora installations. It would be just good to have some documentation about it at some time (I am sure that I am not the only one who works sometimes outside ~ from within a normal user account).
I use Fedora 38 KDE Spin with confined user accounts: In my GUI user, I currently test with sysadm_u (obviously with the sysadm-GUI-boolean enabled).
The default file manager of KDE (dolphin) crashes when I try to copy (both with "CTRL + C" and with using the right-mouse-click-menu to click on "copy") or to cut (both with "CTRL + X" and with using the right-mouse-click-menu to click on "cut") in the below described circumstances. The crash occurs always at the very moment I click on "cut"/"copy" or when I push CTRL+C/X. The crash does not occur when the user is set to unconfined_u.
So far, it seems that the crash occurs (and thus can be reproduced) when dolphin is opened within a KDE session and ... -> the crash occurs IF I try to copy/cut a FILE (not folder!) AND IF this FILE is outside the user's home path (which means the file is neither in ~ nor in its sub-paths).
But ... -> the crash NEVER appeared WHEN I tried to copy/cut a FOLDER in any dir. -> the crash NEVER appeared WHEN I tried to copy/cut a FILE within /home/\<user>/* (including the sub-dirs of ~)
However, everything works fine if I start KDE's terminal "konsole" and use "mc" to do copy/move (so a "mc"-running terminal from within the KDE GUI): it seems only dolphin is affected by that. The issue is not new. I have experienced this issue already many months ago, but I don't use dolphin that much and thus I forgot about it when we created the SIG :)
Here are two examples (copy & cut) with all denial-related logs from the root logs (extracts from "journalctl -r"):
Example of "copy" where the very "action"+"crash"+"avc-denial" was on 14:16:00:
Example of "cut" where the very "action"+"crash"+"avc-denial" was on 14:16:10: