Re: New development
On Monday 12 September 2005 14:17, Amy Griffis wrote:
> This is very important and was missed in that last development
effort.
> The audit system currently collects the first 4 arguments. The way
> it collects them is in this case is the string's address. This is
> totally useless. You do get to see what was executed because a path
> record is emitted. However, there are a lot of times that you want
> to know the parameters passed.
Could you clarify whether this is important for a CAPP certification,
or for general audit usage?
General usage. I've already received emails about this omission from people
that will be using the audit system.
Another idea is aliases for groups of syscalls. You can currently
specify several syscalls in a single filter rule, which shortens your
kernel rules list. An alias would make the rule more concise, and
could be implemented in auditctl without any kernel changes.
OK, I'd like to have a separate mail thread for user space enhancements. I
have a list of those as well and limited this thread to kernel changes. I
like the idea though.
One other nice-to-have is the ability to specify some symbolic
constants in rules, e.g. ioctl control constants.
Right. again user space. I am wanting to do that as a separate thread in about
a week. I want to get LSPP stuff out later this week.
I'm also trying to visualize where the filesystem audit work fits
into
this schedule. If it's based off of Inotify, or if we end up needing
a solution based on code that hasn't been written yet, would that
really go into the 2.6.9 series?
I think this is a dwmw2 judgment, but my guess is no. That code is likely to
be rawhide unless RHEL4 picks up inotify. Until then, we have something that
works. Don't underestimate its importance based on what I just said...FC4
users do not have a working audit system. Rawhide doesn't either.
I think Tim and I are both pretty interested in working on that.
But
if it's not targeted for 2.6.9, do we need to change gears
temporarily?
The auditfs code is on the critical path. That needs to be done asap. If
anyone has time or ideas about performance, they should let the mail list
know. Maybe there's times when you are waiting for feedback that you might
want to look at it a little.
If we haven't finished 1-5 by the time Dustin's patch is
ready, do you plan
to have development going on in multiple kernels at once?
I'd rather not. Dustin's patch introduces a new message number. I need to see
where we are on filtering to decide what the numbers are going to look like.
That in turn depends on filtering operators. There are some pre-requisites
that need to be satisfied before inserting his patch. I also see the work on
1-5 as a way to make progress while allowing time for auditfs to get
upstream.
I also did not mention bug fixing in the mail from this morning. We are
starting to get several bugs that are found and unresolved.
-Steve