Aucbvax.4492 fa.unix-wizards utzoo!decvax!ucbvax!unix-wizards Fri Oct 16 00:58:29 1981 S[UG]ID files and s[re][ug]id() system calls >From decvax!ittvax!swatt@Berkeley Thu Oct 15 21:14:38 1981 Re: S[UG]ID files and [sg][re][ug]id() system calls. Back in my hacking days, we ran into similar limitations of the standard UNIX handling of SUID/SGID bits and suid()/getuid() calls. The approach we adopted was: S[UG]ID works for ALL users (no exceptions for root) S[UG]ID NEVER works for files being exec'd from insecure devices. open() NEVER works for special files residing on insecure devices. The above two prohibitions were to support user- mountable filesystems (floppies). In our implementation, a device was "insecure" if its major device number was not the same as the root device major device number. That way we could boot a UNIX system off a floppy and access special files (handy to do; we had only 1 rp05 drive which was often flakey). The check on the major device number is a clumsy way to do it. Someone (I think Bill Plaugher) suggested an extra argument to the mount command, only honored for the super-user, to say that the mounted filesystem was "secure". If you allow user-mountable filesystems and don't check for SUID/SGID and special files, your system is not secure. setuid(),setgid(). This was back in the V6 days where a uid/gid was only one byte. But the principle applies: Any process may change its real/effective permissions to any combination of permissions it already possesses. The rational behind this was that the only place the REAL user id information was ever checked was in the sgid() system call; all checks for file permissions and the like used the effective permissions. The previous rule said that any process could set its effective permissions to its real permissions. The new rule thus did not permit any new kind of access but made certain kinds of operations for SUID/SGID programs much more convenient. Specifically you could have a "swapid()" subroutine which would switch real and effective permissions AND REVERSE THEM AT A LATER TIME. Thus a program SUID to "jones" being run by "smith" would have the ability to do anything either "jones" OR "smith" could do. An important application was the creation of priviliged commands which could temporarily "de-privilege" themselves. The later addition of the "access" system call has not (I believe) totally obviated the need this. In fact what we added were "getid" and "setid" system calls which returned/took a 4-byte array containing user and group, real and effective ids. Given these two, subroutines to mimic "getuid", "getgid", "setuid", and "setgid" are easy (I think we left the system calls in to keep some binaries happy though). In short, I think the UNIX handling of S[UG]ID files and s[ug]id() system calls could be improved. We also changed the relationship between group and user ID's to be a hierarchy instead of an overlay (mostly to overcome the 256 user limit). A rather nice (I think) side effect of this was the creation of a Group Super User, who had all the powers of "root", but only on files and processes owned by that group. All this was done without changing the tty driver. I would like to see the idea of a group super user made part of V7 UNIX; it considerably simplifies system management in allowing most aspects of administering a group to be divested from administering the system as a whole. In an academic environment, it is also good training for eventual super-users. However, without changing the "overlay" relationship of group and user ID's, I can't suggest a reasonable way to do it. - Alan S. Watt (decvax!ittvax!swatt) ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.