SELinux policy prevents systemd from executing screen, review my solution please

Hello everyone

I’m trying to autostart a service within screen, so I can later connect to it for interactive management.

It looks like this and runs fine on an older computer with a different distro that lacks SELinux

[Unit]
Description=Minecraft Server %i

[Service]
WorkingDirectory=/home/minecraft/%i
User=minecraft

ExecStart=/usr/bin/screen -DmS mc-%i ./run.sh

ExecStop=/usr/bin/screen -p 0 -S mc-%i -X eval 'stuff "say SERVER SHUTTING DOWN. Saving map..."\\015'
ExecStop=/usr/bin/screen -p 0 -S mc-%i -X eval 'stuff "save-all"\\015'
ExecStop=/usr/bin/screen -p 0 -S mc-%i -X eval 'stuff "stop"\\015'
ExecStop=/bin/sleep 2

[Install]
WantedBy=multi-user.target

But upon starting it on my freshly setup Fedora 33 on a stronger machine I get a failure

Dec 31 11:24:49 deep-blue systemd[1]: Started Minecraft Server server-joel-2.
Dec 31 11:24:49 deep-blue systemd[10905]: minecraft@server-joel-2.service: Failed to execute command: Permission denied
Dec 31 11:24:49 deep-blue systemd[10905]: minecraft@server-joel-2.service: Failed at step EXEC spawning /usr/bin/screen: Permission denied
Dec 31 11:24:49 deep-blue systemd[1]: minecraft@server-joel-2.service: Main process exited, code=exited, status=203/EXEC
Dec 31 11:24:49 deep-blue systemd[1]: minecraft@server-joel-2.service: Failed with result 'exit-code'.

This is caused by an AVC denial as we can see in /var/log/audit/audit.log

type=AVC msg=audit(1609410289.919:1814): avc: denied { execute } for pid=10905 comm="(screen)" name="screen" dev="sda4" ino=658299 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:screen_exec_t:s0 tclass=file permissive=0

Now I’m very shakey on SELinux permission management, so I’d like to ask for advice. I’m thinking there is no particular reason why init_t should not have a transition (if I’m using that word right) to screen_exec_t, because init_t is high up the ladder anyway. And if I run audit2allow it spits out the following suggestion:

$ sudo audit2allow -a


#============= init_t ==============
allow init_t screen_exec_t:file execute;

To me that reads like just they thing I want to allow (with the side effect of also allowing systemd to run tmux). Can anyone tell me if it is a bad idea to add this policy?

Edit: After multiple iterations the transition rule expanded a bit, it now looks as follows, is that still okay, or am I in a dangerous territory?

$ cat systemd-may-use-screen.te

module systemd-may-use-screen 1.0;

require {
        type screen_exec_t;
        type ptmx_t;
        type devpts_t;
        type init_t;
        type utempter_exec_t;
        class file { execute execute_no_trans map open read };
        class chr_file { ioctl open read setattr write };
}

#============= init_t ==============
allow init_t devpts_t:chr_file { open setattr };

#!!!! This avc is allowed in the current policy
#!!!! This av rule may have been overridden by an extended permission av rule
allow init_t ptmx_t:chr_file { ioctl open read write };

#!!!! This avc is allowed in the current policy
allow init_t screen_exec_t:file { execute execute_no_trans map open read };
allow init_t utempter_exec_t:file execute;

Thanks in advance for your time!
Best,
Joel

2 Likes