Re: missing avc message field names
by Eamon Walsh
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.
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.
Another request I have is that if this scheme moves forward, that we do
away with the audit_log_user_avc_message(3) family of functions and
instead introduce an interface that takes an array of name/value pairs
making up the audit message, or a single string which it could parse as
name/value pairs. This would be one-size-fits-all and would avoid the
10+ parameter situation with the current functions.
--
Eamon Walsh <ewalsh(a)tycho.nsa.gov>
National Security Agency
17 years, 10 months
- 9
- 17