I recently updated SpamAssassin on my FC6/strict box to spamassassin-3.1.8-2.fc6.
FWIW, the selinux-policy is currently on selinux-policy-strict-2.4.6-37.fc6
It seems that the installation may well have partially failed because I ran "yum update spamassassin" whilst still in enforcing mode.
I erroneously assumed that spamd continued to run Ok, as I saw no error messages during the "yum update".
Sadly, to my horror earlier today, I found that the /var partition was completely full of log messages from SELinux/spamd, viz:
... Feb 22 12:08:25 topaz kernel: audit(1172146105.931:9462050): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Feb 22 12:08:25 topaz kernel: audit(1172146105.932:9462051): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Feb 22 12:08:25 topaz kernel: audit(1172146105.932:9462052): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Feb 22 12:08:25 topaz kernel: audit(1172146105.932:9462053): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir ....
In other words, for some reason the "broken" update left the process running in the unlabeled_t domain, which is a little bizarre.
In any event, I then got a continuous stream of these denials in the log which eventually filled the log within a few hours.
Note to self: presumably using auditd instead of syslog-ng for storing these messages would have avoided the filesystem overload. Similarly, I have yet to check the manual pages for syslog-ng for a max-logfile-size option which might have avoided the ensuing embarrassment.
After clearing out the massive log files to give spamd and syslog-ng room to manoeuvre, I then tried looking for the spamd[10329] in the process list, but found that it was invisible(!), presumably because it was running as unlabeled_t.
I then tried temporarily enabling the "allow_ptrace" boolean to see if that helped make the process visible, to no avail.
Finally, I was forced to drop into permissive mode to locate the rogue PID running in "unlabeled_t".
So then I stopped spamd, went back to enforcing mode, and restarted spamd, which duly ran in its proper spamd_t domain.
From previous experiences I think the strict policy, and perhaps the
targeted policy also, is missing several permissions which allow various init scripts to be called from within "yum update".
To satisfy my own curiousity, can someone explain how spamd ended up running in unlabeled_t? Is it somehow related to a process continuing to run which has no corresponding executable binary?
Following this experience, can I make some suggestions:
a. Please test that rpm/yum update runs without error for any RPM update on both a strict/enforcing box and a targeted/enforcing box before the RPM is released to mirrors.
b. Don't expect that yum update can be run in enforcing mode, especially on packages associated with running daemons.
c. Please can we add a policy permission so that sysadm_t can seek and destroy unlabeled_t processes with extreme prejudice without recourse to permissive mode?
Ted
# ps axf | grep 103 14549 pts/1 S+ 0:00 _ grep 103 # setsebool allow_ptrace=1 # getsebool -a| grep ptrace allow_ptrace --> on # ps axf | grep 103 14561 pts/1 S+ 0:00 _ grep 103
# setenforce 0 # ps axf | grep 103 10329 ? Ss 12:44 /usr/bin/spamd -d -c -m5 -H -r /var/run/spamd.pid 10331 ? Z 1:23 _ [spamd] <defunct> 10332 ? Z 0:06 _ [spamd] <defunct> 14564 pts/1 S+ 0:00 _ grep 103 # ps axfZ | grep 103 system_u:object_r:unlabeled_t 10329 ? Ss 12:44 /usr/bin/spamd -d -c -m5 -H -r /var/run/spamd.pid system_u:object_r:unlabeled_t 10331 ? Z 1:23 _ [spamd] <defunct> system_u:object_r:unlabeled_t 10332 ? Z 0:06 _ [spamd] <defunct> staff_u:sysadm_r:sysadm_t 14566 pts/1 S+ 0:00 _ grep 103 # setenforce 1 # ps axfZ | grep 103 staff_u:sysadm_r:sysadm_t 14569 pts/1 S+ 0:00 _ grep 103
# setenforce 0 # run_init service spamassassin stop Authenticating root. Password: Stopping spamd: [ OK ] # ps axf | grep spam 14591 pts/1 S+ 0:00 _ grep spam
# setenforce 1 # run_init service spamassassin start Authenticating root. Password: Starting spamd: [ OK ] # ps axfZ | grep spam staff_u:sysadm_r:sysadm_t 14617 pts/1 S+ 0:00 _ grep spam system_u:system_r:spamd_t 14612 ? Ss 0:01 /usr/bin/spamd -d -c -m5 -H -r /var/run/spamd.pid system_u:system_r:spamd_t 14614 ? S 0:00 _ spamd child system_u:system_r:spamd_t 14615 ? S 0:00 _ spamd child #
Ted Rule wrote:
I recently updated SpamAssassin on my FC6/strict box to spamassassin-3.1.8-2.fc6.
FWIW, the selinux-policy is currently on selinux-policy-strict-2.4.6-37.fc6
It seems that the installation may well have partially failed because I ran "yum update spamassassin" whilst still in enforcing mode.
I erroneously assumed that spamd continued to run Ok, as I saw no error messages during the "yum update".
Sadly, to my horror earlier today, I found that the /var partition was completely full of log messages from SELinux/spamd, viz:
... Feb 22 12:08:25 topaz kernel: audit(1172146105.931:9462050): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Feb 22 12:08:25 topaz kernel: audit(1172146105.932:9462051): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Feb 22 12:08:25 topaz kernel: audit(1172146105.932:9462052): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Feb 22 12:08:25 topaz kernel: audit(1172146105.932:9462053): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir ....
In other words, for some reason the "broken" update left the process running in the unlabeled_t domain, which is a little bizarre.
In any event, I then got a continuous stream of these denials in the log which eventually filled the log within a few hours.
Note to self: presumably using auditd instead of syslog-ng for storing these messages would have avoided the filesystem overload. Similarly, I have yet to check the manual pages for syslog-ng for a max-logfile-size option which might have avoided the ensuing embarrassment.
After clearing out the massive log files to give spamd and syslog-ng room to manoeuvre, I then tried looking for the spamd[10329] in the process list, but found that it was invisible(!), presumably because it was running as unlabeled_t.
I then tried temporarily enabling the "allow_ptrace" boolean to see if that helped make the process visible, to no avail.
Finally, I was forced to drop into permissive mode to locate the rogue PID running in "unlabeled_t".
So then I stopped spamd, went back to enforcing mode, and restarted spamd, which duly ran in its proper spamd_t domain.
From previous experiences I think the strict policy, and perhaps the
targeted policy also, is missing several permissions which allow various init scripts to be called from within "yum update".
To satisfy my own curiousity, can someone explain how spamd ended up running in unlabeled_t? Is it somehow related to a process continuing to run which has no corresponding executable binary?
Following this experience, can I make some suggestions:
a. Please test that rpm/yum update runs without error for any RPM update on both a strict/enforcing box and a targeted/enforcing box before the RPM is released to mirrors.
I have no idea what caused this. The usually example would be that your program spamd was running in a context that was removed from the system. So say you had it running in a local policy myspamd_t and then you removed the policy, it would end up in unlabeled_t. Nothing in this update should have caused this.
b. Don't expect that yum update can be run in enforcing mode, especially on packages associated with running daemons.
It should be able to run in enforcing mode. The only thing I am aware of where this has been a problem was in MLS machines where you have to run run_init yum -y upgrade.
c. Please can we add a policy permission so that sysadm_t can seek and destroy unlabeled_t processes with extreme prejudice without recourse to permissive mode?
I agree this policy will be added.
Ted
# ps axf | grep 103 14549 pts/1 S+ 0:00 _ grep 103 # setsebool allow_ptrace=1 # getsebool -a| grep ptrace allow_ptrace --> on # ps axf | grep 103 14561 pts/1 S+ 0:00 _ grep 103
# setenforce 0 # ps axf | grep 103 10329 ? Ss 12:44 /usr/bin/spamd -d -c -m5 -H -r /var/run/spamd.pid 10331 ? Z 1:23 _ [spamd] <defunct> 10332 ? Z 0:06 _ [spamd] <defunct> 14564 pts/1 S+ 0:00 _ grep 103 # ps axfZ | grep 103 system_u:object_r:unlabeled_t 10329 ? Ss 12:44 /usr/bin/spamd -d -c -m5 -H -r /var/run/spamd.pid system_u:object_r:unlabeled_t 10331 ? Z 1:23 _ [spamd]
<defunct> system_u:object_r:unlabeled_t 10332 ? Z 0:06 \_ [spamd] <defunct> staff_u:sysadm_r:sysadm_t 14566 pts/1 S+ 0:00 \_ grep 103 # setenforce 1 # ps axfZ | grep 103 staff_u:sysadm_r:sysadm_t 14569 pts/1 S+ 0:00 \_ grep 103
# setenforce 0 # run_init service spamassassin stop Authenticating root. Password: Stopping spamd: [ OK ] # ps axf | grep spam 14591 pts/1 S+ 0:00 _ grep spam
# setenforce 1 # run_init service spamassassin start Authenticating root. Password: Starting spamd: [ OK ] # ps axfZ | grep spam staff_u:sysadm_r:sysadm_t 14617 pts/1 S+ 0:00 _ grep spam system_u:system_r:spamd_t 14612 ? Ss 0:01 /usr/bin/spamd -d -c -m5 -H -r /var/run/spamd.pid system_u:system_r:spamd_t 14614 ? S 0:00 _ spamd child system_u:system_r:spamd_t 14615 ? S 0:00 _ spamd child #
I've had another dig through the remnants of logs following yesterday's log explosion. Fortunately, I hadn't completely eliminated the log history of the crash.
It seems that Dan is quite right in saying that the RPM Upgrade didn't cause the issue. The logs show that it all started when I amended my localanacron policy some 2 minutes before the log explosion started.
I see these two entries:
... Feb 22 11:19:10 topaz kernel: security: invalidating context staff_u:sysadm_r:initrc_t:s0 Feb 22 11:19:10 topaz kernel: security: invalidating context staff_u:system_r:spamd_t:s0 ...
All I had done was to add these lines to localanacron.te, (part of debugging another issue arising out of running anacron instead of crond), increment the module version number, run "make localanacron.pp" and then "semodule -u localanacron.pp":
...
# Odd setfscreate message when using Anacron but apparently not when using Crond #Feb 21 08:47:59 topaz kernel: audit(1172047679.147:93): avc: denied { setfscreate } for pid=5340 comm="cp" scontext=system_u:system_r:system_crond_t:s0 tcontext=system_u:system_r:system_crond_t:s0 tclass=process allow system_crond_t self:process setfscreate; # Attempt to debug the problem auditallow { crond_t system_crond_t } self:process setfscreate; ...
Just for luck, I checked that the devel environment has the same version number as the overall policy:
[root@topaz selinux.local]# rpm -q selinux-policy-strict selinux-policy-strict-2.4.6-37.fc6 [root@topaz selinux.local]# rpm -qf /usr/share/selinux/devel/Makefile selinux-policy-devel-2.4.6-37.fc6 [root@topaz selinux.local]#
Presumably, there's something amiss with the way I'm adding local patches to the policy which is causing SELinux to invalidate contexts during a local module upgrade.
None of my patches directly overwrite any of the default .pp modules; I try to use localxxxxxx.pp to tweak xxxxxx.pp policy.
Some of my modules do admittedly add types, as well as refining file-labelling and overall policy. Is perhaps the problem related to the way RPM update to policy itself is performed?
Maybe I should be following this general method instead of a plain yum update??
# semodule -r localxxxxxx.pp # yum update selinux-policy-strict # semodule -i localxxxxxx.pp
.... Feb 22 11:15:43 topaz kernel: audit(1172142943.430:470): avc: denied { write } for pid=14039 comm="su" name="root" dev=hda2 ino=2 58817 scontext=staff_u:sysadm_r:sysadm_su_t:s0 tcontext=root:object_r:sysadm_home_dir_t:s0 tclass=dir Feb 22 11:18:31 topaz syslog-ng[2517]: STATS: dropped 0 Feb 22 11:19:10 topaz kernel: security: 5 users, 5 roles, 2081 types, 87 bools, 1 sens, 1024 cats Feb 22 11:19:10 topaz kernel: security: 59 classes, 158274 rules Feb 22 11:19:10 topaz kernel: security: invalidating context staff_u:sysadm_r:initrc_t:s0 Feb 22 11:19:10 topaz kernel: security: invalidating context staff_u:system_r:spamd_t:s0 Feb 22 11:19:10 topaz dbus: Can't send to audit system: USER_AVC avc: received policyload notice (seqno=2) : exe="?" (sauid=81, hos tname=?, addr=?, terminal=?) Feb 22 11:19:10 topaz dbus: Can't send to audit system: USER_AVC avc: received policyload notice (seqno=2) : exe="/bin/dbus-daemon" (sauid=500, hostname=?, addr=?, terminal=?) Feb 22 11:19:10 topaz kernel: audit(1172143150.903:471): policy loaded auid=4294967295 Feb 22 11:21:19 topaz kernel: 29 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:ob ject_r:root_t:s0 tclass=dir Feb 22 11:21:19 topaz kernel: audit(1172143279.378:42740): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 in o=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Feb 22 11:21:19 topaz kernel: audit(1172143279.378:42741): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 in o=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Feb 22 11:21:19 topaz kernel: audit(1172143279.378:42742): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 in o=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir ...
[root@topaz ~]# ls -lrt selinux.local/*.pp -rw-r--r-- 1 root root 22394 Jan 17 19:52 selinux.local/localsysadm.pp -rw-r--r-- 1 root root 21743 Jan 26 17:21 selinux.local/localsudo.pp -rw-r--r-- 1 root root 24145 Feb 1 14:18 selinux.local/localjava.pp -rw-r--r-- 1 root root 370766 Feb 7 17:17 selinux.local/myevolution.pp -rw-r--r-- 1 root root 29649 Feb 17 18:25 selinux.local/localfirefox.pp -rw-r--r-- 1 root root 36556 Feb 17 18:25 selinux.local/localevolution.pp -rw-r--r-- 1 root root 35652 Feb 19 10:11 selinux.local/localmiscpolicy.pp -rw-r--r-- 1 root root 36000 Feb 22 11:18 selinux.local/localanacron.pp [root@topaz ~]#
On Fri, 2007-02-23 at 09:16 +0000, Ted Rule wrote:
I've had another dig through the remnants of logs following yesterday's log explosion. Fortunately, I hadn't completely eliminated the log history of the crash.
It seems that Dan is quite right in saying that the RPM Upgrade didn't cause the issue. The logs show that it all started when I amended my localanacron policy some 2 minutes before the log explosion started.
I see these two entries:
... Feb 22 11:19:10 topaz kernel: security: invalidating context staff_u:sysadm_r:initrc_t:s0 Feb 22 11:19:10 topaz kernel: security: invalidating context staff_u:system_r:spamd_t:s0
This means that at an earlier point in time, while permissive, the system executed an init script and spamd and performed automatic domain transitions even though the resulting contexts weren't legal under policy (allowed when permissive) due to invalid combinations of role/type or user/role (e.g. initrc_t should be in system_r, not sysadm_r, and likely staff_u isn't authorized for system_r?). Then later you reloaded policy while enforcing, and the system invalidated those contexts and remapped them to unlabeled.
run_init explicitly transitions to system_u:system_r:initrc_t for running init scripts. The role transition can be done automatically via policy (role_transition statements), but we don't presently have support for automatic user transitions in policy.
Ah.
So does that mean my current method for getting sysadm_t status is flawed?
At the moment I login as staff_u, newrole into sysadm_r, and thence "su -" to sysadm_t.
This leaves me in "staff_u:sysadm_r:sysadm_t", whereupon run_init seems to be perfectly capable of running init scripts whilst in enforcing mode.
Perhaps the root of my problem is that I ran "yum update" whilst in permissive starting from "staff_u:sysadm_r:sysadm_t", but the policy failed to transition to system_u when some of the rpm postinstall scripts ran /etc/init.d/xxxxx?
On Fri, 2007-02-23 at 08:10 -0500, Stephen Smalley wrote:
On Fri, 2007-02-23 at 09:16 +0000, Ted Rule wrote:
I've had another dig through the remnants of logs following yesterday's log explosion. Fortunately, I hadn't completely eliminated the log history of the crash.
It seems that Dan is quite right in saying that the RPM Upgrade didn't cause the issue. The logs show that it all started when I amended my localanacron policy some 2 minutes before the log explosion started.
I see these two entries:
... Feb 22 11:19:10 topaz kernel: security: invalidating context staff_u:sysadm_r:initrc_t:s0 Feb 22 11:19:10 topaz kernel: security: invalidating context staff_u:system_r:spamd_t:s0
This means that at an earlier point in time, while permissive, the system executed an init script and spamd and performed automatic domain transitions even though the resulting contexts weren't legal under policy (allowed when permissive) due to invalid combinations of role/type or user/role (e.g. initrc_t should be in system_r, not sysadm_r, and likely staff_u isn't authorized for system_r?). Then later you reloaded policy while enforcing, and the system invalidated those contexts and remapped them to unlabeled.
run_init explicitly transitions to system_u:system_r:initrc_t for running init scripts. The role transition can be done automatically via policy (role_transition statements), but we don't presently have support for automatic user transitions in policy.
selinux@lists.fedoraproject.org