From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Timothy R. Chavez" Subject: Re: [RFC][PATCH] (#3) file system auditing Date: Thu, 28 Apr 2005 15:31:25 -0500 Message-ID: <1114720285.6554.88.camel@localhost> References: <1114549486.8169.57.camel@localhost> <20050426232819.GA11810@infradead.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from e32.co.us.ibm.com ([32.97.110.130]:32463 "EHLO e32.co.us.ibm.com") by vger.kernel.org with ESMTP id S262172AbVD1UkR (ORCPT ); Thu, 28 Apr 2005 16:40:17 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3SKeBAa102428 for ; Thu, 28 Apr 2005 16:40:11 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3SKeBGU233710 for ; Thu, 28 Apr 2005 14:40:11 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j3SKeAV0010637 for ; Thu, 28 Apr 2005 14:40:11 -0600 To: Christoph Hellwig In-Reply-To: <20050426232819.GA11810@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 2005-04-27 at 00:28 +0100, Christoph Hellwig wrote: > On Tue, Apr 26, 2005 at 04:04:46PM -0500, Timothy R. Chavez wrote: > > Hello, > > > > The audit subsystem is currently incapable of auditing a file system > > object based on its location and name. > Hello Christoph, I apologize for the delay in my response. Thank you for your response. I'll try to be succinct. > Which doesn't make sense in our world of per-process namespaces. The audit subsystem is responsible for generating accounts of activity in the kernel for the purposes of examination and verification. Thus, in terms of audit, how we capture becomes less important than what we capture, as long as it remains consistent, right? Given A, B follows. The syscall filtering on (inode,device)-pairs is not enough to construct complete accounts of activity across transactions in which an underlying inode is subject to change. Once that inode changes, we've lost audit. So, we've introduced an abstract methodology by which the administrator is able to "watch" by location and name. This allows us to ultimately examine and verify actions taken against, say, "/etc/shadow", and not simply the inode currently associated with it. > Unless this is not just a silly checkbox item for government certification > please add it only to your favourite vendor tree. I think that certs are a perfectly legitimate use-case for a kernel's _audit_ subsystem. I'd like to maintain a relative focus here on linux-fsdevel. When I RFC on LKML, we can argue the virtues of audit and certifications there. -tim