audit question (fwd)

[Andrew R. Reiter]

Ok, this is interesting and relates to something I've been thinking about
for the storage piece (audit file store).  Logan and I have been
discussing this alittle bit and I brought up to him the idea of creating
some sort of path hash map on the beginning of the disk that the records
to map so they don't have to have the char * string for every record in
our stored logs. Use it as some sort of compression.  We've mostly been
discussing about how nice it would be but how many issues there are with
keeping our map up to date.  If you had any ideas regarding that, it would
be really nice.  The goal of this audit fs is to decrease what it takes
for records to be generated, decrease the amount of space records take up,
and decrease audit log search lookup times.

One thing Im interested in researching, and Im not sure if has been
something discussed yet, but I was wondering about the percentage of
records that have related paths in a row.  That is -- the path
"/home/arr/freakydeak/" is used in some way shape or form by N number of
records in a row or in a span of a period of generated logs.  It could be
"/home/arr/freakydeak/t.c" or "/home/arr/freakdeak/yo/there/" but they are
related and major portions of their path can be matched.  I know people
use a single pathname cache for some of this.. but what if we used two
caches?  The initial cache would be used to store pathnames generated by
recent logs (based on the N number of records that contain related paths
in a row).  This would increase related repeat lookup speed.  The second
cache would be used for it's intended purpose like in Logan's email.  I
don't really have any logs to do analysis on to see what type of pathname
to records correlation i can make... so Im actually kind of asking if
anyone has any non-critical logs they could share with me so that I could
work on this idea?

Cheers,
Andrew



On Fri, 9 Nov 2001, Ilmar S. Habibulin wrote:

:
:
:On Fri, 9 Nov 2001, Andrew R. Reiter wrote:
:
:> Since you mentioned you did this from experience, can you share with what
:> you used as generic identifiers before?
:I mensioned, that i didn't think about generic identifier, because i used
:special flags on files, which causes audit subsystem to log read, write or
:execute operation. And i made hooks in syscalls, some of them have 'char
:*path' parameter, some of them have only 'int fd'. So i think, that if new
:audit subsystem must register all events, then it is the easiest way to
:register kernel fs-specific identifiers. For ufs they are device and
:inode. And this approach is simular to machine/fs/protocol specific data
:poinetrs in kernel structures. Just look at them - they have some type
:field, some common fields and type-specific field, which is handled only
:by specified driver, not by generic kernel routines. And i propose
:something simular.
:Sorry, but i can't help in figuring out needed identifiers, i know only
:ufs a little bit.
:
:> I had been wondering about how this would impact something like a heavily
:> loaded web server or other type of server that might create any number of
:> files/inodes, etc.. Perhaps if we can compress the relative path and be
:> able to do a hash on that, and then just worry about filenames
:> specifically it might help us.
:Are you wondering about impact of regitering or identifier-to-path
:translation? I have 3 types of object audit: create, access and delete.
:Access audit also was devided to 3 types: read, write and execute. But in
:order not to trash logs and slow down machine, i used special flags. With
:these flags you can mark files of interst, and all accesses to these files
:will be logged.
:Registration of all operations is much more harder requerment. It would
:not be suitable for all environments. So maybe review my approach and
:implement it togather with reg-all?
:
:
:To Unsubscribe: send mail to majordomo at trustedbsd.org
:with "unsubscribe trustedbsd-audit" in the body of the message
:

--
Andrew R. Reiter
arr at watson.org
arr at FreeBSD.org

To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-audit" in the body of the message