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

Snap is not a fedora package so it has no fedora specified selinux context in the policies. Installing software from 3rd party repos may generate selinux errors and fedora has no clue about how to manage that except to deny access.

If you want fedora to never generate selinux errors the only certain way is to only use software that comes from fedora repos and that has context associated with the fedora selinux policies.

Using 3rd party software may require creating your own policies or putting selinux into permissive mode. Permissive will still generate the errors but will not block access.

These messages are rarely spurious. They generally present a legitimate concern that the application is doing something it should not be doing. If you feel it should be allowed to perform what SELinux is complaining about you can always make a local policy exception or you can look into what the message is actually presenting. The thing with restorecon is it is not a fire and forget solution. Did you change anything related to the item in question, add a file, move stuff around, yeah guess what you may have changed the context of the file, then SELinux should and did notify you with a reminder that something is up.

If you post details about what you are doing and how you are doing it, along with some of the alerts I am sure some of the users here including myself will likely help you, but at the very least you should have setroubleshooter installed, and that should be giving you at least basic information as to what is wrong and how to fix it. In my experience both on Fedora and on Redhat Enterprise Linux the SELinux policy at this point is very well crafted and very much stays out of the way in most situations…except if you are trying to do httpd related things then it will pretty put an end to what you are doing until you tell it not to.

1 Like

first of all, thank you and jeff v as well. Since your reply I’ve been trying to learn more about selinux. I have re-enabled it, but in permissive mode to start. Regarding “Did you change anything related to the item in question?”, no I had not changed anything. What I did was to attempt to run snap remove, which basically hung without a message. Only later, after a reboot did I get the selinux popup. At that point I disabled selinux, rebooted, and was able to successfully run the snap remove command.

Since, I re-enabled selinux again and rebooted. It spent a long time relabeling everything. After logging in, I checked journalctl -t setroubleshoot --since= [time]

It shows 1 item:
Jan 21 19:48:54 fedora setroubleshoot[4658]: SELinux is preventing dbus-daemon from watch access on the directory /var/lib/snapd/dbus-1/services.

The detail on this is below.

I’m confused about this because I see that part of what was installed with snap was snapd-selinux. I can’t find anything that explains what that does but the implication is that it somehow tells selinux what it would need to know to allow snap to function without complaining.

As you can tell, I know next to nothing about this aspect of fedora so my guesses and intuition are essentially worthless.

I’m going to eliminate snap completely and reinstall the one thing that I was using (opera) a different way. I will then watch for future selinux messages and see if I can understand them without your help.

Thank you again

Additional Information:
Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023
Target Context system_u:object_r:snappy_var_lib_t:s0
Target Objects /var/lib/snapd/dbus-1/services [ dir ]
Source dbus-daemon
Source Path dbus-daemon
Port
Host fedora
Source RPM Packages
Target RPM Packages snapd-2.57.6-2.fc37.x86_64
SELinux Policy RPM selinux-policy-targeted-37.18-1.fc37.noarch
Local Policy RPM selinux-policy-targeted-37.18-1.fc37.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Permissive
Host Name fedora
Platform Linux fedora 6.1.6-200.fc37.x86_64 #1 SMP
PREEMPT_DYNAMIC Sat Jan 14 16:55:06 UTC 2023
x86_64 x86_64
Alert Count 4
First Seen 2023-01-18 13:11:57 PST
Last Seen 2023-01-21 19:48:50 PST
Local ID 7b2d36d7-6ac5-419b-a860-1e5284cb7b89

Raw Audit Messages
type=AVC msg=audit(1674359330.420:724): avc: denied { watch } for pid=3930 comm=“dbus-daemon” path=“/var/lib/snapd/dbus-1/services” dev=“sda5” ino=9177360 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:snappy_var_lib_t:s0 tclass=dir permissive=1

Hash: dbus-daemon,xdm_t,snappy_var_lib_t,dir,watch

Snap is provided as an rpm snapd-2.57.6-2.fc37.x86_64 in the fedora repository.

Also

[root@newbox ~]# audit2allow -b


#============= snappy_t ==============
allow snappy_t binfmt_misc_fs_t:dir search;
allow snappy_t init_t:system status;
[root@newbox ~]# 

Just running snap will trigger this.

Thanks. Doesthis then also allow things that snap installs, or it more required?

Probably not. You only see what is blocked until you actually run things. When I was testing some printer snaps, I needed to allow quite a few operations. And it keeps changing, as sometimes new checks gets implemented by the kernel which now will trigger selinux issues.

thanks

