By default, the Salt Minion service runs as unconfined_service_t when SELinux is enabled. This works fine in most cases but generates a problem then trying to transition to an unconfined_t domain, i.a. when running cmd.run env runas=nobody.
(This happens for "cmd.run" at the time of trying to invoke a shell as a different user to gather the environment variables from this particular user)
The issue produces an ERROR message in the Salt logs but the command execution usually works fine (as long as your command is not relying on any of the missing environment variables, as they are not really in place at the time of executing the command)
Fixing the SELinuxContext for the Salt Minion systemd service to a general unconfined_t workarounds this situation.
When systemd version is lower than 209, like in an old CentOS 7.0, having a service with SELinuxContext directive will produces this message in the journal at "daemon-reload":
systemd[1]: [/usr/lib/systemd/system/firewalld.service:17] Unknown lvalue 'SELinuxContext' in section 'Service'
But it does not produce any error and the service is able to start.
What does this PR do?
Currently there are no SELinux policies for Salt.
By default, the Salt Minion service runs as
unconfined_service_t
when SELinux is enabled. This works fine in most cases but generates a problem then trying to transition to anunconfined_t
domain, i.a. when runningcmd.run env runas=nobody
.Then we see this denied in audit logs:
(This happens for "cmd.run" at the time of trying to invoke a shell as a different user to gather the environment variables from this particular user)
The issue produces an ERROR message in the Salt logs but the command execution usually works fine (as long as your command is not relying on any of the missing environment variables, as they are not really in place at the time of executing the command)
Fixing the SELinuxContext for the Salt Minion systemd service to a general
unconfined_t
workarounds this situation.SELinuxContext attribute was added on systemd version 209. If SELinux is disabled or not installed, then this directive is just ignored: https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#SELinuxContext=
When systemd version is lower than 209, like in an old CentOS 7.0, having a service with
SELinuxContext
directive will produces this message in the journal at "daemon-reload":But it does not produce any error and the service is able to start.
Upstream PR: https://github.com/saltstack/salt/pull/66780 Tracks: https://github.com/SUSE/spacewalk/issues/23541
Previous Behavior
And denied AVC message on
/var/log/audit.log
.New Behavior
No denied message seen.
Merge requirements satisfied?
[NOTICE] Bug fixes or features added to Salt require tests.
Commits signed with GPG?
Yes
Please review Salt's Contributing Guide for best practices.
See GitHub's page on GPG signing for more information about signing commits with GPG.