9:53 a.m.
On Wed, Aug 25, 2004 at 01:02:33PM +0200, Olaf Kirch wrote:
| Hi,
|
| sorry for taking so long to reply - audit has taken a back seat for the
| past couple of weeks for me.
Hi, Olaf. I'm a reasonably low-level contributor to the Snare
project.. hope you don't mind my 1.5 cents here.
| > 2) Rik's implementation
| > ++ Now part of kernel 2.6.6!
| > + Integrated within SELinux
|
| I think that's a neutral, or even a minus from my perspective. I would
| very much prefer an audit solution that is agnostic of the security
| infrastructure you use.
|
| You may want to use auditing with subdomain, or you may even want to use
| it without any security modules at all (because frankly, SElinux sucks
| performance-wise, and it's not terribly stable yet either)
Rik's audit work can be used without the bulk of SELinux, as I
understand the implementation?
| > - Very basic daemon capabilities (filtering / reporting / etc.)
| > - Two-part auditing (event, then returncode as separate info), which
| > makes the daemon side a little harder
|
| Yes, that is something that needs to be changed. If you do stuff like
| switching audit files on the fly (i.e. writing to N different buckets),
| the records for call and outcome may end up in two different files,
| which is hard to deal with in the user land tools.
I would also expect that splitting the auditing like this would
unnecessarily increase kernel/userland traffic, without significantly
reducing the memory loading in the kernel.
| > 3) Snare's kernel component
|
| Okay, so I'm going to comment on snare. Please don't take anything
| I say below personal, Leigh... also keep in mind that this applies
| to when I last looked at the code over a year ago; maybe you've got
| all of these issues fixed by now. Maybe I'm even mixing up some details
| with syscalltracker.
|
| > - Programmed by a team that really would prefer NOT to be doing things
| > in the kernel. :) .. but have MANY years of experience in managing audit
| > log data in high security organisations.
| > ++ Integrated into SGI Altix
| > ++ Integrated into some HP distributions
| > ++ Required as part of US DoD COE, and NASA.
|
| I think DiiCOE is wrong in mandating specific implementations and
| package names.
|
| > + Great daemon & GUI (though, I'm biased ;)
|
| I looked into snare a year and a half ago when we evaluated different
| audit solutions, and I thought the audit record format, and the daemon
| were rather complicated. One thing that struck me as particularly painful
| was the fact that it wasn't written with performance in mind. Snare
| does almost no filtering in the kernel, so all data has to travel up to the
| daemon, where it gets processed. Rule evaluation isn't very fast either,
| for instance, rules including a user name would be evaluated by doing
| a getpwuid on the uid doing the system call, and then a strcmp was
| done. Which is also fairly prone to deadlock if you start auditing system
| services such as nscd.
Well, the Snare kernel doesn't audit its own audit daemon, which
prevents the most obvious cause of runaway auditing. The audit daemon
as of Snare 0.9.6 now maintains a simple in-process cache for user and
group names to mitigate nscd spamming as well, though it could be
expanded significantly beyond the simple two entry cache it uses at
present.
The audit daemon's efficiency has been increased by a factor of 10 or
so in the recent code, the username/groupname caching being part of
that. There's still more work to do, though, particularly at the
kernel/userland interface.
| The kernel code also suffered from several major problems; it was messing
| around with the system call table, which is a major no-no (it doesn't seem
| to do that anymore). It also covers just a fraction of the system
| calls you need to cover in order to actually achieve CAPP certification.
| It also doesn't deal with the problems of system call arguments being
| modified between performing the system call, and building the audit
| record (think of shared memory - the string passed into open() may change
| while your process is in the kernel). It also doesn't even attempt to
| resolve the path names passed into system functions, which is rather
| useless. It also lacks a login id, which is crucial for CAPP compliance.
All true in the current implementation. I looked at the argument
locking issues somewhat when I was adapting Snare 0.9.6 to the Fedora
Core 2 kernel, but it's clear that handling that will require a
significant rework of a lot of the in-kernel implementation.
The login id tracking is a more significant shortcoming of Snare,
obviously, as well as the inability of the Snare userland tools to
restricted auditing to certain process trees.
| From an evaluation perspective, I think the snare daemon also didn't fare
| very well when it came to assuring that audit records never got lost.
|
| One major question is portability - for laus we had to support
| i386, x86_64, ppc, ppc64, s390, s390x and are currently doing ia64.
The Snare kernel patch has portability covered pretty well these days,
actually, as it just instruments individual syscalls rather than
trying to hook into the platform-specific syscall mechanisms. I've
built Snare-equipped 2.6.[678] FC2 kernels for x86_64 as well as x86,
without any issues.
Instrumenting individual syscalls makes it a pretty invasive patch, of
course.
| I liked the GUI though; that would be something that'd be nice to have.
|
| > * Although selinux and auditing have a pretty common user-set, and I
| > think they can work well together, I'm worried that selinux may not
| > supply us with all the information we need (eg: will all 'denied' calls
| > be passed to audit?)
|
| That is my concern with selinux based auditing as well. By placing audit
| hooks inside selinux (or the LSM framework in general), we will only be
| called by the time the kernel needs to make a policy decision.
|
| What I am wondering is whether we actually need selinux or the LSM hooks
| to make a decision whether to log a call or not. Rik's code is able to
| catch all system calls on return, which is the logical place to make
| a decision on whether to create an audit record or not. The only
| thing we really need is to collect system call arguments as the are
| consumed by the kernel (i.e. copied from user to kernel space).
The biggest dissatisfaction we have with the 2.6.6 audit framework is
that syscall arguments are not logged in the event of early abort of
syscall processing due to a lack of capabilities, etc. We read NISPOM
Ch. 8 as requiring detailed logging of failed attempts to access
"security-relevant objects". A non-root user attempting to do root
actions like 'chroot' is a pretty silly user, but NISPOM would like to
know that sort of thing.
Therefore, we would prefer to see a mechanism in which all auditable
parameters are copied to kernel space up front, and that the syscalls
would then be written to use the pre-copied parameters rather than
doing direct mapping from user space. There would obviously be
certain kinds of parameters that could not reasonably be audited in
such a framework, but that will be true in any prospective auditing
system.
That makes for a more invasive patch, though, with different code
paths for audited and non-audited processes.
| Maybe there's even a way we can tap into copy_from_user pretty much
| the same way Rik taps into getname.
Hmm.. we could perhaps add a identifying tag as an additional
parameter to copy_from_user, so as to allow tracking of multiple
parameters copied from user space, but that still wouldn't support
full auditing of preemptively rejected syscalls.
| > Without breaking any confidentiality agreements / product plans native
| > to Redhat or SuSE, do you think that there might be scope for a combined
| > way forward? If so, do we:
| > * Adopt Rik's stuff as a base, and merge the useful bits of Snare and
| > LAuS into it?
| > - Olaf: Will SuSE be taking on SeLinux for 2.6.6+? Do your SELinux &
| > audit customers generally overlap?
|
| We have plans for using SELinux, but I really want an audit framework
| decoupled from the security module.
|
| With Rik's stuff in 2.6, I think we have a foundation we can build upon.
| Fortunately, the intercept mechanism Rik used is more or less what we
| did for 2.4, so that's good (our 2.6 implementation is different, but
| that doesn't mean we have to keep it).
|
| > * Can we make things generic enough to cover pluggable system call
| > interception?
|
| What do you mean by this?
|
| Cheers
| Olaf
| --
| Olaf Kirch | The Hardware Gods hate me.
| okir(a)suse.de |
| ---------------+
--
-------------------------------------------------------------------------------
Jonathan Abbey jonabbey(a)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