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.

6
  • 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 7 '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 <module>: 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 7 '19 at 22:49
  • Did you use the name of a policy that already exists? If so, see access.redhat.com/solutions/3492361 – Michael Hampton Mar 7 '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 7 '19 at 22:59
  • That seems reasonable, except... Do you even need the policy module at all? – Michael Hampton Mar 7 '19 at 23:49
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.