"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.
> Ok, now you get to flame away. What am I missing?
--- No flames -- valid possibility.Some of these are designed for uptime measured in years. Just looking around here on campus, I see systems that have been up for about 9 months. Now on one of our systems that's only been up for 27 days, a mail hub, it is up to PID 10.2 million. Now let's see...if that system stays up for 2 years, that's over 250M PIDs. At a site with reserve power backup I wouldn't say it's unreasonable to expect uptimes measured in years. Tracking through that and the requirements to save years of audit data is not something customers would like.
Anyway the requirement is to write an audit record that contains the luid. I don't think postprocessing qualifies. If at any time during those years, if auditing for forks got turned off (the customer might not want that level of detail or the Gigs it takes to store it), the whole hypothesis fails. Even at 10 bytes/audit record, that 2.5 Gig just for the fork chain -- ignoring uid changes or any other record.
The CAPP states that the end user can select what is audited. Forcing them to collect audit data they don't want would likely be viewed as noncompliance.
The requirement also states:
"5.1.1.2 The TSF shall record within each audit record at least the following information:
a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event;" --- To meet this requirement with your algorithm would require a full traceback for each audit record emitted. I assert this would *really* slow down the system.
-l
-- 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:13 EST