On Sun, Apr 16, 2000 at 12:00:11AM -0700, Linda Walsh wrote:
> Jan Harkes wrote:
> > The problem I see with LUIDs, which PAGs avoid is that with a user-id is
> > is impossible to distinguish applications that were started by a user
> > logging in at different times, or in multiple simultaneous sessions.
> > i.e. a valid user who logging in from the console compared to a user who
> > just managed to start a compromised shell by hacking some daemon.
> ---
> Accounting could be configured to record 'exec's, ppid and pid so
> a chain of actions taken by a given login session could be traced.
>
> I'm not sure I see a benefit in this adding a new counter. Seems like
> this would just invite someone to loop on calling newpag. Wouldn't that
> generate alot of "paperwork" (ok, computer running through loops after loops
> in a log to reconstruct a user path). Yes they could do the same think with
> a 'fork' loop, but that's already a problem. I just don't think the PAG
> solution solves anything.
For me it does make a big difference.
Coda doesn't automatically allow access based on the local uid, access
permissions are based on a token the user has passed to the cache
manager through the kernel, which is tagged with his credentials. At
the moment we use the fsuid, and while this works for most cases it is
too permissive for many tasks.
One example is sendmail, it needs to deliver mail and drops it's
privileged (seteuid) before delivery. In this case all users need to
have a token on the mailserver to get the mail delivered, which boils
down to keeping every password somewhere and pass new tokens to the
cache manager when a token expires. If I modify sendmail to avoid the
setuid and give `uid 0' just enough rights to update mailfolders, all
other daemons also get the right to access them, not a good thing
either.
The problem with uid/gid/sid/ppid/pid's and the fivehunderd other ids
that keep track of sessions, is that they are either easily modifyable
(by root), or are not sufficient to keep track where a process
originated. f.i. init inherits orphaned child processes when the parent
exits, so the ppid is useless.
Capabilities have helped, as daemons don't need to run as root anymore
and the ruid/fsuid have become reasonably usable. As long I have source
to the apps, everything is possible ;)
As far as the paperwork is concerned, Coda wouldn't have to audit the
user's path. If someone switches to a new pag, he would lose all access
rights until a new token is passed to the cache manager.
If it were possible to do effective auditing by using the existing id's,
the LUID wouldn't be necessary either.
Jan
-
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:08 EST