Auditing - Snare, LAuS, SELinux

Jonathan Abbey jonabbey at arlut.utexas.edu
Thu Aug 26 00:08:35 UTC 2004


On Thu, Aug 26, 2004 at 01:36:23AM +0200, Olaf Kirch wrote:
| 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.

Sure.  As I said, I imagine that prefix and suffix testing would be
adequate for the vast majority of use cases.

| > 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).

Ah, okay.

| 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).

I assume you're talking about the

        testb $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT),TI_flags(%ebp)
        jnz syscall_trace_entry

stuff in /arch/i386/kernel/entry.S and succeeding?

I'm afraid I'm not literate enough in either the kernel's low level
operations or in its history to understand what it is about this
sequence that is novel.. it seems a straightforward branch in the
entry code.. had that branch already been paid for in an earlier
implementation?

 Jon

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

-- 
-------------------------------------------------------------------------------
Jonathan Abbey 				              jonabbey at arlut.utexas.edu
Applied Research Laboratories                 The University of Texas at Austin
GPG Key: 71767586 at keyserver pgp.mit.edu, http://www.ganymeta.org/workkey.gpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20040825/803d8549/attachment.sig>


More information about the Linux-audit mailing list