How so I configure SELINUX to work with systemd --user daemons?

Ask Fedora
1

I’ve got a few daemons/services running - they’re “systemd --user” services (e.g. in ~/.config/systemd/user.

These have permissions to files in my home directory, but it seems that they can’t do some things that I can do when ssh’d in to that account on the box… In particular, one of the daemons uses a mariadb/mysql connector to talk to a locally running mariadb server (via the domain socket connection - /var/lib/mysql/mysql.sock) If I run the daemon via an ssh session, manually, everything works, with SELINUX in enforcing mode. But it doesn’t work when it’s started by systemd at boot time as a user service.

The issue smelled like an SELINUX issue, so I temporarily disabled it, rebooted, and my daemon magically started working again. I put SEL in permissive mode and then used sealert to help generate some SEL rules automatically to allow stuff (approx: sealert -a /var/log/audit/audit.log; … ausearch -c ‘mydaemon’ --raw | audit2allow -M my-mydaemon )

Now, my software works (and I can connect to mysql) with SEL either off or in permissive mode. But it doesn’t work in enforcing mode. In both permissive and enforcing mode I see no warnings or issues in audit.log. I wonder if my systemd --user daemons don’t have permission to write to the audit log so I’m not seeing some error I should in permissive mode.

I’m no expert in either systemd, or SEL- I’m not sure what I can/should do to further diagnose the issue, and I’d really rather not tur off SEL.

Either I need to see what kind of errors systemd would be wiriting to the journal if my user-level services COULD write to it, or maybe there is some other way I could get information out of SEL somehow.

How are people normally writing daemons that the run from their useraccount (systemd --user) that need to access anything outside files in the local account? What is the expected or recommended process?

2

There might be some “hidden” audit messages that need to be handled.

2 Likes
3

Perfect. You were a great help. This is what I needed. With a simple

semodule -DB

to show me the ‘dontaudit’ AVCs

I could then toggle permissive mode with

setenforce 0

and
setenforce 1

and then I found that I needed to add to my policy the ability to read the directory the .sock file lived in…

and then I turned back off the dontaudit rule printing with

semodule -B

Now I’m worried that with all my debugging, testing, and braindead-I-don’t-know-what-I’m-doing fiddling with selinux, that I have made weird, unnecessary and potentially bad changes to both my selinux config and to my filesystem labels. Is there a relatively simple way to say “restore all this back to how things they should be by default”? I should have snapshotted the VM before I messed around.

Thanks again for your spot-on help.

4

Except for policy modules, semanage -o should work to list all your local customizations.

You can use semodule -r <module-name> to remove custom policy modules.

Edit: semodule -lfull | grep -v '^\s*100' should work to list the non-default modules that have been installed. I think custom/user-defined modules will have priorities of 400+ by default.

1 Like