SELinux is preventing gnome-shell from write access on the sock_file dbus-XodxlWoUr5

As suggested in another topic, I’m opening up this one about the SELinux alert spam.

So, yes I can just turn off the alerts, but I expect they are showing for a reason, and best not to ignore them.

As one example, I have 138 errors of gnome-shell attempting to write to dbus-XodxlWoUr5 (not sure if that’s an i or an l though). The last time this happened was about an hour ago.

It says if I believe it should have access than I should file it as a bug, and set up a new policy to allow access for now… but that’s kind of the whole problem with SELinux alerts.

I don’t know what gnome-shell is doing, or what this dbus sock_file is, so I don’t know if I want it to be doing that or not.

I guess I could ask the application developers, but in my experience they (not specifically GNOME developers, just in general) don’t respond so well to such requests.

2 Likes

moved to:
https://discussion.fedoraproject.org/t/selinux-is-preventing-gnome-shell-from-connectto-access-on-the-unix-stream-socket-tmp-dbus-changing-value/74408

You need to report the issue, so it can be properly resolved:

And/or create a custom permissive policy as a workaround:
https://man.cx/audit2allow#heading5

2 Likes

Can you please share the complete selinux alert message so others can look at it?

Can you also please give us the output of fpaste --printonly?

Hi,

A confined service like gnome-shell working in the selinux domain xdm_t will probably never match something that is in the target domain unconfined_service_t.

Looking up what matches the source xdm_t, object unix_stream_socket and permission connectto on my Fedora 32 I came up with this:

allow xdm_t xdm_t:unix_stream_socket { accept append bind connect connectto create getattr getopt ioctl listen lock read setattr setopt shutdown write };

Try what happens if you change the target context on the /tmp/dbus-UpA49W7Z0x.

If you want to be careful you could follow these steps:

touch /.autorelabel
chcon -t xdm_t /tmp/dbus-UpA49W7ZOx

Should that mess things up so you can’t use the system it will be relabeled on hard reboot. On the other hand if it solves the problem you can make it persistent with

semanage fcontext -a -t xdm_t /tmp/dbus-UpA49W7ZOx

(You could also start with checking if the file should have some other label than unconfined_service_t with the command “matchpathcon -V /tmp/dbus-UpA49W7Z0x”)

3 Likes

fpaste --printonly has no output for me, is there something else you’d like me to run?

Here’s the alert: SELinux is preventing gnome-shell from write access on the sock_file dbus-XodxlW - Pastebin.com

Thanks for the info, but I don’t have a /tmp/dbus… right now. Maybe it got cleaned up?

i think there are few people who really understand selinux and it is a management nightmare. in addition there are these inconsistencies with silverblue and at the end of the day you may want to ask yourself: what’s the point?

1 Like

There’s quite a point actually. It is an important security feature. Try this:

https://stopdisablingselinux.com/

Uh, sorry, I forgot the all important --syinfo flag. The correct command is fpaste --sysinfo --printonly.

Looks like a known issue that is being looked into:

https://bugzilla.redhat.com/show_bug.cgi?id=1941853

It’ll be good to comment there. You can login to bugzilla using your Fedora Account too.

2 Likes

Please open a new topic to discuss this. I don’t think it’s the same issue that’s being discussed here.

I’m working on that, Sir! :cowboy_hat_face:
Thanks for the link…

A couple of books are lying on my desk. They want to be further discovered I believe.
Probably these books are not from 2021, but the concept is old.

2 Likes

Yeah, absolutely!

selinux has been around for some time, and it is a good security tool. I really appreciate that Fedora still embraces this kind of security management, instead of letting software developers run wild and do whatever they want.

I think it would be helpful for everyone if it was easier to understand and use though. It’s certainly gotten better over the years, but still has potential for improvement.

Today’s boot is looking much better, only a handful of “ignore” messages are showing. I’ll continue to monitor the situation and post where appropriate.

Thanks everyone for your input and information! :slight_smile:

Move to link above.