From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eamon Walsh Subject: Re: missing avc message field names Date: Mon, 29 Jan 2007 15:07:03 -0500 Message-ID: <45BE53E7.1040700@tycho.nsa.gov> References: <20070129185542.32977.qmail@web51502.mail.yahoo.com> <45BE4971.6090601@tycho.nsa.gov> <45BE4E44.8050900@mentalrootkit.com> Reply-To: ewalsh@tycho.nsa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.redhat.com (mx2.redhat.com [10.255.15.25]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l0TK8Dc3013258 for ; Mon, 29 Jan 2007 15:08:14 -0500 Received: from jazzhorn.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by mx2.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l0TK8DaX002689 for ; Mon, 29 Jan 2007 15:08:13 -0500 In-Reply-To: <45BE4E44.8050900@mentalrootkit.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: Karl MacMillan Cc: linux-audit@redhat.com, selinux@tycho.nsa.gov, Steve G List-Id: linux-audit@redhat.com Karl MacMillan wrote: > Eamon Walsh wrote: > >> Steve G wrote: >> >>>> If you have to include code for parsing the current format, why the >>>> rush to change the kernel output? >>>> >>>> >>> I was thinking that it should be done in near future so its not >>> forgotten. But >>> that is the only reason. It could be delayed for a while. >>> >>> But back to the original question, any preference for non-conflicting >>> names? :) >>> >>> >>> >>> >> CC'ing linux-audit. >> >> Some comments regarding userspace object managers and the userspace AVC: >> in general userspace object managers will introduce new fields to the >> AVC messages. For example the AVC's generated by the X server have >> fields such as window=, property=, and extension= for X-specific things >> which do not appear in the kernel AVC's. So it should be relatively >> easy to add new keywords to the dictionary, or even have the audit >> system gracefully accept keywords that are not in its dictionary. >> >> > > Good point - as long as there are userspace generated audit messages it > will be hard to enforce uniqueness. > > >> If all of these keywords in the data dictionary have to be unique, I'm >> wondering if it might be useful to use a 3-tuple instead of a >> (name,value) pair. The 3-tuple would consist of (namespace,name,value) >> with namespace coming from a defined list of subsystems. So for example >> there would be an "SELinux" namespace encompassing all of the selinux >> keywords, so that the "result" and "perms" keywords from the previous >> example would not conflict with the "other" ones which would presumably >> be in a different namespace. Or just prefix the names with "selinux-", >> "syscall-", etc. >> >> > > The prefixes seems simpler and match with the current audit messages > more closely. > > How about "prefix.keyword=value", selinux.result=denied, selinux.perms=foo,bar,baz. > -- Eamon Walsh National Security Agency