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...
-
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:16 EST