I find it simple to leave Enforcing for laptop/workstation where there is a UI. The SEAlert popup warning when SELinux blocks something is helpful, whereas a server terminal won’t show a thing by default and needs to be explicitly searched for. This is especially important on laptops going around to dodgy wifi connections and coffee shops. If SELinux pops up on my laptop I look at it immediately.

Maybe if there were a terminal warning or wall for SELinux denials that could help.

I’ve got selinux in permissive mode. For whatever reason my thunderbird came from a snap. Everytime I open it I get several selinux alerts.

They are confusing to me. First it says:
SELinux is preventing snapd from getattr access on the file /var/lib/snapd/snap/snap-store/638/meta/snap.yaml.

***** Plugin restorecon (68.9 confidence) suggests ************************

If you want to fix the label.
/var/lib/snapd/snap/snap-store/638/meta/snap.yaml default label should be snappy_var_lib_t.
Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly.
Do

/sbin/restorecon -v /var/lib/snapd/snap/snap-store/638/meta/snap.yaml

do I copy the suggested command and run it. The result is:
sudo /sbin/restorecon -v /var/lib/snapd/snap/snap-store/638/meta/snap.yaml

/sbin/restorecon: Could not set context for /var/lib/snapd/snap/snap-store/638/meta/snap.yaml: Read-only file system

The suggested action isn’t very helpful if it cannot actually be run.
As I’ve said, I don’t know much about selinux, but to my simple mind, this doesn’t make any sense.

I know that if I remove all traces of snap, and all apps that were installed from snap and then get thunderbird from the fedora repo, and then spend about 1/2 hour configuring it again, I can make this go away, but…

It is this sort of inscrutable behavior that led me to disable selinux in the first place. And, as was pointed out, if you’re not running a gui, you would never even know that there were problems, only that things that should have run didn’t.

Are you sure the design of this component is optimal? Have people given up trying to improve it and make it more usable?

Which OS version are you running? With Workstation or any of the other spins it should be possible when using sudo, but with silverblue, kinoite, IoT, or CoreOS that may not be as easy.

And as you just said yourself: Using snaps and flatpaks throws another wrench into the management of the system.

It is entirely your choice to use SELinux or not. We are suggesting that leaving it enabled from the very beginning is a good thing, but that is not mandatory. It is up to the user how they want to manage security on their own system.

If selinux is enabled from the beginning relatively few problems are seen. If disabled the selinux contexts are not updated and potential for problems in the future are created. Fixing the issues when selinux is later enabled then becomes a potentially slow and convoluted process.

Snaps are an Ubuntu thing and Ubuntu uses AppArmor instead of SELinux, so I’m not surprised to hear that the SELinux support for snaps isn’t well polished. Flatpak SELinux support is generally there, though.

2 Likes

The issue here is that it is not inscrutable if you read the documentation. Hell even if you man semanage, man sealert, man restorecon and actually read it, it will help guide you. The main reason I use Fedora is because of SELinux and its very refined policy, if not for that I would be back on Archlinux in a heartbeat. There is a learning curve, but in the end it’s worth it, at least for me since I use it in my personal life and in an Enterprise environment where it is actually required.

SELinux on Fedora is very mature, and very usable, but like most complex systems you may actually have to do some dedicated reading to actually get it.

As others have mentioned snap is an ubuntu thing, you are much more likely to have a better experience using flatpak. In general it is faster, more secure, and I have had not issues with SELinux from any of their flatpaks.

1 Like

Thank you for your reply. I am suitably chastised for not studying it in more depth though I must admit I really didn’t know where to start. Do you know if there’s a book that concentrates on selinux?

thanks

Couple of good places to get started outside of reading the manual for each command:

Good primer https://wiki.centos.org/HowTos/SELinux

Much more detailed production oriented Using SELinux Red Hat Enterprise Linux 8 | Red Hat Customer Portal

All the things GitHub - SELinuxProject/selinux-notebook: The SELinux Notebook

I tried Fedora twice before it stuck. The third time I went in knowing I had to actually read up on SELinux, and not learn it on the fly like a lot of stuff previously, that and accept that things in Fedora land work differently than they do in Arch land. Good luck.

plain old 37

Things are getting stranger and stranger. Several days ago I removed all snaps and snap itself. Today I got an selinux alert about snap. This makes no sense to me.

Why do you suppose that it generated this alert? I have obviously overlooked something, bbut what?

Also remove the leftovers:

sudo rm -f -R /var/lib/snapd

It was the program /usr/bin/mandb which was trying to access /var/lib/snapd/

On my system mandb does not do that.