Re: audit 1.2.2 released

[Darrel Goeddel <dgoeddel@trustedcs.com>]

Chad Hanson wrote:
> Comments below...
> 
> 
>>I've been running mostly on an i686 (Intel) with the .27 kernel and 
>>1.2.2 tools with the MLS policy. I've tested this on an x86_64 (AMD 
>>opteron) and see this problem too. However, this problem does 
>>NOT exist 
>>when using targeted policy, so it is most likely an MLS SELinux issue.
>>My MLS policy is 2.2.42
>>
>>
>>>Can you describe more about your configuration and provide exact steps
>>>to reproduce the problem?
>>
>>1) Reboot your system (so you've a clean slate)
>>2) Login (tty or pty, doesn't matter, I've done both)
>>3) auditctl -l
>>Error sending rule list request (Operation not permitted)
>>4) auditctl -l
>>No rules (or whatever you expect to see)
> 
> 
> Are you running enforcing or permissive?
> 
> I only see this behavior on the LSPP kernels (including 28) after
> transitioning to permissive mode, but not on the FC5 2.6.15 2054 kernel
> running MLS with the same procedures.
> 
> Also, I don't see this behavior the same way. I can reboot, login, newrole
> to auditadm_r and run auditctl -l correctly everytime.
> 
> The problem behavior I see is as follows below 
> 
> 1) newrole to secadm_r
> 2) auditctl -l -- denied as expected. 
> 3) setenforce 0
> 4) auditctl -l -- denied (WRONG)
> 5) auditctl -l -- works correctly (can repeat as many times as desired)
> 6) setenforce 1 -- everything is back to normal
> 
> repeat from #3 to see problems again

I can reproduce Chad's behavior on an up-to-date rawhide box (currently using
kernel 2.6.16-1.2218_FC6).  If I then boot to the latest published FC5 kernel
(2.6.16-1.2122_FC5) on that machine, I do not see the problem.  So...  I'll
see if I can spot any changes between the two source trees that would cause
the problem.  I'll also try building the working FC5 kernel with the rawhide
toolchain, and possibly building the FC6 kernel with a reduced set of patches
if it comes down to that.  Does this information spark any other ideas?

-- 

Darrel