Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Feb 2005 16:20:10 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j1A0K5Iv005019 for ; Wed, 9 Feb 2005 16:20:05 -0800 Received: from build.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id j1A0Jkl15283; Wed, 9 Feb 2005 16:19:46 -0800 Received: (from chrisw@localhost) by build.pdx.osdl.net (8.11.6/8.11.6) id j1A0JkR01862; Wed, 9 Feb 2005 16:19:46 -0800 Date: Wed, 9 Feb 2005 16:19:46 -0800 From: Chris Wright To: David Woodhouse Cc: Linux Audit Discussion , netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] Add audit uid to netlink credentials Message-ID: <20050209161946.F24171@build.pdx.osdl.net> References: <20050204165840.GA2320@IBM-BWN8ZTBWA01.austin.ibm.com> <1107958621.19262.524.camel@hades.cambridge.redhat.com> <1107960659.4837.9.camel@serge> <1107973381.17568.97.camel@moss-spartans.epoch.ncsc.mil> <20050209103747.Y24171@build.pdx.osdl.net> <1107974448.17568.108.camel@moss-spartans.epoch.ncsc.mil> <20050209153816.B24171@build.pdx.osdl.net> <1107993369.9154.2.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1107993369.9154.2.camel@localhost.localdomain>; from dwmw2@infradead.org on Wed, Feb 09, 2005 at 11:56:09PM +0000 X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1454 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 947 Lines: 20 * David Woodhouse (dwmw2@infradead.org) wrote: > On Wed, 2005-02-09 at 15:38 -0800, Chris Wright wrote: > >I just don't see it making sense to add another credential for a special > >case. The signal code already peaks into the siginfo struct when queueing > >a signal to make sure some user isn't trying to send si_code == SI_KERNEL > >or similar. Perhaps audit could do that with it's own payload during send. > >No matter how we slice it, it's a special case. > > I'm not entirely sure the check is needed anyway. This is a trusted > application sending audit messages. Why shouldn't it be permitted to log > auditable events which were triggered by someone _else_? Then it comes back to the question of how to protect loginuid. If it can be spoofed by someone with CAP_AUDIT_WRITE, then it shouldn't be write protected by CAP_AUDIT_CONTROL. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net