Problems with SELinux on Fedora 32

Hello.
I’m new to Fedora and trying it out (for switching to Btrfs by default), I currently use Ubuntu on all my Desktops.
But I immediately found some problems that I don’t have on Ubuntu, Debian, openSUSE and other distros, that is SELinux: I cannot create folders on the home skeleton “/etc/skel” to have the configurations for all new users created, I cannot create Btrfs subvolumes.
The only solution is to deactivate SELinux or learn how to use it, which is not really ideal for a new user, albeit a bit advanced like me where I like to customize some parts of the system.
I am wondering at this point if a security system like SELinux forces you to disable it, maybe there is something wrong.
Or maybe I’m doing something wrong?

Hello @emanuc,
I am uncertain from your description what may be the issue. However I would point out that I never make any changes to SELinux and leave it setup as default, so enforcing. Also, I have never learned anything but the most basic things about SELinux, didn’t need to it doesn’t get in the way ever. I am using BTRFS on Fedora rawhide, no problem . You may need to use sudo to modify anything in /etc directory.

1 Like

Thanks for answering and sorry if I was not very clear in explaining my problem, I try to explain better.
Problem 1: When I create new users, I would like all configurations of user 1 to apply also to user 2, to do this, in the case of GNOME, I move the various user configuration folders to (.config/dconf, .local/share/gnome-shell/) /etc/skel.
With SELinux enabled, when I create a new user it doesn’t create my /etc/skel folder configurations, when I disable SELinux the folder configurations on /etc/skel work.

ls -al /etc/skel
totale 12
drwxr-xr-x. 1 root root 106 21 ago 22.04 .
drwxr-xr-x. 1 root root 4694 23 ago 12.05 …
-rw-r–r--. 1 root root 18 2 giu 14.42 .bash_logout
-rw-r–r--. 1 root root 141 2 giu 14.42 .bash_profile
-rw-r–r--. 1 root root 376 2 giu 14.42 .bashrc
drwxr-xr-x. 1 test test 10 21 ago 22.01 .config
drwxr-xr-x. 1 test test 10 21 ago 22.01 .local
drwxr-xr-x. 1 root root 34 23 apr 00.34 .mozilla
Maybe that folders must belong to root and not the user?

For the Btrfs subvolumes, I tried to recreate them and now Fedora starts without problems with SELinux running:

Sorry but I’m new to Fedora :slight_smile:

1 Like

I don’t know if it’s relevant, but I’ll post it: when I created the first flatpak subvolume, it took a few seconds to reboot, with these messages:

I’m not sure if this is a good answer for you, but in your explanation you said ‘move’. I interpret this as ‘mv … …’, I think if you use ‘cp … …’, the SELinux context gets copied and corrected for the new file location.
If you want to use ‘mv … …’, there is a SELinux command ‘revcon’ or something like that, which you can apply to the new location of your files to get the SELinux context in proper sync.

2 Likes

Or, there’s always the option of fixing the SELinux permissions after the fact.

Some context (the hopefully-short version; I’ll try to fight my nature):

With SELinux every file has a context associated with it, and that influences what some processes can and can’t do with those files. (The affected processes, mostly system services, are also executed within a certain context. Regular user processes mostly run unconfined and aren’t restricted by SELinux.) The process that creates new user accounts is likely one of those.

You can view file contexts by passing the -Z flag to ls.

Looking in the default /etc/skel dir, it appears the files only have etc_t file context — I was sort of expecting something more specific.

$ ls -lZA /etc/skel
total 25k
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0   18 Jun  2 08:42 .bash_logout
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0  141 Jun  2 08:42 .bash_profile
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0  376 Jun  2 08:42 .bashrc
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0  334 Aug 20 16:09 .emacs
drwxr-xr-x. 4 root root system_u:object_r:etc_t:s0 4.1k Jan 29  2020 .mozilla
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0  658 Feb 24  2020 .zshrc

Still, as @bobgus intimates, you can get yourself into trouble moving files around on the filesystem, because that’ll cause their origin context to be preserved — normally, when you create a file, it’s assigned the default context for files matching that path/name/etc. But moves aren’t treated that way:

$ cd /home/ferd
$ sudo sh -c 'echo "Nothing to see here" > /etc/skel/.motd'
$ cp .zshrc .zshrc_skel 
$ sudo mv .zshrc_skel /etc/skel/
$ ls -lZA /etc/skel                                        
total 37k
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0             18 Jun  2 08:42 .bash_logout
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0            141 Jun  2 08:42 .bash_profile
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0            376 Jun  2 08:42 .bashrc
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0            334 Aug 20 16:09 .emacs
-rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0         20 Sep  2 04:47 .motd
drwxr-xr-x. 4 root root system_u:object_r:etc_t:s0           4.1k Jan 29  2020 .mozilla
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0            658 Feb 24  2020 .zshrc
-rw-r--r--. 1 ferd ferd unconfined_u:object_r:user_home_t:s0 5.8k Sep  2 04:43 .zshrc_skel

