new user id system idea.

[wizard%wisdom.bitnet at WISCVM.ARPA]

From: Mike Trachtman  <wizard%wisdom.bitnet at WISCVM.ARPA>

an idea for protection sceme for unix.

Note: this is not entirely thought out, any comments are welcome.

It seems to me that having only all or no privledges,
is not quite appropiate for systems that support mov%than 20 users.

One would like to give teaching assitants access to make some accounts,
have other users be allowed to do backups, have some users, be allowed
to access certain devices, etc., w/o giving them full su privs.

This is of course doable with appropiate suid programs, but such
programs are a workaround, and a pain to write.

Thus I think Unix should have more than one type of priv.

also, I think that the group idea is not really used well at most Unix
Installations, and should be slightly modified to deal with it.

Lastly I think, that as alot of software gets strange ideas, when a person
is running as su, as to who is running, that system should be slightly changed
also.

Thus I suggest the following:

1) have a three layer permission heirechy (rather than 2 as now)

                        root
        |-------|--------|--------|--------|
        group   group    group    group    group
        leader  leader   leader   leader   leader
        | | |   | | | |  | | | |  | | | |  | | | |
        users   and more  users ..................

with uid-0 being root
uid 1-255 being group leaders
and other users, having the gid coded in the hi word and user within
the group, coded in the low word.

Users could then have group sets, and users sets also.
( I think that becoming su, should be just adding root, (or some other uid)
to your uid set).

the following permissions would be understood by the system

1) be allowed to set permission bits
2-5) be allowed to read/write/execute/search any file or directory.
6-9) be allowed to read/write/execute/search any file or directory belonging
        to your group.
10-13) be allowed to read/write/create/mount any special file
14) be allowed to do a shutdown
15) be allowed to do certain special system calls (set date)

the following convention would be used.

uid 0 - has all permissions
uid 1-255 have permissins v.s. the group they control
uid 1 would have 10-15 (operator group)
other uid's as appropiate.

This information would be kept in the password file.

The password file should be split up.
there should be a master file called /etc/passwd
which has an entry for each group, which says
which entries that group leader can control, and a filename where
he can write the accounts he creates.
then there would be /etc/passwd[1-255] for each of the groups, where the
leader can read/write it. (i.e. owned by that group)
(and of course /etc/passwd.hash, which is a hashed table of all the passwd
entries. for quick access.)

to su, to somthing would make a subshell with the added uid/gid to the
uid/gid lists, and the permissions of those accounts added.

One side note, It has been discussed whether someone running as root,
should have his privs changed when running someone elses suid program.
Though in general this is not a problem, the following situation has
occurred, and is a problem.

assume the games directory is locked, and some game runs suid
and does a cd to /usr/games/lib/somthing.
then even root can not play that game.
(this has happenned with hack)
if users permission sets are adopted, then this becomes no problem,
as a user would have both hack and root permissions.
any files made should be owned by the original user, unless
the program makes provision to be owned by somthing else.
the uid set should have a known order of uids,
first, real uid
second, suid uid
third... all other added uids.
then a program should be able to say
setown(uid) and if that uid is in the uid set, then all files
        created from then on, would have owner set to uid.

What do people think ??

                                Mike Trachtman
My address:

        wizard at wisdom                           (BITNET)
        wizard%wisdom.bitnet at wiscvm.ARPA        (ARPA/CSNET)
        wizard%wisdom.bitnet at berkley            (ARPA/CSNET)
and if all else fails (ONLY for VERY short items)
        ...!decvax!humus!wisdom!wizard          (UUCP)

(One should not say anything, when one has nothing to say.)