[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: delegation conflict, background

At 03:23 PM 6/28/96 -0700, Bill Frantz wrote:

>And, given that a user can log on multiple times, the results on the system
>are the same.  

Except in my system (TENEX with the Utah scheduler [Proc IEEE, ?June? 1975])
-- under which a user logged in 3 times had 1/3 the clout in each process.
Each user was given an income rate and a checkbook.  As long as he was
logged in anywhere, his income was delivered.  He paid for resources out of
his checkbook.

A user who delegates login to a friend must give him some income -- by
diverting some of the user's own rate.

>Even if the system only allows one logon/user at any given
>time, serial use by many people can load down a system.  The reason why
>neither of these forms of delegation is a major problem is that users need
>to get work done, and so do not abuse their ability to delegate.

Here, too, I tend to agree with you -- but back in 1971, it was really easy
to overload machines.  Just doing normal single-user jobs could do it.  The
checkbook mechanism was my alternative to restricting low clout users (e.g.,
undergrads) to the graveyard shift.  Instead of that, we gave them low
incomes.  In fact, we didn't give incomes directly except to the three major
research project leaders.  Each of them divided up his own income pool --
and so on until it filtered down to the poor undergrads.  That way the
sysadmin staff could wash its hands of the granting of favors (by tuning of
scheduler parameters).

All I'm trying to say with this reminiscence is that if you have good enough
controls so that you can deliver what you promise and so that delegation
doesn't hurt anyone else, you can afford to let delegation be widespread.
Otherwise, I think you're asking for trouble.  My examples related to
performance.  The same applies to security, of course.  Is your OS secure
enough that you can afford to let a hacker log in on the same machine
holding your files?  Delegation of delegation of access interferes with your
ability to do background checks or to preserve security by threatening
employees with termination.


>(4) We shouldn't pretend to prevent what we can't prevent.

AMEN!  ...or to certify what we can't certify (like "identity" meaningful to
the verifier :).

>(5) Up-front delegation can be audited.  The back doors of proxys or key
>sharing can not.  Sysadmins can have much better control thru audit trails
>which can't be subverted than thru no-delegate attributes which can be
>subverted.

Yes.

>
>If we do include no/limited delegation in SPKI, I hope we will also include
>a discussion of its weaknesses and limitations.

..you mean in our document? ..or just on the list in its archive?

 - Carl