SELinux Failure after Fedora22 Upgrade

SELinux got somehow mangled during upgrade process from Fedora21 -> Fedora22. Some of the modules were changed between the versions and as a result my SELinux "system" is borked. It'd be nice to have more available documentation on re-installing and/or resetting SELinux on a system.  I can't use any of the normal tools to manage SELinux, as it only prints out errors like `libsepol.permission_copy_callback...`.  Attempting to relabel a filecontext, for example results in:

# semanage fcontext -a -t system_dbusd_var_lib_t /var/lib/dbus/machine-id
    libsepol.context_from_record: type radicale_port_t is not defined (No such file or directory).
    libsepol.context_from_record: could not create context structure (Invalid argument).
    libsepol.port_from_record: could not create port structure for range 5232:5232 (tcp) (Invalid argument).
    libsepol.sepol_port_modify: could not load port range 5232 - 5232 (tcp) (Invalid argument).
    libsemanage.dbase_policydb_modify: could not modify record value (Invalid argument).
    libsemanage.semanage_base_merge_components: could not merge local modifications into policy (Invalid argument).
    OSError: Invalid argument

I've found 1 relevant bug related to something similar to my issue.  The only "resolution" comes in the last comment from a user, though it's not very clear/detailed on the exact way of "fixing" this problem once and for all.  Anyway, here's the relevant comment from the bug-report:

2015-06-22 15:20:04 EDT

Umm, sure, and the obvious way to rebuild them is to *delete them* using
semanage, which I can't do.  Just rebuilding them is tricky because I
use a puppet module for the builds and I haven't done one by hand in ages; I
guess I could make a one character change to all my modules to make them regen?
Ah, here we go.
So for everybody else: what I did was find all the .pp files (i.e. sudo find
/etc | grep my | grep -v mysql | grep
-v mythtv | grep '\.pp' or whatever works for you) and then simply deleted
them (i.e. sudo rm
/etc/selinux/mymodules/myvirshbugs880971/myvirshbugs880971.pp ...).
After puppet rebuilt them, everything is fine.  I dunno about NOTABUG.  IMO,
semanage not being able to remove invalid modules is *absolutely* a bug.
But at least I have a workaround.

  • I've already tried relabeling the system with `# touch /.autorelabel` multiple times
  • I've tried removing the pertinent lines that are reported as irrelevant during relabel from the file in `/etc/selinux/targeted/modules/active/file_contexts.local` without any changes
  • I've tried disabling SELinux via `/etc/selinux/config` and/or kernel commandline with `selinux=0` in hopes that re-enabling it would, *somehow*, magically fix the issue; alas, no dice
  • I've tried removing the `selinux-policy\*` packages while disabled one by one with `# rpm -ev selinux... --nodeps` and reinstalling them; again, no dice

Once again, the linked bug report is marked as NOTABUG; I have to ask at this point, what is it then? I am clearly not the only one affected by this.

The frustrating thing is that I did not notice/experience this issue before the last upgrade with `dnf`; though, I haven't been using this system for a while now, and the Fedora version was upgraded with `fedup` 6 months ago with no noticeable problems.

Here's the directory listing for the configuration files, though I'm not sure what, if any, of those files I'm supposed to delete. 

 # ls -alh /etc/selinux/targeted/modules/active/

total 876K
drwx------. 2 root      16K Nov 15 02:32 modules
-rw-r--r--. 1 root      58K Oct  8 09:07 base.pp
-rw-r--r--. 1 root      470 Jul 15 14:40 booleans.local
-rw-------. 1 root       32 Oct  8 09:07 commit_num
-rw-------. 1 root     362K Oct  8 09:07 file_contexts
-rw-r--r--. 1 root      13K Oct  8 09:07 file_contexts.homedirs
-rw-r--r--. 1 root     4.7K Nov 15 02:33 file_contexts.local
-rw-------. 1 root     373K Oct  8 09:07 file_contexts.template
-rw-------. 1 root      12K Oct  8 09:07 homedir_template
-rw-------. 1 root        0 Oct  8 09:07 netfilter_contexts
lrwxrwxrwx. 1 root       38 Oct  8 09:07 policy.kern  /etc/selinux/targeted/policy/policy.29
-rw-r--r--. 1 root      225 Jul 15 14:40 ports.local
-rw-r--r--. 1 root      176 Nov 15 05:30 seusers
-rw-------. 1 root      176 Jul 15 14:40
-rw-------. 1 root      101 Oct  8 09:07 users_extra


Ultimately, the only way to deal with this issue at the time of this writing is to painfully go through each and every failure record reported from SELinux and try to find the reference to it in the `/etc/selinux/` subdirectories and delete them.  Weak, annoying, workarounds for failures stemming from incomplete/poor/bad package updates/installation/removal.

Popular posts from this blog

RHEL 7 and CentOS 7 syslog Rate Limit

Set Focus to Follow Mouse Cursor in GNOME 3

Configure rsyslog Server on Fedora