I'm running salt 2015.8.1, but I've grabbed the selinux state and module from develop, so I could have the selinux.module state.
After doing something that SELinux doesn't like, I'll grab the relevant portions of /var/log/audit/audit.log on the minion, stick it in a why.txt. If I want to know why SELinux was unhappy, I'll run:
audit2why < why.txt
To create my module I'll run:
audit2allow -M <my_module_name> < why.txt
Then I'll go ahead and copy the .pp file
cp <my_module_name>.pp /srv/salt/files/selinux/
The way I've figured out to get my module present is like this:
selinux.sls
/etc/selinux/targeted/modules/active/modules/<my_module_name>.pp:
file.managed:
- source: salt://files/selinux/<my_module_name>.pp
my_module_name:
selinux.module:
- module_state: Enabled
Then I run highstate or state.apply and it reports that the module was enabled.
Unfortunately this doesn't actually work. Boo :disappointed: If I re-try the action that triggered the SELinux violation it still fails. However, when I do something to flush privileges (like, say
salt 'myminion' selinux.setsebool xguest_use_bluetooth off persist=True
or
salt 'myminion' cmd.run 'setsebool -P xguest_use_bluetooth off'
), then the SELinux permissions take.
I don't know if the semodule -i command will make the permissions apply right away... but I think what I would personally prefer is to be able to just provide my .te, since it's possible to create the .pp from the .te and maybe have a state that looks something like this:
enable_my_module:
selinux.module:
- name: my_module
# Or something?
- source: salt://files/selinuxe/my_module.te
Alternatively, if there's a way that I _should_ be installing my modules, then some better documentation would be awesome :+1:
More info:
Salt Version:
Salt: 2015.8.1
Dependency Versions:
Jinja2: 2.7.2
M2Crypto: 0.21.1
Mako: Not Installed
PyYAML: 3.11
PyZMQ: 14.7.0
Python: 2.7.5 (default, Jun 24 2015, 00:41:19)
RAET: Not Installed
Tornado: 4.2.1
ZMQ: 4.0.5
cffi: Not Installed
cherrypy: Not Installed
dateutil: Not Installed
gitdb: Not Installed
gitpython: Not Installed
ioflo: Not Installed
libnacl: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.4.6
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: 2.6.1
pygit2: Not Installed
python-gnupg: Not Installed
smmap: Not Installed
timelib: Not Installed
System Versions:
dist: centos 7.1.1503 Core
machine: x86_64
release: 3.10.0-229.14.1.el7.x86_64
system: CentOS Linux 7.1.1503 Core
And minion:
centosdev:
Salt Version:
Salt: 2015.8.1
Dependency Versions:
Jinja2: 2.7.2
M2Crypto: 0.21.1
Mako: Not Installed
PyYAML: 3.11
PyZMQ: 14.7.0
Python: 2.7.5 (default, Jun 24 2015, 00:41:19)
RAET: Not Installed
Tornado: 4.2.1
ZMQ: 4.0.5
cffi: Not Installed
cherrypy: Not Installed
dateutil: Not Installed
gitdb: Not Installed
gitpython: Not Installed
ioflo: Not Installed
libnacl: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.4.6
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: 2.6.1
pygit2: Not Installed
python-gnupg: Not Installed
smmap: Not Installed
timelib: Not Installed
System Versions:
dist: centos 7.1.1503 Core
machine: x86_64
release: 3.10.0-229.14.1.el7.x86_64
system: CentOS Linux 7.1.1503 Core
Installed Packages
Name : policycoreutils-python
Arch : x86_64
Version : 2.2.5
Release : 15.el7
Size : 1.2 M
Repo : installed
Summary : SELinux policy core python utilities
URL : http://www.selinuxproject.org
License : GPLv2
Description : The policycoreutils-python package contains the management tools
: use to manage an SELinux environment.
Available Packages
Name : policycoreutils-python
Arch : x86_64
Version : 2.2.5
Release : 20.el7
Size : 435 k
Repo : base/7/x86_64
Summary : SELinux policy core python utilities
URL : http://www.selinuxproject.org
License : GPLv2
Description : The policycoreutils-python package contains the management tools
: use to manage an SELinux environment.
@waynew, thanks for the detailed report. It seems that for now you will need to add a step to perturb selinux into accepting the new module, but I think this should be added to the salt execution and state modules if possible in addition to your suggestion of .te file support.
@waynew I'm experimenting with the following approach. Please note that it has not been thoroughly tested, but it seems to be working so far.
# Install SELinux policy to allow Apache to use the proxy via the UNIX socket
httpd-proxy-selinux:
file.managed:
- name: /root/httpdsockpolicy.pp
- source: salt://cloud-sql-proxy/files/httpdsockpolicy.pp
cmd.run:
- name: semodule -i /root/httpdsockpolicy.pp
- onchanges:
- file: /root/httpdsockpolicy.pp
selinux.module:
- name: httpdsockpolicy
- module_state: enabled
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.
The fix worked. As of 2018 I can install and enable a module with the pattern:
galera-module-file:
file.managed:
- name: "/root/galera.pp"
- source: "salt://percona/files/galera.pp"
- user: root
- group: root
- mode: 600
galera-selinux-module:
selinux.module:
- name: galera
- module_state: enabled
- install: True
- source: "/root/galera.pp"
- require:
- percona-module-file
Most helpful comment
The fix worked. As of 2018 I can install and enable a module with the pattern: