On May 24/2000, Nick Sayer scared people when he wrote:
>What we _really_ need is some mechanism to recognize the
>difference between a user program and a system library,
>with an eye towards granting privileges to trusted libraries
>without letting those privileges leak past the library in
>question.
>
>I don't claim that this is an _easy_ thing to do, nor that
>it is a particularly standard thing to do.
>
> [...]
>
>User authentication is only one example. There are many
>things that only root can do where letting non-root do
>the job is not dangerous, but granting non-root permission
>in a general way is.
As long as the floor is open to non-standard ideas, let me
reminisce about a feature from a different operating system
which started with an "M"...
It was called program keys, or 'pkey's. When a program
was running, there was this pkey attribute (in addition
to uid and gid). The pkey was a 16-character value (if
I remember right). Each executable had a pkey associated
with it, and that value became the current pkey when the
program started to execute. Users could change the pkey
value of any executable they had access to, but they could
only pick values that started with their userid. "System"
pkeys were values that started with an '*', and most of
those values could only be set by a privileged userid.
The default pkey for all executables was '*exec'.
There was a system call which allowed a program to change the
value of the active pkey. Any program at any time could
change the program key to '*exec'. The system call had
a table of what which active pkey's were allowed to switch
to some other pkey (with a specific list of acceptable
values it could switch to).
You could permit files to a pkey. So, you could:
permit /etc/passwd read pkey=*pw
chflag /usr/bin/login pkey *login
and then have the 'pushpkey' system routine allow pkey=*login
to change the active pkey to *pw.
When login starts to execute, the system would change the
active pkey to '*login'. While login was running, it could
call the pushpkey routine to switch the pkey to *pw, read
from /etc/passwd, and then pop the pkey back to *login (or
change it to *exec, if it didn't think it needed *login for
anything anymore).
I'm skipping a lot of details, of course, and it certainly
would not be a "standard thing" to do, but it was a very very
useful capability. You could have some password-reading
routine in a library, and that would be fine because that
routine could only PUSH the needed pkey if the calling
program had a pkey which allowed that *pw to be set.
This is also how things like games were able to keep
system-wide score-files. Any user program could use this
facility (they were only limited to the values of pkeys
they were allowed to 'chflag' to). So, userid 'drosehn'
could:
permit ~/scorefile write pkey=drosehn:mygame
chflag ~/mygame pkey drosehn:mygame
and anyone playing the game could write to that file, but
only thru the game. And the game, while active, would only
have access to files permitted to that specific pkey, instead
of all files owned by that userid.
I am not sure how one would map this into a distributed
computing environment, with NFS, AFS, and other networked
file systems shared by many different machines (with
different userid spaces). I think it'd be a cool project
if it could be done, though.
Anyone interested in extra credit points is invited to try
and guess which operating system THIS idea is from...
---
Garance Alistair Drosehn = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
