Bug 437662 - Selinux prevents audit daemon from starting
Selinux prevents audit daemon from starting
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2008-03-15 18:21 EDT by Göran Uddeborg
Modified: 2008-03-18 09:58 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-18 09:58:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Göran Uddeborg 2008-03-15 18:21:04 EDT
Description of problem:
With the policy from updates-testing, the audit daemon does not start properly
at boot.  In the messages file I get these messages:

Mar 15 23:01:55 freddi kernel: audit(1205618515.525:4): avc:  denied  { read }
for  pid=2312 comm="auditd" name="audispd" dev=sda2 ino=3270513
scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0
Mar 15 23:01:55 freddi auditd: Unable to open /sbin/audispd (Permission denied)
Mar 15 23:01:55 freddi auditd: The audit daemon is exiting.

And when I log in the audit daemon isn't running.  The "unlabeled_t" looked
incorrect to me.  I checked the file, and it indeed has that type:

freddi$ ll -Z /sbin/audispd
-rwxr-x---  root root system_u:object_r:unlabeled_t    /sbin/audispd

But trying to relabel it fails:

freddi$ sudo restorecon /sbin/audispd
restorecon set context /sbin/audispd->system_u:object_r:audisp_exec_t:s0
failed:'Invalid argument'

I experimented a bit, and realised if I redo the semanage command in the
postinstall script of the policy, I can do the relabel.  But the semanage
command gives an error message first.

freddi$ cd /usr/share/selinux/targeted
freddi$ sudo semodule -b base.pp -i amavis.pp -i audioentropy.pp -i awstats.pp
-i ccs.pp -i calamaris.pp -i cdrecord.pp -i certwatch.pp -i cipe.pp -i clamav.pp
-i consolekit.pp -i daemontools.pp -i dcc.pp -i ethereal.pp -i fail2ban.pp -i
games.pp -i gnome.pp -i hal.pp -i ipsec.pp -i irc.pp -i iscsi.pp -i lockdev.pp
-i mailscanner.pp -i mozilla.pp -i mplayer.pp -i mrtg.pp -i nagios.pp -i
oddjob.pp -i pcscd.pp -i openct.pp -i publicfile.pp -i pyzor.pp -i razor.pp -i
ricci.pp -i roundup.pp -i rwho.pp -i screen.pp -i slocate.pp -i smartmon.pp -i
unconfined.pp -i userhelper.pp -i tor.pp -i tvtime.pp -i uml.pp -i usbmodules.pp
-i usernetctl.pp -i tmpreaper.pp -i amtu.pp -i zabbix.pp -i apcupsd.pp -i w3c.pp
-i rpcbind.pp -i vmware.pp -i guest.pp -i xguest.pp -i logadm.pp -i webadm.pp -i
exim.pp -i kismet.pp -i munin.pp -i bitlbee.pp -i nx.pp -i prelude.pp  -s targeted
freddi$ sudo restorecon /sbin/audispd
freddi$ ll -Z /sbin/audispd
-rwxr-x---  root root system_u:object_r:audisp_exec_t  /sbin/audispd

After that, I can start the audit daemon successfully:

freddi$ sudo service auditd start
Startar auditd:                                            [     OK     ]

Now, at first I thought this was some kind of glitch when I installed the policy
package.  But if I reboot the computer, audispd has type unlabeled_t again.  And
I have to repeat the above procedure to get the audit daemon started.

Version-Release number of selected component (if applicable):

How reproducible:
Every time (i.e. every boot)
Comment 1 Daniel Walsh 2008-03-17 09:17:39 EDT
So you are saying the updated did not label file file correctly and even after
running restorecon, th file ends up with an unlabeled_t label after reboot?

Comment 2 Göran Uddeborg 2008-03-17 11:07:51 EDT
I'm not sure what the label was after the update but before I rebooted.  It was
my first guess that the error happened.  But what I know is that after reboot it
was "unlabeled_t", and I had to do the semodule command before restorecon. 
After the next reboot, it was back to unlabeled_t again, and I had to do it again.
Comment 3 Göran Uddeborg 2008-03-17 17:44:14 EDT
I'm not sure if this is related.  But I noticed that /selinux/policyvers says
21.  But it's /etc/selinux/targeted/policy/policy.22 that gets rebuilt when I do
the semanage command, judging from the timestamps.  There is a file
/etc/selinux/targeted/policy/policy.21 too, belonging to the policy package, but
it has a modification time in December.

Is this an indication that I have broken my configuration somehow?  Or is this
natural?  I'm not sure what defines what policy version to use.
Comment 4 Daniel Walsh 2008-03-17 17:50:37 EDT
Remove the 21 file.  Just to make sure.
Comment 5 Daniel Walsh 2008-03-17 17:51:25 EDT
The 21 file must be getting reloaded on reboot and the 22 file gets loaded on
Comment 6 Göran Uddeborg 2008-03-18 06:19:18 EDT
After removing the policy.21 file, the system became unbootable.  The boot
stopped with a message

  Enforcing mode requested but no policy loaded.  Halting now.

Using a rescue disk, I made an attempt to move the generated policy.22 to
policy.21 and reboot, but that simple trick wasn't successful:

  security: policydb version 22 does not match my version range 15-21

That range is defined by the kernel, right?  And I do have the latest F8 kernel.
 So what can I have done to my system to make semanage create a policy with a
too high version number?

Some additional package version numbers, in case they matter:

Comment 7 Daniel Walsh 2008-03-18 08:45:47 EDT
# rpm -q libsemanage checkpolicy libsepol

Comment 8 Göran Uddeborg 2008-03-18 09:58:27 EDT
Aha!  I had installed F9α versions of libsepol and libselinux (for satisfying
dependencies when debugging another issue).  Downgrading back to F8 version made
things behave normally again.

I apologize for the false alarm.

Note You need to log in before you can comment on or make changes to this bug.