wizard%wisdom.bitnet@WISCVM.ARPA (04/30/85)
From: Mike Trachtman <wizard%wisdom.bitnet@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@wisdom (BITNET)
wizard%wisdom.bitnet@wiscvm.ARPA (ARPA/CSNET)
wizard%wisdom.bitnet@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.)long@ittvax.UUCP (H. Morrow Long [Systems Center]) (05/01/85)
> From: Mike Trachtman <wizard%wisdom.bitnet@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 more 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 can be done with a group for the TA's and appropriate group permissions on the files, directories and programs they need to access. Another group for operators, etc. Under 4.2bsd they can even belong to multiple groups simultaneously. All without setuid programs. Hey! Lets not be lazy out there. -- H. Morrow Long ITT-ATC Systems Center, 1 Research Drive Shelton, CT 06484 Phone #: (203)-929-7341 x. 634 path = {allegra bunker ctcgrafx dcdvaxb dcdwest ucbvax!decvax duke eosp1 ittral lbl-csam milford mit-eddie psuvax1 purdue qubix qumix research sii supai tmmnet twg uf-cgrl wxlvax yale}!ittvax!long
terryl@tekcrl.UUCP () (05/01/85)
>an idea for protection sceme for unix. >Note: this is not entirely thought out, any comments are welcome. >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. >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. You sure you didn't go to Berkeley??? They did something similar 6-8 years ago with group leaders. Basically, if the user id matched the group id, then that user was a group leader with su-like privileges for that group only. If I remember correctly(rarely) they never did distribute this as part of the normal UNIX* distribution. Terry Laskodi of Tektronix * UNIX IS A TRADEMARK OF YOU-KNOW-WHO
ee163acp@sdcc13.UUCP (DARIN JOHNSON) (05/02/85)
In article <6611@ucbvax.ARPA>, wizard%wisdom.bitnet@WISCVM.ARPA writes: > From: Mike Trachtman <wizard%wisdom.bitnet@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 more 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. I know of lots of people who hate VMS because it has to many protection modes. On the other hand, lots of people hate UNIX for the lack thereof. I would like to see something in the middle. All of the VMS privileges get kind of huge. (we have jokes about ABLE-TO-COMPILE-ON-TUESDAY privileges being added in a new version) On the other hand, on UNIX, you have to go and give your new system service to the SU to get it running (suid eats up your account). The VMS system we have here has virtually-nil privileges for students. This is annoying when we could use things like mailboxes but aren't allowed to. So if a new system were set up, people would tend to have an all or none approach anyway. For universities, it would seems nice to disallow all but the most basic permissions to introductory classes. For example, when our system got incredibly loaded and a certain command was 'turned off', those of us who didn't overuse it are equally restricted as the hogs. So something more than just owner, group, others would be a nice change. Oh well, enough rambling, off to work. Darin Johnson UCSD
ericr@hpvclc.UUCP (ericr) (05/02/85)
The idea as presented would be very handy. In fact, I once implemented the group administrator idea when I was at Washington State Univ. The main reason we did it was to overcome the system imposed limit of 255 uid's which we had at the time. The side-effect however was that a TA could manipulate his student accounts without free run of the system. Unfortunately, I did that some years ago and have no listings left. WSU cs dept. may still have it, but I am not sure. On the negative side about your suggestion, I see how many loopholes that can develop in our two-level security scheme; I just cringe when I think of what can develop with this multi-dimensional matrix that you suggest. I short, I think that security would suffer greatly. Several other systems including Hewlett Packard's MPE and Digital's RSX series OS's used more of a single dimension scheme where each use had a set of permission flags. I am more familiar with MPE so I will discuss some of its features. First, the 'super-user' has the SM (System Manager bit) set. This will allow him free run. The next level down is the 'AM' bit. He can create users within his account with their own logins and give them any permissions that he himself has. Then, there is the interactive permissions and batch permission flags. On the administration side, there is the OP (Operator) which will allow such sundry tasks as Spool control, backups, etc. He has no control on the account structure. The real beauty of this scheme is that you can mix and match to your heart's content to get the appropriate security scheme for each user. So, what I am suggesting is possibly the present uid and gid and an additional perm field which has permissions which can be individually mixed and matched. You asked for an opinion and you got it :) Eric Ross ihnp4!hpfcla!hpvcla!hpvclc!ericr Hewlett Packark Vancouver, Division (206)254-8110
jwp@sdchema.UUCP (John Pierce) (05/03/85)
I've found that expending some effort in making sure group ownership of directories is reasonable and in using 4.2's "member of multiple groups" feature has solved most, though not quite all, of the problems we used to have with permissions. Addition of a system call to allow "group superusers" helped quite a bit [if uid == gid, then that user can work their will with that groups files]. While there are still occassions where I would really like to have "subgroups", on a practical level I haven't yet found anything to be unmanageable.
mwm@ucbtopaz.CC.Berkeley.ARPA (05/04/85)
In article <114@tekcrl.UUCP> terryl@tekcrl.UUCP () writes: > You sure you didn't go to Berkeley??? They did something similar >6-8 years ago with group leaders. Basically, if the user id matched the >group id, then that user was a group leader with su-like privileges for >that group only. If I remember correctly(rarely) they never did distribute >this as part of the normal UNIX* distribution. The code that does this is still in use at the Berkeley Comp Center - not to be confused with CSRG - and, I suspect, originated here. We also have a hack (oops, that should be "hook", but then again, I've seen how it was done...) that allows "administrative" users to su to any id that isn't a staff id. If you're interested in this stuff, drop me a line. <mike
db@cstvax.UUCP (Dave Berry) (06/27/85)
In article <382@sdchema.UUCP> jwp@sdchema.UUCP (John Pierce) writes: >Addition of a system call to allow "group superusers" >helped quite a bit [if uid == gid, then that user can work their will with >that groups files]. I'd like to suggest a slight variation on this. Make uid's & gid's the same, with groups defined by a special format in /etc/passwd (analogous to the style of entries in /etc/group). Then you get your "group superuser" by logging-in (or su-ing) to that user. Everybody else starts off in their own group - i.e. files they create have the same uid & gid, restricting permission to themselves in each case. This would obviously be changeable. Then when any daemons write files to private spool directories, they change the gid of these files to the owner, thus giving the owner (& no-one else) read permission on spooled files. This would be useful if they wanted to check the contents of files, before removing them or updating them. -- Dave Berry. CS postgrad, Univ. of Edinburgh ...mcvax!ukc!{hwcs,kcl-cs}!cstvax!db