Re: missing avc message field names

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.