All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karl MacMillan <kmacmillan-dy+cvmKwH3TCDj715knRiQC/G2K4zDHf@public.gmane.org>
To: ewalsh-+05T5uksL2qpZYMLLGbcSA@public.gmane.org
Cc: Steve G <linux_4ever-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>,
	Stephen Smalley <sds-+05T5uksL2qpZYMLLGbcSA@public.gmane.org>,
	selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org,
	linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Subject: Re: missing avc message field names
Date: Mon, 29 Jan 2007 14:43:00 -0500	[thread overview]
Message-ID: <45BE4E44.8050900@mentalrootkit.com> (raw)
In-Reply-To: <45BE4971.6090601-+05T5uksL2qpZYMLLGbcSA@public.gmane.org>

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.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo-+05T5uksL2qpZYMLLGbcSA@public.gmane.org with
the words "unsubscribe selinux" without quotes as the message.

WARNING: multiple messages have this Message-ID (diff)
From: Karl MacMillan <kmacmillan@mentalrootkit.com>
To: ewalsh@tycho.nsa.gov
Cc: Steve G <linux_4ever@yahoo.com>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	selinux@tycho.nsa.gov, linux-audit@redhat.com
Subject: Re: missing avc message field names
Date: Mon, 29 Jan 2007 14:43:00 -0500	[thread overview]
Message-ID: <45BE4E44.8050900@mentalrootkit.com> (raw)
In-Reply-To: <45BE4971.6090601@tycho.nsa.gov>

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.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  parent reply	other threads:[~2007-01-29 19:43 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-29 14:10 missing avc message field names Steve G
2007-01-29 14:35 ` Stephen Smalley
2007-01-29 14:58   ` Karl MacMillan
2007-01-29 15:13     ` Steve G
2007-01-29 15:09   ` Steve G
2007-01-29 15:13     ` Stephen Smalley
2007-01-29 17:27       ` Steve G
2007-01-29 18:32         ` Karl MacMillan
2007-01-29 18:39     ` Karl MacMillan
2007-01-29 18:55       ` Steve G
2007-01-29 19:22         ` Eamon Walsh
2007-01-29 19:22           ` Eamon Walsh
     [not found]           ` <45BE4971.6090601-+05T5uksL2qpZYMLLGbcSA@public.gmane.org>
2007-01-29 19:43             ` Karl MacMillan [this message]
2007-01-29 19:43               ` Karl MacMillan
2007-01-29 20:07               ` Eamon Walsh
2007-01-29 20:07                 ` Eamon Walsh
2007-01-29 20:56           ` Steve Grubb
2007-01-29 20:56             ` Steve Grubb
2007-01-29 21:16             ` Karl MacMillan
2007-01-29 21:16               ` Karl MacMillan
2007-01-29 22:49               ` Steve Grubb
2007-01-29 22:49                 ` Steve Grubb
2007-01-29 23:48                 ` Eamon Walsh
2007-01-29 23:48                   ` Eamon Walsh
     [not found]                   ` <45BE87E0.5090109-+05T5uksL2qpZYMLLGbcSA@public.gmane.org>
2007-01-30 12:25                     ` Russell Coker
2007-01-30 12:25                       ` Russell Coker
     [not found]                 ` <200701291749.21897.sgrubb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2007-01-30 14:49                   ` Karl MacMillan
2007-01-30 14:49                     ` Karl MacMillan
2007-01-30 17:06                     ` Joshua Brindle
2007-01-30 17:06                       ` Joshua Brindle
2007-01-30 17:28                       ` Valdis.Kletnieks
2007-01-30 17:28                         ` Valdis.Kletnieks
2007-01-30 18:45                       ` Casey Schaufler
2007-01-30 18:45                         ` Casey Schaufler
2007-01-30 17:42                     ` Steve Grubb
2007-01-30 17:42                       ` Steve Grubb
2007-01-30 22:53                     ` James Antill
2007-01-30 22:53                       ` James Antill
     [not found]                       ` <1170197588.3373.28.camel-pBdgC7Q4sO52KDkfy0k2sw@public.gmane.org>
2007-01-31  0:50                         ` Karl MacMillan
2007-01-31  0:50                           ` Karl MacMillan
2007-01-31  5:29                           ` Joshua Brindle
2007-01-31  5:29                             ` Joshua Brindle
     [not found]                             ` <45C02948.9090607-5TQdPaFcblfQT0dZR+AlfA@public.gmane.org>
2007-01-31 22:59                               ` Russell Coker
2007-01-31 22:59                                 ` Russell Coker
2007-02-01 11:40                                 ` Steve Grubb
2007-02-01 11:40                                   ` Steve Grubb
2007-01-29 19:37         ` Stephen Smalley
2007-01-29 21:14           ` Steve G

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45BE4E44.8050900@mentalrootkit.com \
    --to=kmacmillan-dy+cvmkwh3tcdj715knriqc/g2k4zdhf@public.gmane.org \
    --cc=ewalsh-+05T5uksL2qpZYMLLGbcSA@public.gmane.org \
    --cc=linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=linux_4ever-/E1597aS9LQAvxtiuMwx3w@public.gmane.org \
    --cc=sds-+05T5uksL2qpZYMLLGbcSA@public.gmane.org \
    --cc=selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.