3:59 a.m.
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(a)suse.de |
---------------+