Bug 181872 - audit2allow -l should not depend on enforcement mode
audit2allow -l should not depend on enforcement mode
Product: Fedora
Classification: Fedora
Component: policycoreutils (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2006-02-17 07:07 EST by Ivan Gyurdiev
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 18:27:10 EST
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 Ivan Gyurdiev 2006-02-17 07:07:52 EST
According to audit2allow's manpage:

       -l | --lastreload
              read input only after last policy reload

However, to determine when policy was reloaded, audit2allow -l looks for a
load_policy { granted } message. In permissive mode policy is reloaded just
fine, whether or not the audit message says { denied } or { granted }. This
affects audit2allow -l in a way that I don't like.

I think audit2allow -l should use a different source of information to determine
whether policy was loaded - one that logs what actually happened as opposed to
what should have happened if selinux was enforcing.

Note: The reason I get { denied } on load_policy is that awful scheme where (1)
I need to newrole after su, and (2) my default role isn't sysadm_r. It's a good
thing I'm running in permissive mode, otherwise I'd be near impossible to get
anything done - I want my root privileges back!

Note2: Why doesn't the audit log have timestamps in it? How do I find out when
anything happened - it has 20-digit serial numbers instead, which are not helpful.
Comment 1 Steve Grubb 2006-02-17 08:22:37 EST
Ivan, the lspp kernel has a patch in it where the audit system records policy
load events as having a AUDIT_MAC_POLICY_LOAD event. The current userspace
package, 1.1.4, supports this. The patch was here if you wanted more info:


The patch has not made it upstream, but is set for inclusion in 2.6.17 kernel.
But, anyone doing SE Linux work should be using the lspp test kernels, at least
occassionally, which can be found here: http://people.redhat.com/sgrubb/files/lspp/

Regarding time stamps, the ausearch and aureport programs translate the time
stamp and make it readable. They are the recommended utilities to view audit
logs. Sometime soon we will start a user space library to parse audit logs so
that 3rd party apps do not encode audit knowlege in their own apps. We may
change the log format at some point breaking all apps that don't use a standard

Hope this helps...
Comment 2 Ivan Gyurdiev 2006-02-17 09:42:57 EST
Ok, thanks for the info. Once this patch is merged, we should change audit2allow
to look for the right type of event (will close bug then).

Re: kernel - I am still using kernel 1886 with the debugging removed :) 
Switching my kernel is a highly complex procedure that involves lots of work to
make sure out-of-tree 3D and wireless drivers work properly... but maybe next
time I do it I'll give this kernel a try.

Re: ausearch and aureport. 
Is there an aureport -a -l (as opposed to audit2allow -l)?
Comment 3 Steve Grubb 2006-02-17 10:21:10 EST
There is an "aureport -a -i" which will get you all the important pieces of the
avc denial. If you are wanting to look through the audit logs, I recommend:
"ausearch -i -m all". Both of these can be limited with -ts and -te for start
and end times respectively. To find policy loads, you would do "ausearch -i -m
MAC_POLICY_LOAD -ts 00:00:01" for all since midnight.
Comment 4 Daniel Walsh 2006-02-21 18:27:10 EST
Fixed in policycoreutils-1.29.26-1

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