Auditing - Snare, LAuS, SELinux

[Olaf Kirch]

On Thu, Aug 26, 2004 at 01:28:29PM +1000, Leigh Purdie wrote:
> Actually, this is the area that probably had the most though put into it
> - the token-based system allows for easy follow-on processing, whilst
> preserving some level of 'real human' readability, and the capability to
> extend the fields, without breaking any assumptions made by follow-on
> processing scripts.

I'm very much in favor of binary formats, actually. printf formatting
wastes a lot of time and space on stuff that nobody's ever going to look
at anyway, except using a toolset. I agree that making it extensible is
a good idea; the laus format currently isn't.

What we're currently doing is a generic header that's the same for
all system call audit records, followed by the list of arguments encoded
as TLV.

Concerning the snare format, what I was actually wondering about was
the fact that you seem to have several different classes of records
for system call auditing.

> > It also doesn't even attempt to resolve the path names passed into
> > system functions, which is rather useless.
> 
> Actually, it sent the PWD, and the path sent to the system call, to the
> audit daemon. The audit daemon then used a modified realpath() to bring
> them together. So not in the kernel, but it did happen at the point of
> filtering.

There is also a race condition here - by the time the audit daemon puts
together the full path, the file system may have changed already. On a
slow file system such as NFS, the delay may be long enough for attackers
to pretty reliably conceal their tracks (symlink flipping on NFS is a
fairly well-known technique to skew the odds in a file access race
condition towards the attacker).

> Yes. This is actually a design feature. The administrator could choose
> how hard snare tried to ensure audit records weren't lost, by bumping up
> the 'linked list' cache between kernel and daemon. So on systems where
> audit was useful, but not critical, low effective resource usage
> resulted, with a reasonable chance of dropping events (eg: 2% in high
> load situations). On systems where audit was more critical, the linked
> list RAM is bumped up, which means a much reduced chance of audit loss.

But the CAPP requirement is that you never lose a single audit record.
And depending on what you audit, your message queue will never be long
enough. That's why I think a process trying to deliver an audit record
should stall if there's no room in the queue. In fact, that's a fairly
simple way to deal with terminal audit problems as well - if the disk
fills up, the audit daemon simply stops accepting new events from the
kernel, causing all audited processes to stall.

> Whilst we should have a 'must try as hard as possible to deliver audit'
> facility to satisfy the hard-core, there should also be a 'try to
> deliver audit, but if it's going to slow down the system too badly, drop
> it'.

Agreed. Evaluation requirements and real-world scenarios don't necessarily
have much overlap.

> > Maybe there's even a way we can tap into copy_from_user pretty much
> > the same way Rik taps into getname.
> 
> This doesn't 'feel' like the right place.. but I'm not sure why yet (nor
> can I offer an alternative at this stage).

It surely would be a hack, but a convenient one with a minimally
intrusive patch.

> > > * Can we make things generic enough to cover pluggable system call
> > > interception?
> > What do you mean by this?
> 
> I was just thinking of making the 'syscalltrack' guys jobs easier - ie:
> provide a mechanism whereby an external entity can 'request' that an
> (almost) arbitrary system call be monitored. Not a priority though.

Ah, I understand. Yes, having that would be nice.

> Pete then came in with:
> > You can make use of SELinux policy files to create rules for
> > generating audit records.
> 
> >From the file Pete attached, I get the impression that file-auditing is
> sorta dependent on selinux. Is this the case, or would file auditing be
> independent of selinux?

As far as I understood from the RedHat folks, auditing files based
on their security labels was what they wanted to do. It makes sense if
you're doing selinux, and a common audit implementation would definitely
have to allow for it (but not mandate it).

What about audit hooks that provide the following services for selinux
and other LSM frameworks:

 -	a function that tells the audit framework
 	"I decided to audit this system call, please do that for me"
 -	a function that tells the audit framework
	"here's an additional blob of information, please attach that
	to the audit record"

Would that be sufficient? What else would be required?

Would it be better to allow selinux to use the generic filtering machinery
of the audit subsystem? In that case, it would need a mechanism to specify
additional bits of information that could be used in filter evaluation,
such as object labels, caller roles, etc.

Olaf
-- 
Olaf Kirch     |  The Hardware Gods hate me.
okir at suse.de   |
---------------+