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: Mon, 08 Jul 2013 17:26:19 -0400 Message-ID: <7631599.bE25jHDhjZ@x2> References: <1369411910-13777-1-git-send-email-eparis@redhat.com> <2141171.0lgOghWp8c@x2> <1373316680.2395.8.camel@dhcp137-13.rdu.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1373316680.2395.8.camel@dhcp137-13.rdu.redhat.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: Eric Paris Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Monday, July 08, 2013 04:51:20 PM Eric Paris wrote: > On Mon, 2013-07-08 at 16:34 -0400, Steve Grubb wrote: > > On Friday, May 24, 2013 12:11:50 PM Eric Paris wrote: > > > This adds a new 'audit_feature' bit which allows userspace to set it > > > such that the loginuid is absolutely immutable, even if you have > > > CAP_AUDIT_CONTROL. > > > > I'm also not sure I like it done this way. What I was thinking about is > > that we should set this at boot so that no matter what happens during > > boot, the policy is for setting loginuid cannot be messed with. We really > > do not want this to be changeable after the system comes up. I'd much > > rather see this as audit=4 on the boot prompt (meaning enabled and > > immutable). This way its clear to everyone that it can only be changed by > > rebooting the system and the policy is in effect for the duration of the > > session. > > Linus has explicitly said the kernel command line options are only > acceptable if they are required for kernel functionality before they can > be set by userspace. I'd say that is the case. If we are going to have immutable loginuid, we don't want some processes running under one policy and then others later under another policy. Besides, this isn't adding a boot command. Its already there. > If we don't trust the audit system initialization we already lost and no > amount of audit= is going to change that. I'm thinking more about High Assurance cases where the boot partition/environment is removed from an attacker's reach. Consider use cases where you want to allow root, but you do not want them to make certain kinds of changes to the system by taking away certain capabilities in the initramfs which is outside of the control of anyone with root. -Steve