Restricting access to files/directories using Confined Users?

Dont know if fitting here, but would confined users also fit to restrict permissions to

  • application launch dir
  • path
  • shell configs
  • .ssh, .gnupg

? Because those are by default pretty unprotected. Currently I have them either not even readable by anyone but root, or only writable by root.

But then in the app dir you would want only root and packagekit to be able to add entries there. I mean any malware could copy a user app there and add its stuff into the file. But then what about those linked from flatpak?

Same for shell configs and path but those normally dont get touched, only manually and there gnome texteditor and kwrite both have polkit for password auth.

I have created a new topic for this. Feel free to adjust the topic title if you want.

I have to simplify/shorten my answer a little since I have not that much time today. But hopefully this will give you some indication:

Generally, be aware that for Linux, everything is a file: this includes processes, hardware, and so on. With this “rule” in mind, you might revisit the original topic and read the Firefox case: SELinux can prevent Firefox to access the “file” that represents the terminal emulator (in my case, it was konsole), even if all occurs within one account.

So the answer is yes, SELinux confined user accounts increase protection for any files within the account: if anything wants to access any file, it needs to have a profile that fits read/write for the profile of what is to be read/altered.

When it comes to gpg files, there is even a dedicated profile. I have no specific knowledge about the gpg profile and do not know how much it differs, but I expect that the dedicated profile for gnupg further restricts access to the related files since they are through the profile “further separated” from other files. You might do yourself some research on gpg_secret_t types.

So, we have an increased security through limited access in terms of read/write to all files in the user account, which includes .ssh, .gnupg, shell configs and so on.

However, I am not sure what you mean with “application launch dir” → binary directories should be not writable by users by default, but are intended to be readable by everyone. If you mean any executable in your user dir, the above applies as to any file.

