If you are a developer, do you keep enabled SELinux?

If you are a developer, do you keep enabled SELinux?

I’m having problems with docker, e.g. when it’s used inside scripts written by others, I’ve problems connecting to VPNs etc.
My biggest problem is that I don’t get any notification about this, probably due to some misconfiguration when I switched from KDE to Gnome.
Due to these, I’m thinking to disable it permanently to avoid wasting any other working time to find out it was only SELinux blocking me to do something.

What do YOU do? Have you become a SELinux “expert” or you have disabled it entirely?

1 Like

I leave it on, as every environment I work in has it enabled, or simply requires it. You can either deal with the issues in your development environment or deal with it later in a much more public and less easily dealt with situation where you do not control all the factors involved. In other words why create additional items to troubleshoot by disabling it.

Instead solve the issues you are having with docker or use podman, leave it enabled. Always leave it on.


You can check if you have setroubleshoot-server installed, that’ll show the notifications and include suggestions on how to work with them. The tool is sealert

I leave it enabled, and if I do need to workaround it, I temporarily set it to permissive:

setenforce 0

and toggle back when done.

I haven’t had a lot of issues with it recently, but I do remember docker etc. throwing up some issues as you note.


SELinux might randomly trigger an alert, but it’s usually fixed pretty quickly, or is not relevant to me.

As a developer, I’ve not had SELinux cause any issues in many many years. There are really only 2 I can think of:

  1. Matlab, but that was in early Grad school and I ditched it for Python as quickly as possible.
  2. Volume mounts in docker/podman. You need to be sure to pass the z or Z mount flag to ensure it works. See Podman volumes and SELinux – Just another Linux geek

Also, Fedora has switched to Podman. It’s built and integrated better and probably there’s no need to use Docker instead (install podman-docker to set up an alias if you have old scripts that need to run the executable.)


Leaving it enabled is a good idea. Just be sure to remember that there are silenced security violations which won’t show up and might lead you to think that it was not SELinux blocking you.

More information about these dontaudit rules are here: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/troubleshooting-problems-related-to-selinux_using-selinux


Yes, I keep it on. I check journalctl when I suspect selinux might be an issue and the messages there are generally helpful in figuring out how to patch it, but honestly, the need to tweak selinux on my dev boxes doesn’t come up nearly as often as it does the various servers I manage at work (which I also keep SELinux enforcing on). I use :z or :Z with my podman mounts.


I installed setroubleshoot-server and I’ve runned the proposed commands to fix the VPN once and for all, thanks @ankursinha !

Thanks for the opinions!
I do agree problems are very rare and once you remember to use :z in docker volumes, 99% problems are solved, I wanted to hear other devs thought and I got some backing in keep using it!


Developed by NSA (National Security Agency) for UNIX going back years ago with information here : https://en.wikipedia.org/wiki/Security-Enhanced_Linux.

1 Like

I’m an electrical engineering student, I do quite some development work (C, C++, Python) and leave selinux alone without problems, except once when it caused me a problem because I restored my home directory without relabeling, locking me out of my user.

Any other problem is detected and reported using SELinux troubleshooter so I’m ok with it.

1 Like

I develop and maintain some science applications. I keep SELinux enabled to ensure the software won’t cause issues for users. I have encountered a few SELinux issues with 3rd party libraries, but most had fixes or workarounds by the time I hit the issue.

1 Like

I have disabled it because even the default fedora install bombards me with so many selinux errors/messages that it make the system almost unusable. I know eacm message shows the command to run to address the specific messagd, but I would nevr get to use the system; I would spend all my time diddling with it.

My impression is that it a very poor way to insure security if it’s so annoying that people like me turn it off. Perhaps the whole design needs to be re-imagined, or a gui config app developed so you could set all your prefs once and be done with it.

There is one command that can be used to fix the selinix context on the entire file system so those messages disappear.
sudo restorecon -R -v / > ~/restorecon.log will do a full relabel of every file & directory on the system with the output written to the restorecon.log file so you can look at what was actually done. Following that, as long as selinux is in enforcing or permissive mode any new files created should be assigned the proper context and no new messages should be generated.

It is much better to fix the problem correctly than to ignore it.

I have, in the past, been flooded with similar messages when there was a change in selinux policies and my file system had not been updated for the change. The preceding command fixed that.

Thanks for this info. Very helpful. I’ll try it

➜ ~ sudo restorecon -R -v / > ~/restorecon.log

This is the log:
Relabeled /run/user/42/dbus-1 from system_u:object_r:user_tmp_t:s0 to system_u:object_r:session_dbusd_tmp_t:s0
Relabeled /run/user/42/dbus-1/services from system_u:object_r:user_tmp_t:s0 to system_u:object_r:session_dbusd_tmp_t:s0
Relabeled /run/NetworkManager/no-stub-resolv.conf from system_u:object_r:NetworkManager_var_run_t:s0 to system_u:object_r:net_conf_t:s0

should it have done more?

It only does what is needed to ensure the file system selinux context complies with system policies, so no it may not have needed more.

The files and directories in the /run (or /var/run) all live in a ramdisk file system, and therefore are all created from scratch at every boot.
If restorecon would fix any of those, it indicates some inconsistencies in the policies.


I experienced problems with docker in Fedora as well, I blogged about my findings in that respect Fixing Docker problems in Fedora | Lorenzo Bettini

That’s to be expected with docker/moby to some extent. Docker was slow to adopt any SELinux support and podman was built with SELinux support intentionally in mind from the beginning. There are very good reasons why podman is the default over moby.

1 Like

I apologize for revisiting this topic but I have run restorecon. Today I tried to run a “sudo snap remove” command and it failed. There was an selinux popup complaining about insufficient permissions.

Obviously the nags that led me to disable selinux have returned and running restorecon does not appear to have been the solution.

I’m going to have to disable it again but if there is some way to enable it so that it does not generate these spurious messages that prevent normal system maintenance from being carried out, I would appreciate it if someone could tell me how to do it.

Thank you