New development

[Steve Grubb]

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