I have a number of Fedora 27 systems. I am reasonably comfortable with SELinux. I run it on all my systems, with the "unconfined" module disabled.

On this particular system, SELinux is blocking all "systemctl --user" commands:

$ systemctl --user status
Failed to read server status: Access denied

This worked until recently. I don't know what changed. I did upgrade from Fedora 26 to Fedora 27 recently, but the timing is not the same as this problem, I don't think.

The part that's weirding me out, and making it hard to know what to do next, is that there's nothing about it in auditd, at all.

In syslog I get:

Dec 25 09:48:07 jukni systemd[669]: selinux: avc:  denied  { status } for auid=n/a uid=1086 gid=1086 cmdline="" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tclass=system permissive=0

Further, this:

$ systemctl --user restart lojban_mediawiki_web
Failed to restart lojban_mediawiki_web.service: Access denied
See user logs and 'systemctl --user status lojban_mediawiki_web.service' for details.

Gives this in syslog:

Dec 25 09:49:06 jukni systemd[669]: selinux: avc:  denied  { start } for auid=n/a uid=1086 gid=1086 path="/home/sampre_mw/.config/systemd/user/lojban_mediawiki_web.service" cmdline="" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:systemd_unit_file_t:s0 tclass=service permissive=0

I can't find anything in sesearch about self:system, and all I can find in https://github.com/TresysTechnology/refpolicy.git or https://github.com/TresysTechnology/refpolicy-contrib.git is:

481:    allow can_load_kernmodule self:system module_load;

225:    allow init_t self:system { status reboot halt reload };

My other similar systems don't have this problem. A relabel reboot did not help. The contexts of the user unit files are:

$ ls -lZ ~/.config/systemd/user/
total 8
drwxr-xr-x. 2 sampre sampre staff_u:object_r:user_home_t:s0  66 Feb  6  2017 default.target.wants
-rw-rw-r--. 1 sampre sampre staff_u:object_r:user_home_t:s0 417 Jul 14 00:32 jbotcan_database.service
-rw-rw-r--. 1 sampre sampre staff_u:object_r:user_home_t:s0 419 Jul 14 00:32 jbotcan_site.service

, which I have no idea if that's correct or not.

Changing this user's login to sysadm_u or user_u didn't help either.

I have no idea where to even go from here. I mean, I could make a custom module to implement the AVCs that are going to syslog, but that seems like The Wrong Thing (tm), since clearly the OS didn't ship without this working.


$ cat /etc/selinux/config

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.

Added #2:

I've now rebooted one of my other Fedora 27 boxes and:

Jan  5 23:31:38 vrici systemd[5992]: selinux: avc:  denied  { status } for auid=n/a uid=1000 gid=1000 cmdline="" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcla

ss=system permissive=0

which makes it feel a lot more like a bug with systemd or selinux.

  • You might be hitting a dontaudit policy. Try disabling dontaudit temporarily with semodule -DB, setting permissive, and running the action again. You should then have complete audit logs you can pass through to audit2why. – Michael Hampton Jan 6 '18 at 9:44
  • My standard audit log check does this: sudo setenforce 0 ; sudo semanage dontaudit off ; echo tailing ; sudo tail -F /var/log/audit/audit.log | grep --line-buffered type=AVC | grep --line-buffered -Pv '\{ (siginh|noatsecure|net_admin|rlimitinh) \}' – rlpowell Jan 6 '18 at 18:16
  • And, I mean, I've got the AVCs from syslog; it just seems really improbable to me that nobody can run systemd user things on F27, which makes me think there's something wrong with my setup. – rlpowell Jan 6 '18 at 18:16
  • Ah. Looks like enabling the "unconfined" module makes this problem go away; that definitely makes it feel like an F27 bug; bugzilla.redhat.com/show_bug.cgi?id=1531864 – rlpowell Jan 6 '18 at 18:21

I think you need to change to the sysadm_r role, maybe try:

sudo -u <your_user> -r sysadm_r -t sysadm_t systemctl --user status?

That could indeed be a bug in the policy, users should be able to manage their own services IMVHO (compared to the system ones). I guess you should report that to fedora selinux-policy package.

Also, did you try to relabel the filesystem with restorecon -RFv /? This will force (-F) some extra identifier to be reset.

Not the answer you're looking for? Browse other questions tagged or ask your own question.