Red Hat Bugzilla – Bug 181872
audit2allow -l should not depend on enforcement mode
Last modified: 2007-11-30 17:11:24 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.
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: https://www.redhat.com/archives/linux-audit/2005-December/msg00000.html 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 api. Hope this helps...
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)?
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.
Fixed in policycoreutils-1.29.26-1