From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Subject: Re: [PATCH 7/7] audit: audit feature to set loginuid immutable Date: Mon, 08 Jul 2013 17:32:31 -0400 Message-ID: <1373319151.2395.30.camel@dhcp137-13.rdu.redhat.com> References: <1369411910-13777-1-git-send-email-eparis@redhat.com> <2141171.0lgOghWp8c@x2> <1373316680.2395.8.camel@dhcp137-13.rdu.redhat.com> <7631599.bE25jHDhjZ@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <7631599.bE25jHDhjZ@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Mon, 2013-07-08 at 17:26 -0400, Steve Grubb wrote: > On Monday, July 08, 2013 04:51:20 PM Eric Paris wrote: > > 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. If that's the case, you must be loading the audit policy inside the initramfs, and thus, you can set this inside the initrd. We MUST have absolute trust until the audit.rules are processed. To get a boot option, we have to show how this has value before the audit.rules are loaded. And it doesn't... Not in any system I can imagine. Nor in the description you gave above... What am I missing?