From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [PATCH 7/7] audit: audit feature to set loginuid immutable Date: Wed, 10 Jul 2013 09:46:38 -0400 Message-ID: <1768498.01aSW39qOl@x2> References: <1369411910-13777-1-git-send-email-eparis@redhat.com> <1453848.WlUzMfBVNC@x2> <51DCA20F.6020309@magitekltd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51DCA20F.6020309@magitekltd.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: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Tuesday, July 09, 2013 06:51:43 PM LC Bruzenak wrote: > On 07/09/2013 05:24 PM, Steve Grubb wrote > > ... > I don't think anyone has plans to write those tools at the moment. That > would be ideal. But even in the case where audit rules don't get loaded, > there are audit events generated by the MAC systems and some hard coded > kernel events and user space events. It would be nice to know they are not > tampered with. ... > > > Question - from the title I had thought this was a good thing. But wasn't > loginuid (and subsequently auid) already immutable? Sorry; just not certain > what this change does for the average guy... Currently its a compile time option. This means when its selected the auid is immutable and you have a strong assurance argument that any action by the subject really is the subject's account. Strong assurance may be required for high assurance deployments. It would be more solid standing up in court as well because the argument can be made that whatever action occurred can be attributed to the subject because there is no way to change it. Its tamper- proof. The change means the default policy will now allow process with CAP_AUDIT_CONTROL to change the auid to anything at anytime and then perform actions which would be attributed to another user. There is an event logged on setting the loginuid, so it could be considered tamper-evident. At least as long as the event's not filtered or erased. My preference is that we have a way that we can put the system into the immutable mode in a way that leaves no doubts about whether the system has operated under the same policy from beginning to end. -Steve