audit 0.6 release

[Casey Schaufler]

--- Leigh Purdie <Leigh.Purdie at 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 at schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
All your favorites on one personal page – Try My Yahoo!
http://my.yahoo.com