From mboxrd@z Thu Jan 1 00:00:00 1970 From: Darrel Goeddel Subject: Re: audit 1.2.2 released Date: Fri, 26 May 2006 11:05:32 -0500 Message-ID: <4477274C.8020100@trustedcs.com> References: <36282A1733C57546BE392885C061859201264DAD@chaos.tcs.tcs-sec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k4QG67MV000614 for ; Fri, 26 May 2006 12:06:07 -0400 Received: from tcsfw4.tcs-sec.com (tcsfw4.tcs-sec.com [65.127.223.133]) by mx3.redhat.com (8.13.1/8.13.1) with ESMTP id k4QG60ca010317 for ; Fri, 26 May 2006 12:06:01 -0400 In-Reply-To: <36282A1733C57546BE392885C061859201264DAD@chaos.tcs.tcs-sec.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Chad Hanson Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.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