RE: audit 0.6 release
--- Leigh Purdie <Leigh.Purdie(a)intersectalliance.com>
wrote:
... Although this is what I'd LIKE solaris
to provide me, unfortunately, it
doesn't actually provide the requested path
My bad. It's been 15 years since I worked on
that code, and it appears it's been "improved".
> Meeting the CAPP requirements as well as being
> useful to an auditor adds a certain spice to the
> design.
*laugh* What an amazingly graceful way of implying
that CAPP and real-
world user requirements are not always perfectly
aligned. Very true. ;)
Just out of curiousity, what is being used as a
security model for the system? A lot of the issues
regarding what people think would be useful and
what the system can provide easily are
manifestations of poor education about what the
system is actually up to. You wouldn't believe
how long it took and how many high powered NSA
experts required convincing that file names are
not connected to the files they name.
I don't personally have a problem with a
subject/object approach, but I
think that a level of wildcard audit filtering is a
critical
precondition for a successful (and effective!) audit
implementation.
I haven't actually ever done this, but I can
see how it could be done ...
Create a function that is handed a list of strings
and/or substrings to key on. Call it during
directory lookup for each component, and remember
if you get any matches. On syscall exit generate
a record if there were any, and include an
indication in the record of which string you
matched. Userland filtering still has to determine
if the wildcard is truely matched, but it's looking
at a small fraction of the records it would have
to otherwise. This is consistant with the notion
that what you really care about -in this case- is
the path name, not the object.
I leave the issue of what to do with relative
pathnames and the current working directory as
an exercise to the reader.
This could conceivably be done is through object
inheritance on
directories (like Windows -
c:\path\to\secretstuff\*), or through path-
name filtering in the kernel.
As above.
With a wildcard-based rule system, a security
auditor can put a rule in
place like match=.*/NOFRN/.*, and tell departments
that auditing is
available for their NOFRN data - all they need to do
is place it in a
'NOFRN' subdirectory with their directory structure.
Which is the same as telling them that if they
want to be sure it isn't audited to avoid that
string. When did end users start following
instructions, anyway?
With a object-inheritance structure, you'd either
have to explicitly
establish a rule for each new NOFRN directory, or
modify your directory
structure (and perhaps user practises somewhat) to
accommodate auditing
(which may not be a bad things in many
circumstances).
An attribute that says "audit every lookup here"
would suffice, and in fact the audit-by-label LSPP
requirements pretty much requires all the mechanism
you need to add this bit.
Neither approach is bad - but since we're still at
the decision-making
point from a filtering perspective, I thought I'd
highlight some
potential repercussions. :)
The Irix experience is certainly that the best
place to filter is on record generation within
the kernel. It is vastly preferable to make the
kernel checks and avoid creating a record than
to go through the motions of generating records
you might want and having a user process throw
them away.
=====
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________
Do you Yahoo!?
All your favorites on one personal page � Try My Yahoo!
http://my.yahoo.com