Auditing - Snare, LAuS, SELinux

[Leigh Purdie]

On Thu, 2004-09-09 at 09:49, James Morris wrote:
> On Wed, 8 Sep 2004, Stephen Smalley wrote:
> 
> > > Similarly, implementing a policy of 'audit all attempts to write to files
> > > in /bin' implies a non-atomic operation, where, e.g. a new file could be
> > > written to /bin after the xattr tagging started.
> > 
> > An inheritance issue, similar to ACLs or SELinux attributes.  Newly
> > created files could inherit the audit attribute of the directory in
> > which they were created by default.
> 
> Let's say you have a policy which says that you had to audit anything
> which happens to the file /foo/bar.txt , but the policy does not require
> anything else under /foo to be audited.
> 
> The administrator deletes /foo/bar.txt.  This is audited, as it was
> labeled during installation.
> 
> The administrator creates /foo/bar.txt.  This is not audited, as the file 
> does not inherit a security.audit flag from /foo.  Further changes to the 
> file are not audited.
> 
> In practice, the system could be implemented to avoid this issue, but it
> is a potential pitfall.

I'd have to agree with James here. Conceptually, I love the idea of
auditing attributes applied to files. It fits in really nicely with the
way the 'programmer' side of my brain feels things should work.

In practise though, it's an arse. Windows implements something like
this, and it's exactly the sort of thing that James highlights that
causes problems in large organisations.

Stephen - have a think about an example using NOFORN in your
organisation. If, rather than telling data owners to jump through a
bunch of hoops to get their new NOFORN data audited effectively, that
all they had to do was make sure that the directory they put the files
in was called NOFORN and the audit subsystem would pick it up
automatically, then think how much administrator time and effort might
be saved.

An audit objective would be set up with a filter of something like:
userid != 0
file path = */NOFORN/*
mode = read-only
criticality = MEDIUM

or perhaps something like:

userid != 0
group != groups,that,can,access,this,data
file path = */NOFORN/*
mode = write
criticality = HIGH

> > > I think it's better to have a centralized policy which can be updated
> > > atomically and applied within the kernel, rather than being distributed
> > > with each object to be audited.
> > 
> > Sounds like you are arguing against using attributes for SELinux too ;)

Very good point! I can't think of a reasonably coherent defensible
position at the moment for why ACLs and Auditing are REALLY that much
different. Anyone else want to jump in here?

About the only things that spring to mind relate to complexity at this
point:
* object ACLs are very well understood, and there have been a bunch of
cross-platform tools built up over the years to effectively manage stuff
like this. SELinux builds (significantly!) on this work.
* object ACLs need to be managed on an individual basis by lots of
users.
* Auditing is generally under under the control of a small core of
administrators, and doesn't have the existing tools to effectively
manage/control audit flags.

If we step back for a second, and try to challenge these assumptions
though:
* Why should auditing be under the control of an 'elite few'?
- Dunno. One reasonable reply might be that auditing has fairly
significant resource implications, and that you might want to control
this sort of thing (pretty poor reason though).

* What's wrong with building up the tools that will allow us to
associate an auditing capability on a per-object basis?
- Nothing... though the idea might (at this stage) be consigned to the
'too hard' basket - we may be able to come up with an efficient audit
implementation with significantly less effort by taking a slightly
different approach.

Thoughts anyone? If we decide to go down the object-association path,
this is a pretty good argument for a SELinux tie-in, as many of the
applications required to manage per-object settings are already covered.

> Another potential issue is that file auditing would then be limited to
> filesystems which support extended attributes and a security namespace
> handler.  I don't know if this would be a problem for certification.

Very good point. Although if anyone really wants to audit a FAT file
system under linux, I reckon they're asking for trouble in the first
place.... ;), there might be situations where something very similar
comes into play - eg: read-only file systems.

A good example might be a signing key stored on CDRom or something. We
might want to audit access to it, but can't zap attributes onto an
iso9660 file system. Whereas a filter of /mnt/cdrom/key.txt might work
reaonably well.


So, questions/summary:
* Object-based auditing, or filter-based auditing?

- Object based:
  - Good reason to stick with SELinux
  - Probably a bucket-load more programming than filter-based

- Filter based:
  - file-system agnostic.
  - SELinux independent.
  - effectively maintains the 'super user only' paradigm of audit
control, for good or evil.

I'd recommend filter-based, as it works better than object based
auditing in all the implementations I've come across. However, that's no
reason not to challenge our assumptions. Thoughts?

L.
-- 
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/