Re: CAPP mode for audit

On Thursday 11 August 2005 15:12, Amy Griffis wrote: > Steve Grubb wrote: [Wed Aug 10 2005, 04:09:35PM EDT] > > On Wednesday 10 August 2005 15:58, Amy Griffis wrote: > > > I think it would help if audit had a finer-grained mechanism for > > > specifying events to watch for. > > > > Please elaborate. I am mulling over the next specs. Maybe an example > > usage, too? > > A few weeks ago in #audit, Tim, Rob (_blah_) and I discussed using the > inotify events. For example, from inotify.h: > > /* the following are legal, implemented events that user-space can watch for */ > #define IN_ACCESS 0x00000001 /* File was accessed */ > #define IN_MODIFY 0x00000002 /* File was modified */ > #define IN_ATTRIB 0x00000004 /* Metadata changed */ > #define IN_CLOSE_WRITE 0x00000008 /* Writtable file was closed */ > #define IN_CLOSE_NOWRITE 0x00000010 /* Unwrittable file closed */ > #define IN_OPEN 0x00000020 /* File was opened */ > #define IN_MOVED_FROM 0x00000040 /* File was moved from X */ > #define IN_MOVED_TO 0x00000080 /* File was moved to Y */ > #define IN_CREATE 0x00000100 /* Subfile was created */ > #define IN_DELETE 0x00000200 /* Subfile was deleted */ > #define IN_DELETE_SELF 0x00000400 /* Self was deleted */ > > /* helper events */ > #define IN_CLOSE (IN_CLOSE_WRITE | IN_CLOSE_NOWRITE) /* close */ > #define IN_MOVE (IN_MOVED_FROM | IN_MOVED_TO) /* moves */ > > #define IN_ALL_EVENTS (IN_ACCESS | IN_MODIFY | IN_ATTRIB | IN_CLOSE_WRITE | \ > IN_CLOSE_NOWRITE | IN_OPEN | IN_MOVED_FROM | \ > IN_MOVED_TO | IN_DELETE | IN_CREATE | IN_DELETE_SELF) > > I suppose an example might be to use -E for event (as -e is already > taken). There are too many possibilities to practically use a single > character "mask", so you'd probably have to do something like: > > -E access -E modify -E move > > or > > -E all > > Any other ideas? Hi Amy, I'm glad you've been thinking about this. I think your suggestion makes sense. Or maybe, -E access,modify,move. I definately like the idea of using descriptive words to map to the events we want audited. On another, but related note, the permissions filtering will not be removed so that backwards compatability can be preserved. What will happen is that given the permissions filter, the appropriate events filters will be enabled (i.e., -p wa will enable "modify" but not "access"). This might be considered a nice "short cut" way of saying "I'm interested in all events that require write and append access".

-tim > > Amy > > -- > Linux-audit mailing list > Linux-audit(a)redhat.com > http://www.redhat.com/mailman/listinfo/linux-audit > > -- Linux-audit mailing list Linux-audit(a)redhat.com http://www.redhat.com/mailman/listinfo/linux-audit