[redhat-lspp] Re: [PATCH] testing new audit features

[Amy Griffis]

On Wed, Apr 05, 2006 at 03:18:22PM -0400, Steve Grubb wrote:
> On Monday 20 March 2006 18:38, Amy Griffis wrote:
> > In contrast to existing audit rule field types, these types require string
> > fields. ?E.g., AUDIT_WATCH requires a path like "/etc/passwd",
> > AUDIT_SE_USER requires a user label like "user_u".
> 
> I have some questions since I'm readying user space tools to support this:
> 
> 1) Does this file system auditing do away with filter keys? Are they no longer 
> needed?

Filter keys are not needed if we include the watch insertion path as part of
the AUDIT_PATH record when an AUDIT_WATCH field matches the context.  It's on
my TODO list. :-)

> 2) What about perms? If someone wanted to express that they want to get write 
> changes to /etc/passwd, how do they do it?

Assuming you mean writes to the file itself,

    auditctl -a exit,always -S open -F watch=/etc/passwd

The open syscall is a rather coarse-grained filter, so we could
consider adding some finer-grained filtering for it, similar to what
was done in Laus.


> >        audit_rule_syscallbyname((struct audit_rule *)rule, "all");
> >        rule->flags = AUDIT_FILTER_EXIT;
> >        rule->action = AUDIT_ALWAYS;
> 
> 3) Does this mean that the file system auditing is handled by the syscall exit 
> filter ?

Yes, in that way it is like inode-based filtering.

> 4) Does each rule get added to the filter or is there some short circuit that 
> keeps them out of the filter? 

Each rule is added to the exit filter list.

> 5) Does the syscall matter ? Its being set to "all", just curious if it really 
> matters.

The syscall(s) specified determine which audit records you will see,
like inode-based filtering.

> 6) The example does not show devmajor and devminor getting used...does this 
> affect anything?

Devmajor and devminor don't really make sense for watches.  The dev
will be determined from the path_lookup on the supplied path.

On Wed, Apr 05, 2006 at 03:45:31PM -0400, Steve Grubb wrote:
> 7) Also...what becomes of the watch_filter? Does it still work ? Is it still 
> needed ?

No, the same feature is now provided using the exit filter list.
Additionally, you may now specify different filters per watched file
if you like, instead of being forced to apply a filter to all watched
files.

Hope this helps,
Amy