Re: Auditing - Snare, LAuS, SELinux
by Jonathan Abbey
On Wed, Aug 25, 2004 at 05:44:46PM +0200, Olaf Kirch wrote:
| Hi,
|
| On Wed, Aug 25, 2004 at 09:53:44AM -0500, Jonathan Abbey wrote:
| > | 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?
|
| I seriously hope it can.
|
| > 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.
|
| I seriously believe that filtering in the user land is wrong. At most,
| the daemon should shovel fully cooked records from the kernel into
| the audit trail files and potentially other consumers (such as IDSs).
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.
| For performance reasons, filtering should happen in the kernel module, so
| we avoid costly memory allocations and kernel-user land copying.
To be sure. The big win for Snare in doing userland filtering is the
ability to apply regular expressions, but as long as you have support
for prefix and suffix matching in the kernel, you might not gain all
that much for the extra cost, flexible though it is for the user.
| > 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.
|
| Same for CAPP. I'd have to go and see how hard it would be to adapt
| the laus module to this infrastructure.
|
| > 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.
|
| Not sure if I understand what you intend to do here. Some audit
| implementations I looked at created wrapper functions that copied
| arguments from user space and did a set_fs(KERNEL_DS). This is obviously
| a simple way of doing it but it creates security problems if you audit
| system calls that pass structs with pointers in them. That way, you could
| never audit ioctls (besides, there are many ioctls that don't follow the
| convention of including call direction and argument size in the ioctl
| number, so you wouldn't know the argument size beforehand).
Well, right.. I expect that there would have to be context sensitive
code to decide which arguments should be considered auditable. If we
can't get a clean snapshot of a syscall's arguments for such practical
reasons, then the auditing framework should be cognizant of that.
| > | 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.
|
| Why not? The basic idea is simple.
|
| - 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?
| This is mostly generic; it doesn't even involve selinux.
| All you need is a table mapping system call numbers to argument types,
| the way we did in laus. This allows you to audit _any_ system call
| without having to touch each and every kernel function.
| (You need some special cases, because some arguments need to be copied on
| their way in, such as the argv array in execve - when we return, argv
| no longer points to anything useful)
Right.
| 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
often copy_from_user is used outside of the syscall argument
processing case, but if there's a distinction to be drawn between
conceivably auditable use and never-auditable use, one could split
copy_from_user and provide an audit-enabled variant for syscalls.
| Another extension along the same line would be to add a hook to the namei
| functions so that we get the dentry and thereby the resolved path, rather
| than some more or less useless string.
Right.
Thanks,
Jon
| 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
20 years, 11 months
- 7
- 13
Re: Auditing - Snare, LAuS, SELinux
by Peter Martuccelli
On Wed, 2004-08-25 at 13:13, Kevin Till wrote:
> On Wed, Aug 25, 2004 at 11:33:28AM -0400, Peter Martuccelli wrote:
> > I have everyone on the Cc list entered on the linux-audit list except
> > for Olaf and Ktill - if you want me to add you please let me know.
> >
> Peter,
> please add me to the linux-audit list.
Done.
> Also, do you know whether LauS works on RHEL3 update 2 on ia64 platforms?
U2 had no support for IA64 code. The latest LAuS kernel code which has
all of the latest IA64 patches applied to the U3 kernel is on my people
page;
http://people.redhat.com/peterm/audit-kernel/
Most of the IA64 patches did not make the U3 cut off date, so look for
new kernels on my people page until U4 ships.
If you need anything else please let me know.
Peter -
21 years
- 1
- 0
Re: Auditing - Snare, LAuS, SELinux
by Jonathan Abbey
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
21 years
- 2
- 1
New mailing list
by Peter Martuccelli
Hello,
This is the list we had discussed last week. People should have
received email informing them that they are on the list. If people on
the list know of others that are interested please forward the email you
received from linux-audit-request, or have them email me directly at
peterm(a)redhat.com.
I have attached a write up of what we have so far in the upstream
kernel. It is still being worked on but I hope it will answer some of
the questions I have been receiving.
Feel free to comment on any kernel and/or user space issues,
suggestions, proposals.
Regards,
Peter
21 years
- 1
- 0
- ← Newer
- 1
- Older →