On Sun, 16 Apr 2000, Linda Walsh wrote:
>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.
That shouldn't happen with session IDs; they should not be associated with a
tty. If it does, then we do need something that is unique to each
login/session that accomplishes that.
> 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.
Follwing fork/exec chains takes too long and requires that audit tools perform a
topological sort to determine which branches belong to a session. It would be
much simpler to have a real session identifier. I've tried to follow these
chains in IRIX, and they almost never work properly (especially when you get
into socket tracing).
>> 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).
I never noticed that X used different sessions - Linux would be the first
one I've seen that did.
If it is necessary to have yet another thing - I would recommend a true session
identifier rather than a LUID. The session ID eliminates having to follow
chains of things like fork/exec/ipc calls/rpc calls ...
Something unique like the current time concatenated with a counter since last
boot would work. At the present time, I wouldn't want the identifier to
repeat within the last 3-5 years (effectively, we are not allowed to delete any
audit logs until the system generating has been removed for at least 1 year).
The full audit trail tracing an event becomes available with a simple select
of a given session ID followed by a sort by time. The result presents all
activity from the instant the session started.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@cats-chateau.net
Any opinions expressed are solely my own.
-
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