If you want to ensure 100% that an attacker can execute nothing that at the same time can be changed by them, you might mount /home, and non-system partitions that the user has access to, with noexec → no file on these partitions can be executed (the user can still execute the binaries of the system’s binary folders such as Firefox and such, but these are not alterable by users anyway). BE AWARE: Some desktop environments can break with noexec configurations, which includes the one of the Fedora KDE Spin (KDE SIG #368), I don’t know about the other environments.

Btw, we had some time ago another topic that had related questions, maybe that is interesting for you, too: SELinux confined users: sysadmin privileges necessary to do sudo operations? Why? How to mitigate?

1 Like

~/.local/share/applications is the directory where desktop entries can be created without any privileges.

You can also copy a file to there without any privileges.

cp /usr/share/applications/firefox.desktop ~/.local/share/applications/firefox.desktop
# edit the Exec= line to add any script from anywhere, use a Fork of Firefox that steals passwords, ...

Then there are default user PATHS, like ~/.local/bin so if a script can be placed here by anyone, it may either be preferred over system directories, or simply it can be malicious.

Same for your .bashrc etc.

So okay, any file in any direction can be executed. This is pretty bad? Why not make noexec to everything apart from the shell config and the PATH, which are both only writable with elevated privileges?

I am new to selinux so I dont know how this would be done.

When I run a systemd-nspawn container the entire directory structure gets a relabel for example :

semanage fcontext -a -t sandbox_file_t "/home/<My-User>/Contain/F38(/.*)?"


restorecon -R /home/<My-user>/Contain/F38

This will give the the container sandbox_file_t context inside of the sandbox container. They cannot break out or see the outside world, but run unconfined inside of the container. You have to relabel if you boot this minimal install so it’s required.

Running a web browser with sandbox -X -w 1920x1080 -H temphome -T tmp -t sandbox_web_t and the browser will be confined to it’s 'temphome and tmp directory you create for it. Also cannot break out.

I think this topic needs more dialogue, because with containers, images and even flatpaks, it’s a great idea to confine apps or give them at leaset a higher SELinux sensitivity level.

Its your user’s local dir, so of course you are free to create files in it.

The ~/.local/share/ dir is indeed one of the issues why noexec causes issues in some desktop environments (see the mentioned KDE SIG #368 above).

Obviously the issue with .bashrc is the same, although the impact of manipulations of .bashrc might be worse in some cases.

Generally, most operating systems have a security architecture that tries to secure the user account as such so that no further security is necessary from within. This is necessary to achieve an acceptable user experience → most people would not be able to manage anything else and would get rid of any security measures at all (we saw that already in the time SELinux has been introduced: many admins just turned it off completely). The obvious outcome is that if any attacker can act from within the user account, there is not much that limits the attacker possibilities once they achieved privileges in the user account. I elaborated this in the above mentioned topic.

SELinux confined users change that (hopefully, at some point at a level that is usable by any average user). The issues you refer to fall into the same category as those elaborated in my previous post: you need a profile that fits the action you want to do. This limits the possibilities of an attacker. First, a directory has also a profile, which means that adding a new file also needs a profile that fits. Second, the major issue I see is a captured or a malicious process: e.g., for some reason, an attacker captures your browser (if you use a secure default browser, this is very unrealistic as of today!) or any application that you installed is captured/malicious (maybe from a third-party repository that ain’t sufficiently tested for Fedora or that is malicious at all) or so → the profiles of “processes” will have limited possibilities to create or change the files you referred to if there is no intentional user action involved. So again, the idea of a Mandatory Access Control (such as SELinux) to not only mitigate attacks at all but also limit the possibilities of seemingly-successful attacks so that they at the best cannot do anything outside the very malicious/captured process is “fulfilled” here.

But as mentioned in the other topic, getting into a user account on a normal desktop/workstation system is already hard because the potential entry vectors (e.g., Firefox) have on themselves strong measures to mitigate attacks and exploitation so that attackers cannot enter a user account as easily as it may sounds (e.g., seccomp). In practice, the issue is mostly that users break themselves the architecture, such as using dangerous untrusted third party software or so (at the worst giving it privileged access), and thus in practice the issue is less that the architecture is broken by attackers. But indeed, SELinux can here help to mitigate the security issues caused by the users themselves, and thus “protect users from themselves” to some extent (making things smoothly usable by average users by definition implies security compromises).

Further, keep in mind that if an attacker has physical access and the necessary credentials, the possibilities of an attacker are much higher than their possibilities with a captured/malicious process, and it is likely that you as a user (and thus in this case the attacker) will have the possibilities to create desktop files and such → it is your account, you need to be able to use it. If the attacker reached this possibility, the only remaining mitigation is to limit the attacker to the user account which has from that point on to be considered broken/untrusted (obviously, that would include to have no sudo on the very user account).

A slight supplement (I’m not sure if that is clear so far): Be aware that factual “SELinux privileges” differ from the “normal” privileges. These are two independent layers of security: every action needs to be permitted by both layers → therefore, if any of the two layers denies an action, the action will be denied at all. In the previously mentioned topic that is elaborated more deeply I think.

So, the stuff you see in the terminal when you seek information about privileges on a file or directory, such as -rw-r--r-- when doing ls -l, has no impact on the factual “SELinux privileges”. But you can get information about the SELinux labels (which in the end determine the possibilities/privileges) by adding the Z option, e.g., ls -lZ.

1 Like

Thanks for all the explanations!

I had some more questions, one will be a seperate thread.

By default gnupg alarms about insecure permissions. I suppose this is a fedora problem and they should be labelled differently?

I wonder what the best way would be here. If gnupg expects traditional unix permissions, that error would still show even if Selinux would block access from the default user profile.

So would you use both, or leave the default permissions and only enhance the SELinux Part?

Well, Fedora and gnupg are exchanging, and Fedora uses the very defaults
of gnupg (as it does with most packages of upstream) without making
alterations, while our findings (e.g., bugs) are forwarded upstream to
gnupg people. I remember there was an issue a year ago or so about
obsoleted systemd files. When we found the issue here in Fedora, we put
it upstream, the changes were done at the level of the gnupg project,
and then the changes “arrived” in Fedora through the next update of
gnupg. This is how it works here. So security guarantees/knowledge
should be widely transferred to Fedora, and if something occurs on
Fedora with gnupg, it is likely to affect gnupg at all.

Also, be aware that gnupg is checking only the “normal” permissions,
because it cannot know if a system uses a mandatory access control
(MAC), and even if so, it cannot know which MAC is used in which way
(there is not just SELinux). So such a warning does not refer to SELinux
but to the “normal” permissions.

However, I don’t have this issue, and if you have it by default, it
might be worth to check the issue and check if we might report it
upstream: if you have a default Fedora, what exact warning (please
the exact copy/paste output) do you get and when do you get it?
How to provoke the issue? What circumstances? You can give us
some terminal output with your input and then the resulting output if
possible (feel free to anonymize user or account names and such). but
please open a new topic for this. You can use the security &
permissions tags and the tag of your Fedora variant (e.g., workstation
or kde ).