"David A. Wagner" wrote:
>
> Oh boy, yet another uid, for those of us who weren't already
> confused by the existing bestiary of uids and gids. :-)
>
> I'm sure I'm missing something, but don't you get all the same
> benefits (and more) from the following, conceptually simpler
> mechanism:
> Whenever a process changes any of its uid's, record its
> pid, old-uids, and new-uids as an audit event.
> Record all process-creation events, along with where they
> inherited their uid's from.
> Special processes like /bin/login can record extra events
> whenever they like (e.g., where they would have called
> setluid()/newsess_id()).
> This gives you a tree of audit events.
> Now, whenever you want to know the luid or sess_id for auditing
> purposes, you can just walk back the tree in a user-level daemon.
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. Consider a system that's been up for a
year, with a user logged in for the past month. If that user
performs some evil deed, you will have to filter an entire
month's audit records (on my system, with just me reading email
and only minimal auditing being done that's 23meg, on our group
server it's 220meg in 3 days) to determine whodonit and the
integrity of those records must be perfect. For a very small system
with an enormous disk and an extremely patient auditor, it
might work. It's not practicle on a real system.
--Casey Schaufler Manager, Trust Technology, SGI casey@sgi.com voice: (650) 933-1634
- 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:13 EST