1

We're installing RPMs into a CentOS 7 system using Anaconda + Kickstart, which does a chroot into the target system's environment and installs all of the RPMs we specify in our Kickstart config file. In some of these RPMs, the %pre or %post scriptlets are running the SELinux commands semodule, semanage and restorecon to set up our needed SELinux policy.

When installing these RPMs normally (i.e. in an already-installed system), the scriptlets are executing as expected and setting up the SELinux policy on the system. But when we install these RPMs via Anaconda, the commands are succeeding, but none of the SELinux policy actually takes effect in the installed system upon a reboot: none of the modules installed via semodule are installed, and none of the context mappings configured via semanage are in place.

For example, we have a module mymodule.pp which we install in our %post script via semodule -i mymodule.pp and a file context mapping definition that we set as semanage fcontext -a -t mysqld_db_t '/storage/export(/.*)?'; these commands "succeed" during the Anaconda install, but upon rebooting into the actual system, none of the policies are in place.

So this brings my question: when I manage my system's SELinux policy using e.g. semodule, semanage and restorecon, are these commands managing the currently running kernel? Is that why they're not being seen in the newly-installed system? Or might I have something else going on here? I would have figured that running these commands would put/changed a file in the filesystem that would get read by the (newly-installed) kernel on boot to set the policy and contexts.

villapx
  • 143
  • 1
  • 9
  • These commands generally operate on the SELinux configuration in `/etc/selinux` and then tell the kernel to reload it once they're done. You should pull the installation log from one of these systems before it reboots out of Anaconda and take a look at it. – Michael Hampton Mar 07 '19 at 22:09
  • @MichaelHampton so I think one part of my question is actually wrong: the commands don't "succeed" in Anaconda. So maybe I should edit. I'm getting this error message upon running `semodule -i `: `Failed to resolve typeattributeset statement at /etc/selinux/targeted/tmp/modules/400/httpd_mysqld_db/cil:1` and then `/usr/sbin/semodule: Failed!` So that was an oversight on my part in the OP. Any ideas? – villapx Mar 07 '19 at 22:49
  • Did you use the name of a policy that already exists? If so, see https://access.redhat.com/solutions/3492361 – Michael Hampton Mar 07 '19 at 22:53
  • @MichaelHampton No, this is a unique policy name (`httpd_mysql_db`). It might be worth noting that I compiled this SELinux module on a development CentOS 7 machine (using `make -f /usr/share/selinux/devel/Makefile` on my `httpd_mysql_db.te` file) and then am trying to install that compiled module in Anaconda...admittedly, I don't know enough about compiling SELinux modules to know if that's okay. – villapx Mar 07 '19 at 22:59
  • That seems reasonable, except... Do you even need the policy module at all? – Michael Hampton Mar 07 '19 at 23:49
  • @MichaelHampton that's a good question for this particular case, but upon further research after posting this question, we have much larger SELinux issues with Kickstart as well. We also install Nginx and MariaDB, both of whose RPMs set SELinux policy as a `%post`-install scriptlet, and none of those are working when installed in the Kickstart environment either. – villapx Mar 08 '19 at 14:03

1 Answers1

1

Indeed, Michael Hampton was correct in that the SELinux tools operate on the filesystem. We can't find the root cause for why the SELinux policy definitions/modules aren't installing during the Kickstart package installation, but we implemented a workaround:

In our Kickstart ISO, we still put all of these extra packages we need into the package repository, but rather than listing the packages in the %packages section of ks.cfg, we install them in the %post section, e.g.:

additional_pkgs=(
MariaDB-10.3.13-centos73-x86_64-client.rpm
MariaDB-10.3.13-centos73-x86_64-server.rpm
MariaDB-10.3.13-centos73-x86_64-shared.rpm
galera-25.3.25-1.rhel7.el7.centos.x86_64.rpm
rh-nginx114-1.14-6.el7.x86_64.rpm
rh-nginx114-nginx-1.14.1-1.el7.x86_64.rpm
rh-nginx114-runtime-1.14-6.el7.x86_64.rpm
)
for ((i=0; i < "${#additional_pkgs[@]}"; i++)); do
    additional_pkgs[i]="/mnt/install/repo/Packages/${additional_pkgs[i]}"
done
rpm --root /mnt/sysimage --install "${additional_pkgs[@]}"

The unfortunate side effect is that we have to specify the full version number as opposed to just the package name, but we can probably implement a fairly straightforward solution to that when the need arises.

Now, with this workaround, our RPM packages' %post scriptlets that set SELinux policy definitions (or install modules) are working as expected.

villapx
  • 143
  • 1
  • 9