missing avc message field names
Eamon Walsh
ewalsh at tycho.nsa.gov
Mon Jan 29 20:07:03 UTC 2007
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 <ewalsh at tycho.nsa.gov>
National Security Agency
More information about the Linux-audit
mailing list