Jesse Pollard wrote:
> At the present time I don't know the exact mechanics of it's creation, but
> it is somewhere in the setsid call. The manpage doesn't currently indicate the
> restrictions (not all, anyway) on creating a session, but it should be
> restricted to just root privileges - or some capability entry.
It isn't. It's a session ID that is associated with each tty. So for 1 X
session I could have many session ID's. The sessions are not associated with
an authorization -- in fact, I can say, su to a user, create an Xterm and that
user would be logged as creating a new session. That isn't what we want for
auditing.
For auditing, tracking needs to be done per user and only after that user
has been has been 'identified and authorized'.
>
> No - LUID's repeat - two jobs may run, (two telnets, or telnet and cron, or...)
> with the same LUID. These two jobs can only be uniquely identified by the
> session ID, if they both run at the same time. This gives the auditor a way to
> connect the events in a sequence that otherwise cannot be connected (at least
> not easily). It prevents the sequence of process activations from becoming
> confused.
--- The events can be tracked via forks/execs. When I su to another user withing my current 'session', then spawn an xterminal, All I would see in the log is that user "new" now has started a session. I'll see no idea that it was really user "old". Scenario: user "old" manages to create a SUID "new" program in one of new's directories. New doesn't notice it -- it's one among thousands. Possibly create it in /tmp. The next day, "old" uses the suid script to become "new" -- uses the 'setuid and setruid' to the effective uid. User then creates an Xterm and does nasty things.Now admittedly, we can likely trace that back depending on what auditing information we have collected, but it certainly is no simpler than tracking logins, forks and execs for a given user. The pid and ppid would be recorded on each.
> I know - this is based on the way the UNICOS MLS audit entry tracks user > activity. The accounting is a secondary ability that just falls out from > the use of a sessionID. --- Sessionid has existing semantics. I assert that we shouldn't change the existing semantics w/o breaking existing code that relies on its current behavior (e.g. X).
-- 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 Apr 23 2000 - 21:00:09 EST