From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Serge E. Hallyn" Subject: Re: auditing file based capabilities Date: Mon, 13 Oct 2008 09:04:27 -0500 Message-ID: <20081013140427.GC21812@us.ibm.com> References: <200810130715.43092.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <200810130715.43092.sgrubb@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: Steve Grubb Cc: Linux Audit List-Id: linux-audit@redhat.com Quoting Steve Grubb (sgrubb@redhat.com): > Hi, > > With file based capabilities in recent kernels, I think we need to add those > to the path records. An example PATH record: That's a great idea (and would get me to use audit :). > node=127.0.0.1 type=PATH msg=audit(1223893548.459:459): item=1 > name="/etc/resolv.conf" inode=20774937 dev=08:08 mode=0100644 ouid=0 ogid=0 > rdev=00:00 obj=system_u:object_r:net_conf_t:s0 > > If executing the file leads to extra capabilities, I think we need to record > that. If we add it, I'd like to see it recorded like render_cap_t does for > the proc filesystem. Agreed. Then userspace tools can print out full capability names. > In order to conserve disk space, should we make the > field optional so that it doesn't appear in the record unless there are file > based capabilities? Except I think setcap should also be audited, so that if a task receives some inheritable capabilities, you can tell from the logs when that happened and which executable did it. Do you already have a patch for this? -serge