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

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?

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


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

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.

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