Auditing - Snare, LAuS, SELinux

[Olaf Kirch]

On Wed, Aug 25, 2004 at 04:45:31PM -0500, Jonathan Abbey wrote:
> Snare does do preliminary filtering in the kernel, deciding which
> syscall audit records should be passed to the userland based on what
> objectives are specified to the daemon.. i.e., if you don't specify
> any filters on open(), no open syscall audit record will be passed to
> the daemon.

I noticed that. It is still little solace if you're required to audit
network configuration ioctls (as mandated by CAPP), and need to wade
through all the terminal related ioctls in user land. Or if you want
to audit all file system calls where the caller's uid != euid.

Doing regular expressions in user land sounds nifty - but is that really
essential? I think most of the time people will want to audit based
on the directory hierarchy, e.g. "all of /etc and /usr except /usr/tmp"
and stuff like that. That requires no regexp matching.

> |  -	intercept system call on entry, copy arguments from registers
> |  	to some internal per-process structure.
> |  -	in copy_from_user, check the source pointer against all
> |  	arguments in above structure
> |  -	if we have a match, kmalloc a suitable chunk of memory and
> |  	copy the argument
> |  -	on the way out, call the audit filter to find out if we need
> |  	to audit the syscall. If yes, build the audit record.
> |  -	When building the audit record, check if we have a copy of
> |  	the argument. If not, we aborted early, so get the argument
> | 	now.
> 
> Why kmalloc/copy in copy_from_user when we've already copied the
> arguments from registers to a per-process structure?

Mostly because the structure that copy_to_user copied to will have
been clobbered by the time the system call returns (e.g. because it was
sitting on the stack).

> | The down side is obviously that you have to put a branch into copy_from_user,
> | which many people will not like for performance reasons. Obviously, some
> | clever magic is needed here.
> 
> Only if you are running with audit enabled, yes?  I don't know how

Yes, but from a distributor's point of view we want an audit solution
that we can enable in all our kernels without a negative impact on
performance. We cannot do a separate audit-enabled version of every kernel :)

So when it comes to putting branches into commonly used code, there's
no difference between auditing enabled or disabled (check the way the 2.6
kernel intercepts the system call on the way in and out - everyone accepted
that change because it didn't cost any additional cycle in the system
call entry and exit code).

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