See, now I’ve created an unfortunate situation here. The new .motd file is fine, the different unconfined_u user context won’t matter, but it’s been auto-labeled with etc_t file context, which is most likely one of the only contexts the new-user setup process can access. It won’t be able to read my user_home_t context file.

Fixing it is easy, though:

$ sudo restorecon -Rvv /etc/skel
Relabeled /etc/skel/.zshrc_skel from unconfined_u:object_r:user_home_t:s0 to unconfined_u:object_r:etc_t:s0
$ ls -lZA /etc/skel/.zshrc_skel
-rw-r--r--. 1 ferd ferd unconfined_u:object_r:etc_t:s0 5.8k Sep  2 04:43 /etc/skel/.zshrc_skel
$ # Whoops, should probably change the owner, too
$ sudo chown root:root /etc/skel/.zshrc_skel
$ ls -lZA /etc/skel/.zshrc_skel             
-rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 5.8k Sep  2 04:43 /etc/skel/.zshrc_skel

SELinux can be daunting and frustrating, but it just takes some getting used to. It really doesn’t create problems in practice, though it can frustrate us into creating our own problems. But there’s basically never any reason it HAS to be disabled — disabling it is typically an act of frustration (and we’ve all been there) when the “right way” to handle things isn’t clear.

2 Likes

Thank you so much for the detailed answer!

I still have a doubt:: What happens if I create a Btrfs subvolume?

sudo mount -t btrfs /dev/sdyx /mnt
sudo btrfs subvolume create /mnt/@varlibflatpak
sudo cp -ar /var/lib/flatpak/* /mnt/@varlibflatpak/
edit fstab:
UUID=uuid /var/lib/flatpak btrfs noatime,space_cache=v2,compress=zstd:1,autodefrag,subvol=@varlibflatpak 0 0

In this case, what should I do with the subvolume folder “/mnt/@varlibflatpak”?
I have already tried and it seems that everything is fine on reboot. So in this case the SELinux contexts are created on automatic restart? It’s right?

That, honestly, I have no idea. There should be SELinux file contexts defined for most areas of the system, but if you’re creating your own paths in /mnt I’m not sure whether they’ll be covered by the default context mappings (which are nearly always path-based, and rely on well-known locations for things. Though some are very broad, e.g. all of /home is user_home_t by default, except for the many paths underneath that are customized beyond that.

All directories and symlinks under /mnt are mapped to mnt_t, and it looks like any dotfiles directly under /mnt/* are explicitly given no context at all. (You can see all that with semanage)

$ sudo semanage fcontext -l |grep '/mnt'
/mnt(/[^/]*)?                                      directory          system_u:object_r:mnt_t:s0 
/mnt(/[^/]*)?                                      symbolic link      system_u:object_r:mnt_t:s0 
/mnt/(.*/)?\.snapshots(/.*)?                       all files          system_u:object_r:snapperd_data_t:s0 
/mnt/[^/]*/.*                                      all files          <<None>>

So /mnt/ appears to be intended as a free-for-all. But if all you intend to use it for is to store user files, that’s not necessarily a bad thing. SELinux is mostly designed to not get in the user’s way, it’s intended to restrict system processes that may be running untrusted, or with elevated privileges, to minimize the damage they could do if misbehaving. Generally running as a regular user, though, you’ll be able to access almost everything.

The only times I’ve had to worry about file contexts is when creating files for system daemons. Like, any files in your home directory you want to serve to the web have to have the httpd_user_content_t context (the default for $HOME/public_html). Or, when I set up the MPD music daemon to serve my music collection, I had to apply the audio_home_t context to all of the files I added to the library or MPD couldn’t read them. Things like that.

So, to sort-of answer your question, paths in /mnt I don’t expect will get any particular context. If you need to apply context to anything stored under there, you’ll probably need to do it manually.

You can use the chcon command to change the context of a file/directory as an explicit customization, or you can create a new custom context mapping in the SELinux database using semanage fcontext — doing it that way means that the system will auto-apply the context to newly-created files, and you can use restorecon as I did above to correct the context on any mislabeled files. Using chcon just applies the context, it doesn’t create any rules for managing it. (However, restorecon by default will respect chcon overrides and not undo them, unless it’s run with the -F option.)

1 Like

I should warn you though, if you go that route — the syntax, as you can sort of see in the output of the fcontext -l subcommand I posted, is f—ing BIZARRE and was clearly designed by someone who had no friends growing up.

Yeah “in a sense” it’s just regular expressions, but they’re employed in all sort of nebulous ways, there’s really no documentation or reference for how the actual file contexts are or are supposed to be used, mapping rules can apply to just files, just directories, links, or all sorts of other specific categories, and you’re constantly asked to make choices when you don’t even understand the question. (It’s almost alway best to just keep everything at the defaults except whatever small bit you want to change.)

My point is, don’t expect that it’ll make sense eventually. I have never seen any evidence that’s the case and you’ll just be setting yourself up for disappointment. It will always be confusing and unnecessarily complicated. I definitely still don’t understand it, even 12 years in. But you get used to its complete lack of comprehensibility after a while, and sometimes that’s good enough.