2

All,

I'm developing a modification to systemd that will extend systemd-sleep to support calling user-defined scripts on suspend, hybrid-sleep, etc. similar to systemd-sleep. This is working quite well, however when I started testing on an SELinux-enabled system, things began to fall apart.

I'm not well versed in SELinux, so I'm not even sure on where to begin looking. Fundamentally, the service calls a script as a configured user (/usr/lib/systemd/systemd-sleep-user) which in turn executes any executable under $HOME/.config/systemd/system-sleep.

The associated error message is: SELinux is preventing systemd-sleep-u from execute_no_trans access on the file /home/stallion/.config/systemd/system-sleep/kill-scdaemon.sh.

Since this behavior is similar to how systemd-sleep works (albeit, it uses /usr/lib/systemd/system-sleep) I was hoping this would just require applying the same properties to the user location.

Any thoughts?

Edit: Relevant audit log entry below:

type=AVC msg=audit(1508702442.885:388): avc: denied { execute_no_trans } for pid=3539 comm="systemd-sleep-u" path="/home/stallion/.config/systemd/system-sleep/kill-scdaemon.sh" dev="dm-3" ino=533984 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:config_home_t:s0 tclass=file permissive=0

Improve this question
4
  • There should be an exact AVC message logged in /var/log/audit/audit.log, it probably relevant enough to include in the question.
    – sebasth
    Commented Oct 22, 2017 at 21:06
  • I don't have a system to test on; could you add SELinuxContext=system_u:system_r:unconfined_t:s0 to systemd service file? This would make your scripts run in unconfined domain, in which SELinux does not place (almost any) restrictions. (I can write this as an answer should this work)
    – sebasth
    Commented Oct 22, 2017 at 21:26
  • It definitely works, but you it looks like you can't mix User= and SELinuxContext=. I was able to work around this by just using runuser so I'm good to go. I'd love to see a write up on why this works. Thanks!
    – Steven Stallion
    Commented Oct 23, 2017 at 0:43
  • 1
    For reference: github.com/systemd/systemd/issues/5875
    – Steven Stallion
    Commented Oct 23, 2017 at 0:44

1 Answer 1

Reset to default
2

The error happens because there is no rule in SELinux policy to allow the specific access: allow non-transitioning execution of a file with context config_home_t by a process running in init_t domain.

You could create a custom policy module to include such rule, but you probably do not want to allow any init process to execute any file with user home data label. Another option is to create a custom policy which contains a new file context for your scripts, matching labeling rules and rules allowing a process in init_t domain to execute them.

Third option (and likely the simplest option) is to configure systemd to execute the process in unconfined domain, in which SELinux places almost no restrictions (regular DAC, etc. restrictions still apply). Use SELinuxContext option in your systemd service file:

SELinuxContext=system_u:system_r:unconfined_t:s0
Improve this answer
1
  • Makes sense. Thanks again for the help and explanation!
    – Steven Stallion
    Commented Oct 24, 2017 at 12:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .