Re: Proposal "LUID"

From: Jesse Pollard (pollard@tomcat.admin.navo.hpc.mil)
Date: Mon Apr 17 2000 - 14:16:06 EST


Linda Walsh <law@sgi.com>:
> Jesse Pollard wrote:
> >
> > 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.
> --
> Actually the creation of a session seems to happen when you disassociate
> from a tty. Here's the code for set:
>
> asmlinkage int sys_setsid(void)
> {
> struct task_struct * p;
> int err = -EPERM;
>
> read_lock(&tasklist_lock);
> for_each_task(p) {
> if (p->pgrp == current->pid)
> goto out;
> }
>
> current->leader = 1;
> current->session = current->pgrp = current->pid;
> current->tty = NULL;
> current->tty_old_pgrp = 0;
> err = current->pgrp;
> out:
> read_unlock(&tasklist_lock);
> return err;
> }
> ---
> It sets up a new process group as well -- both become equal to the
> pid of the calling process. There seem to be no restrictions on when it is
> called. This is not suitable for requirements of the CAPP or LSPP.

You're right - this is not suitable.

>
> > > 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.at
> ---
> Whether 'X' uses it or not I really don't know. But the point is the
> current semantics aren't what you or I want. CAPP requires auditing by Login-user ID,
> not by session #. If you log by session #, you would have to go through an exhaustive
> proof that *all* sessions can be tracked back to a an authorized login (cron or at).
> Interestingly enough, for 'at' IRIX encodes the LUID in the name of the 'at' job.
> If cron doesn't have a similar mechanism, to meet requirements, one might disable
> user-level cron jobs.
>
> >
> > 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 ...
> ---
> It is not an either/or thing. Feel free to propose your session ID
> and throw in the code. I don't care one way or the other. I can see a use
> for it. I wouldn't be against it. But it's not what I am wanting. I would
> add that having such a session_id would be a useful addition to auditing, but it
> isn't required to meet the CA or LS Protection Profiles.

true - I don't think it is required.

> > 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).
> ---
> Maybe we should use a "GUID" -- Globally Unique ID. :-) (*danger will
> robinson*)

ummm actually a YAUID (Yet Another UID :)
 
> > 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.
> ---
> It would be very useful in report generation, but given the right post-processing
> tools to create the back (fork) chains sorted by LUID and login time one
> can also create the same report.

The back fork chains are what is a booger to implement efficently. That was the
only reason to have a "session ID", even if only in addition to the LUID. Untangling
the fork chains gets to be very memory intensive, especially if you are tracing a
trojan daemon.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

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:11 EST