> On Thu, 04 May 2000, David A. Wagner wrote:
> >In article <3910C0DC.514A457E@sgi.com>, Casey Schaufler <casey@sgi.com> wrote:
> >> This scheme works just fine when you actually have all of the
> >> audit records available until the end of time. Alas, this may
> >> not always be the case.
> >
> >I think maybe I wasn't clear enough about my proposal.
> >My proposal was to split the luid/sess_id-tracking code up
> >into two pieces: (1) kernel hooks, which generate audit
> >events, and (2) a user-level daemon, which derives and keeps
> >track of the luid/sess_id of each process from the audit events.
> >
> >If all you care about is the luid/sess_id of each process,
> >then that is all that the user-level daemon needs to retain,
> >and there are no worries about large audit logs or long-uptime
> >systems. The audit events need not be retained anywhere once
> >they have been processed by the user-level daemon.
> >
> >The point of splitting it up this way is that it is a more
> >general approach: put the mechanism in the kernel and the policy
> >at the user level. Then, if we want to tweak the policy at some
> >later time, we can just tweak the user-level daemon, without needing
> >to modify the kernel any further.
> >
> >Do you buy it? Am I missing something? I know you have far more
> >experience building these types of systems than I do; maybe there's
> >something obvious I'm overlooking...
--- I guess I'm missing something here -- do people want performance or not? To my mind, keeping an luid and sess_id in the kernel is *trivial*. To do it in a user-land demon *requires* that the kernel would emit audit records for every fork. Now the cost of forks has gone significanly up when all I really wanted was to know when people changed access rights on files.The requirement is that audit be configurable. Sure you could have the userland deamon drop records that weren't wanted, but note that each process will also have its own audit_mask, a 128 bit mask that will tell the kernel exactly what to emit an audit record for.
So under your scheme, the kernel would always emit records for everything and the user deamon would have to keep up by reading *tons* of data, while doing computations on it to decide what pids map to what luid, and what each pid's audit_mask was and only record the requested events and information. That's tons of information sent up from the kernel and filtered by a demon -- with most of the information being thrown away.
Do you realize the performance impact you are talking about by doing userland processing and filtering -- the kernel would be really busy emitting audit records -- I could easily see a 10-30% performance impact. Much of that would be consumed memory bandwidth with the kernel generating data in the range of multi-megabytes/second on a busy multi-cpu system. Multiple CPU's would compete for audit-queue management locks -- *alot* -- The buffers both in the kernel and in the userland demon would be huge. You can only have 1 userland auditd -- the records should be read and written in order. Multiple auditd's would contend with locks in the reading the kernel data. I think cpu, memory and bus bandwith requirements of your algorith make this idea infeasible. The idea with auditing is you want to make it as low impact on the system as possible, like <1%. You don't want audit to get in the way of anything. It should be as unobtrusive or less than process accounting and disk quotas. The last thing you want to do is any real-time processing on the *normal* case. The *user* could write a user-land deamon to do real-time audit processing and intrusion detection, but that would be optional. The kernel should emit binary records (most efficient) and the audit deamon should read them from the kernel, direct them to the audit device (local, NFS, another system, a printer/WO-CDROM...whatever) with no processing/no formatting. Minimal memory impact of the audit demon and minimum CPU impact (unless user *chooses* some sort of realtime processing).
-linda
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:21 EST