[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: delegation conflict, background
At 4:13 PM 6/28/96 -0400, Carl Ellison wrote:
>I wanted to allow each user (even a lowly undergrad) to have the power to
>create a sub-account of his own login -- for a friend to use. All CPU time
>would be taken from the source user's allocation, as would all memory
>residency and all disk space usage. The friend would create his own
>password, so the source person wouldn't be able to invade the friend's
>privacy and vice versa.
>
>This is indefinite delegation. However, it requires several changes to the
>OS. Most OS's (except mine at that time) have the characteristic that the
>more jobs you log in, the more percentage of the CPU you get -- and none
>controlled the percentage of the memory occupancy you got. [Mine controlled
>both and multiple jobs just diluted your clout.]
>
>As long as you have no such controls in the OS, the user's ability to let
>his friends have accounts amounts to giving up all sysadmin control.
>
>As long as you retain sysadmin control, users keep loaning their passwords
>to friends.
And, given that a user can log on multiple times, the results on the system
are the same. 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.
>I assume that's the basis of your desire to permit delegation at all times.
>That is, if we replace passwords with private keys, we will find users still
>motivated to hand out copies of their private keys unless we allow
>uncontrolled delegation of certified rights -- but I can't imagine syadmins
>agreeing to that.
That is only one facit of my desire to permit delegation at all times. The
others that I can think of now:
(2) The most basic is that, with fine-grained enough controls, all use
implies delegation. Consider a simple example, handing a file to an
execute-only text formater. Although many systems don't formalize this,
the model is: (1) I have permission to cause an instance of the text
formater to come into existance. (But not permission to look at the memory
immage of that instance.) I am delegating that instance the authority to
access (hopefully just) the file (but more likely the directory, or worst
of all, all the directories and files I can access). With fine-grained
controls, each entity in this scenario (the execute only program, the
instance, and the file) has a different identity.
(3) Users, particulary in a mutually suspicous distributed environment, can
always build proxys to do their delegation.
(4) We shouldn't pretend to prevent what we can't prevent.
(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.
If we do include no/limited delegation in SPKI, I hope we will also include
a discussion of its weaknesses and limitations.
Regards - Bill
-------------------------------------------------------------------------
Bill Frantz | The Internet may fairly be | Periwinkle -- Consulting
(408)356-8506 | regarded as a never-ending | 16345 Englewood Ave.
frantz@netcom.com | worldwide conversation. | Los Gatos, CA 95032, USA