Re: missing avc message field names
On Monday 29 January 2007 14:22, Eamon Walsh wrote:
Steve G wrote:
> 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.
Which brings up the question of does everything have to be an AVC message
type? If we ever want to have binary audit records, we need to think of these
audit messages as if they were database tables - each type normalized. This
is, I think, where we are ultimately heading.
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.
The parsing API has a iterator approach and makes no assumptions about what is
supposed to be there or not. So, it would accept new name/value pairs without
any problem.
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.
I just don't see audit growing that much bigger. Of course, I may be wrong.
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.
That would add a lot to disk space consumption in the current logging format.
The real problem that we will have if there is a common name share among
different records but with different meaning, is when people do a search. You
should be able to say "I want all audit records with the perm field" and get
records that are of the right type. Or another example, "I want records with
perm == 0". The perm field in AVC's with get run through strtol which will
yield 0 and then you have a match for an AVC when it should have been file
related. We need unambiguous names to make searching work as expected.
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.
The one function you speak of was designed specifically for a python program.
But otherwise the API is designed to enforce common format across a variety
of applications. I do not see this family of functions growing much bigger at
all. I think we have auditing in nearly all the trusted apps right now. But I
also want to point out that if we ever want to have binary audit records, we
would have to have a standard API that takes certain parameters and converts
them to their binary equivalents. To allow a free style API would mean that
it cannot be converted to binary format.
-Steve