jrw@hropus.UUCP (Jim Webb) (10/17/86)
> I currently have VAX 11/785s running AT&T UNIX V Release 2 Version 2.0. > I am wondering which commands in /bin /and /usr/bin (owned by root, group is > sys) must have the set user ID, or set group ID on execution in order > to work correctly. -rwsr-xr-x 1 root sys 9784 Apr 3 1986 df df needs to be able to read the superblock of the filesystem(s) to see how many blocks and inodes are free. Unfortunately, the standard version allows it to open ANY device; it should restrict non-super-users to those devices found in /etc/mnttab (mounted filesystems) -rwsr-xr-x 1 root sys 8360 Nov 5 1983 mkdir only root can mknod directories, as the . and .. entries are put in somewhat manually by the command. If anyone could make directories, I guess somewhere along the line someone in their application would not do it correctly and minor mayhem would ensue. -rwsr-xr-x 1 root bin 18936 Nov 5 1983 newgrp needs suid so that one can change his/her group id. -rwsr-sr-x 1 root sys 19068 Nov 5 1983 passwd obvious. -rwsr-xr-x 1 root sys 8796 Nov 5 1983 rmdir like mkdir, only root can unlink directories. -rwsr-xr-x 1 root sys 19484 Nov 5 1983 su obvious. -rwsr-xr-x 1 root sys 47197 Oct 20 1985 at at needs to talk to cron in a very specific manner. It should be noted that this is why the files in /usr/spool/cron/atjobs are setuid and setgid to the submitter, for cron (yes, cron) stats the file and does a setuid and setgid on the owner and group of the file. However, some pond scum (:-) could chgrp and chown the files to root and have them then run as root. SO, at makes sure the setuid and setgid bits are set, as they are cleared on chowns. -rwsr-xr-x 1 root sys 25093 Nov 5 1983 crontab crontab tells the cron daemon to create individual crontabs. It does this by writing on /usr/lib/cron/FIFO which had better be 700 owned by root. Otherwise, a user could manipulate cron quite freely. You should at this point make /usr/spool owned by uucp and modes 755. As distributed, /usr/spool is 777, so a user could mv /usr/spool/cron to /usr/spool/cron/.cron and replicate the directory structure, obviously adding a nicety to root's crontab. Although this would not be noticed until the system is rebooted or cron re-run, it is usually worth the wait... ---s--x--x 1 root sys 41980 Oct 16 1985 ct ct needs to be suid root so that when it calls /etc/getty, getty can write in /etc/utmp and /etc/wtmp to log the login. It also needs to run as root so that login will work, as by default, login is NOT suid. You could setuid root login and then people could successfully login again via "exec login" -rwsr-xr-x 2 root bin 37232 Nov 6 1983 sh just kidding... -rwsr-xr-x 1 root sys 22380 Nov 5 1983 shl shl needs it so that it can set/reset the owners of the sxt devices as well as twiddle some other things. > I hesitate to change the permissions without knowing why the commands > had the set user id on execution in the first place. Or in other > words, I have changed the permissions on a FEW commands and they stopped > working. snicker snicker Some more comments on suid root programs. Do yourself a favor and make the following change, it will make a lot of hackers (like myself) not like your machine too much, but.... chmod 777 /usr/preserve chmod u-s /usr/lib/ex*preserve By no means does ex*preserve need to be setuid root. It did when it was on berkeley, as chown was/is restricted to root there, but not under SV. I guess you could make a group "vi" and setgid it to vi, and make /usr/preserve 775, group vi if you wanted to be a bit more secure. Also, /etc does not need to be 775 group sys. Make it 755. -- Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw
seb022@tijc02.UUCP@ndmce.uucp (Scott Bemis ) (10/17/86)
I currently have VAX 11/785s running AT&T UNIX V Release 2 Version 2.0. I am wondering which commands in /bin /and /usr/bin (owned by root, group is sys) must have the set user ID, or set group ID on execution in order to work correctly. An example of a command is /usr/bin/at. Below is what ls -l would produce. $ ls -l /usr/bin/at -rwsr-xr-x 1 root sys 31448 Jul 3 1984 /usr/bin/at I hesitate to change the permissions without knowing why the commands had the set user id on execution in the first place. Or in other words, I have changed the permissions on a FEW commands and they stopped working. Scott Bemis mcnc!rti-sel!tijc02!root
wcs@ho95e.UUCP (#Bill.Stewart) (10/18/86)
In article <735@hropus.UUCP> jrw@hropus.UUCP (Jim Webb) writes: >>[Somebody else wrote..] >> I currently have VAX 11/785s running AT&T UNIX V Release 2 Version 2.0. >> I am wondering which commands in /bin /and /usr/bin (owned by root, group is >> sys) must have the set user ID, or set group ID on execution in order >> to work correctly. What surprised me about the list Jim replied with was that most of the commands were -rws......! Why should a setuid command *ever* be writeable? - it's just *inviting* attempts to find a bug and convince the command to write over itself. Are there any commands that actually depend on this? >-rwsr-xr-x 1 root sys 47197 Oct 20 1985 at >-rwsr-xr-x 1 root sys 25093 Nov 5 1983 crontab >at needs to talk to cron in a very specific manner. I would expect you could write a good cron without setuid, since /etc/cron runs as root? Likewise "at", since it's the other side of cron? What irks me more, though, is that the "lp" commands all run setuid-lp setgid-bin; this means that in a directory which lp can't access ( e.g. 700), lp foo fails, though lp <foo is ok. -- # Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
rcodi@yabbie.rmit.oz (Ian Donaldson) (10/20/86)
If you carefully set the permissions and owner/groups of "priviliged"
files and devices you can remove the need for lots of programs to
have "setuid root" permission.
For example, "df", "quot" need only access filesystems, so it makes
sense to group all your "disk" devices by an owner "disks". Thus, you
make "df" and "quot" setuid "disks".
Since "ps", "w", "pstat", "gcore" all access /dev/kmem, they can
conveniently it also makes sense for /dev/kmem to be grouped by "mem",
and the set-gid mem permission placed on the programs.
A few examples follow:
-rws--x--x 1 disks bin 13512 Jun 11 1985 df
-rwx--s--x 1 bin mem 21688 Jun 15 19:38 ps
-rwx--s--x 1 bin mem 12028 Jun 15 19:59 gcore
-rwx--s--x 1 bin mem 20588 Jun 10 01:08 pstat
-rws--x--x 1 disks bin 16328 Jul 16 1985 quot
-rwx--s--x 2 bin mem 17124 Jun 15 19:38 uptime
-rwx--s--x 2 bin mem 17124 Jun 15 19:38 w
Some of my /dev/ follows:
brw-rw-r-- 1 disks floppy 0, 0 Aug 24 22:08 flp0d
brw-r----- 1 disks winnie 1, 0 Jun 26 01:34 imi0a
crw-r----- 1 bin mem 2, 1 Oct 12 21:43 kmem
crw-r----- 1 bin mem 2, 0 Jun 26 01:33 mem
crw-rw-r-- 1 root magtape 10, 16 Jun 26 01:34 nrmt0l
crw-rw-r-- 1 root magtape 10, 24 Jun 26 01:34 nrmt0p
crw-r----- 1 disks winnie 4, 18 Aug 16 15:30 rimi1c
crw-rw-r-- 1 root magtape 10, 8 Jun 26 01:34 rmt0p
crw-r----- 1 disks winnie 11, 0 Jun 26 01:35 rst0a
brw-r----- 1 disks winnie 5, 0 Jun 26 01:35 st0a
brw-r----- 1 bin mem 5, 2 Jul 14 21:36 swap
For the benefet of those who can't handle cryptic crosswords,
"st" and "imi" are winchester disks,
"flp" is a floppy disk,
"mt" is a mag-tape,
the rest should be universal.
This way other benefits are provided: you can list in /etc/group
those users that are allowed access to the floppy and magtape etc,
without having to tell them what the root password is, or make
the device publicly read/writeable. By changing mode 640 to 660
on other devices you can grant winchester access as well (not advised).
This convention has been in use on our systems for months now and
I am confident it is reasonably free of side-effects.
Ian Donaldsonsherm@popeye.UUCP (Paul A. Sherman) (10/20/86)
In article <735@hropus.UUCP> jrw@hropus.UUCP (Jim Webb) writes: >Also, /etc does not need to be 775 group sys. Make it 755. Although /etc does not *need* to be 775 group sys, it makes ps(1) run much faster in most cases (see explanation below). I don't know if other standard programs make use of this situation, but I don't think that it creates a security problem. Unless other programs that are setgid sys have shell escapes (I don't know of any) or access to group sys is granted indiscriminately, I think that /etc should remain mode 775, group sys, as distributed. At least in System V, ps(1) creates a data file called /etc/ps_data containing information from /dev, /unix, and /etc/passwd. If /etc/ps_data is newer than those three files than it is used. Otherwise it is recreated. On all System V systems that I've worked on, ps runs MUCH faster when it can use an existing ps_data. This is because otherwise it has to call nlist(3) on /unix and look through all of the entries in /dev. Normally /etc is 775, group sys and ps is setgid to sys, so any user of ps can create the new ps_data. If /etc is mode 755, owned by root, ps can only successfully create a new ps_data file when it is run by root. If things don't change much, than other users of ps will be able to use the file that root created. However, any user changing a password (with passwd) or login shell (with chsh) changes /etc/passwd and makes the older /etc/ps_data unusable. Adding or removing nodes from /dev (which admittedly happens much less frequently and requires superuser permissions) also makes ps_data unusable since the modification time of /dev changes. As an aside, I have run across a couple of times that ps seemed to run slow ALL the time, not only the first time after a change to /etc/passwd or /dev. I found that the system had been powered off recently and the date had to be reset. Before that happened, however, the modification time of /dev or /unix was set to some time in the future. Thus, ps's check for ps_data being newer than those files always failed, and ps had to read all of its own data and recreate ps_data. The next time, of course, the same thing happened. -- Paul Sherman AT&T Information Systems, Lincroft, NJ {pegasus|ihnp4}!popeye!sherm (201) 576-6316
jrw@hropus.UUCP (Jim Webb) (10/20/86)
This is not the beginning of a shouting match... > What surprised me about the list Jim replied with was that most of the > commands > were -rws......! Why should a setuid command *ever* be writeable? - it's just > *inviting* attempts to find a bug and convince the command to write > over itself. First off, root can overwrite any file regardless of perms, yes/no? Second, ever see "error: text busy" ? You cannot remove or write over a file that is running somewhere on the system (or, to be picky, has the sticky bit set and has been run) > Are there any commands that actually depend on this? Self modifying code, perhaps :-) > >-rwsr-xr-x 1 root sys 47197 Oct 20 1985 at > >-rwsr-xr-x 1 root sys 25093 Nov 5 1983 crontab > >at needs to talk to cron in a very specific manner. > I would expect you could write a good cron without setuid, > since /etc/cron runs > as root? Likewise "at", since it's the other side of cron? at and crontab need to yell down /usr/lib/cron/FIFO to talk with cron. I suppose you could make these commands setgid to some unique group and make this pipe writable only by that group. > What irks me more, though, is that the "lp" commands all run setuid-lp > setgid-bin; this means that in a directory which lp can't access ( e.g. 700), > lp foo > fails, though > lp <foo then make lp suid root :-) -- Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw "Use the Force, Read the Source"
jrw@hropus.UUCP (Jim Webb) (10/20/86)
> >Also, /etc does not need to be 775 group sys. Make it 755. > > Although /etc does not *need* to be 775 group sys, it makes ps(1) run > much faster in most cases (see explanation below). I don't know if > other standard programs make use of this situation, but I don't think > that it creates a security problem. Unless other programs that are > setgid sys have shell escapes (I don't know of any) or access to group > sys is granted indiscriminately, I think that /etc should remain mode > 775, group sys, as distributed. I can think of one program off the top of my head that is setgid sys and has two very exploitable security holes. I would mention it here, but I am sure that every college student listening in would try it :-). I guess it is a tradeoff, I can become root on any standard SV machine in under 60 seconds if /etc is 775 group sys, or ps can run slower if /etc isn't writable by group sys. Because of this, I guess ps should be hacked to overwrite /etc/ps_data instead of unlinking and exclusively re-creat-ing it. Or, make "yet another" nothing login with NONE as its passwd so that it is IMPOSSIBLE for a non-superuser to login or su to the account, make it the owner of /etc, 755, and make ps setuid to it. You have to keep ps setgid sys, otherwise you cannot get at /dev/*mem and /dev/swap. ISN'T SECURITY FUN? It should be noted to fellow AT&T Bell Labbers that the hole mentioned above has been closed on most, if not all, 452 CompCenter machines, so don't waste your time looking at all of the setgid sys programs :-) -- Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw "Use the Force, Read the Source"
jack@mcvax.uucp (Jack Jansen) (10/20/86)
Probably a *lot* of commands in /bin or /usr/bin don't need set-uid. If you adopt a well-chosen group scheme, set-gid to a certain group can be enough. This is what is more-or-less done in BSD unix. For instance, /dev/kmem is owned by the group 'kmem', and '/bin/ps' is setgid kmem. This can easily be extended to programs like 'at', 'df', 'expreserve', etc. The nice thing is that this is even possible if you don't have a source license....... -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.
henry@utzoo.UUCP (Henry Spencer) (10/21/86)
> -rwsr-sr-x 1 root sys 19068 Nov 5 1983 passwd > > obvious. No, actually, not obvious. Passwd only has to be able to read and write in /etc, which generally does not require root privileges. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
gwyn@brl-smoke.ARPA (Doug Gwyn ) (10/21/86)
In article <32@popeye.UUCP> sherm@popeye.UUCP (62545456-Paul A. Sherman;LZ 3E-303;6316) writes: >I think that /etc should remain mode 775, group sys, as distributed. Please note that, from a security standpoint, this has given any "sys" group member (or set-gid "sys" process) super-user access if it chooses to exploit it. Also note that "ps" need not have write permission on /etc in order to rewrite /etc/ps_data. (If so desired, the file could be locked during rewrite so that concurrent "ps"es wouldn't trip over each other.)
gwyn@brl-smoke.ARPA (Doug Gwyn ) (10/21/86)
In article <1040@ho95e.UUCP> wcs@ho95e.UUCP (Bill Stewart 1-201-949-0705 ihnp4!ho95c!wcs HO 2G202) writes: >What surprised me about the list Jim replied with was that most of the commands >were -rws......! Why should a setuid command *ever* be writeable? - it's just >*inviting* attempts to find a bug and convince the command to write over itself. The "write" access bit on a file owned by "root" is essentially a no-op, since the super-user (or a privileged process) could write the file anyway. It doesn't create any additional security problem that I can see.
geoff@desint.UUCP (Geoff Kuenning) (10/22/86)
In article <735@hropus.UUCP> jrw@hropus.UUCP (Jim Webb) writes: > df needs to be able to read the superblock of the filesystem(s) to see how > many blocks and inodes are free. Unfortunately, the standard version allows > it to open ANY device; it should restrict non-super-users to those devices > found in /etc/mnttab (mounted filesystems) However, this can be done by creating a special UID or GID for 'df' and putting the appropriate devices in that user ID or group: -rwsr-xr-x 1 check check 14356 Feb 2 1985 /bin/df brw------- 1 check check 6, 11 Sep 24 09:53 /dev/w0a brw------- 1 check check 6, 13 Feb 7 1985 /dev/w0b -- Geoff Kuenning {hplabs,ihnp4}!trwrb!desint!geoff
levy@ttrdc.UUCP (Daniel R. Levy) (10/23/86)
In article <1040@ho95e.UUCP>, wcs@ho95e.UUCP (#Bill.Stewart) writes: >What surprised me about the list Jim replied with was that most of the commands >were -rws......! Why should a setuid command *ever* be writeable? - it's just >*inviting* attempts to find a bug and convince the command to write over itself. Waitaminnit... at least on SysV, it is not possible to overwrite, or remove the last link to, any executable file which is currently being run (this doesn't count shell scripts). I do not know whether BSD has the same restriction. Could someone suggest a reason for this (other than security)... is this to accommodate versions of the UNIX OS which can page or swap text out of the filesystem? What about UNIX systems which don't swap or page out of the filesystem? But I digress. A setuid command being writeable makes it easier for the system admin to install a new version, I suppose, though it seems almost as easy for makefiles to put in an explicit rm -f or chmod when needed. ># Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, go for it! allegra,ulysses,vax135}!ttrdc!levy
gaspar@ALMSA-1.arpa (Al Gaspar) (10/24/86)
I would be interested in seeing this discussion cover BSD as well. Al Gaspar <gaspar@almsa-1.arpa> USAMC ALMSA, ATTN: AMXAL-OW, Box 1578, St. Louis, MO 63188-1578 COMMERCIAL: (314) 263-5118 AUTOVON: 693-5118 seismo!gaspar@almsa-1.arpa
guy@sun.uucp (Guy Harris) (10/26/86)
> Waitaminnit... at least on SysV, it is not possible to overwrite, or > remove the last link to, any executable file which is currently being > run (this doesn't count shell scripts). I do not know whether BSD has > the same restriction. BSD has the former restriction, but not the latter. > Could someone suggest a reason for this (other than security)... There is no good reason whatsoever for the latter restriction, which is why Berkeley lifted it. Since the shared text structure (or, presumably, the region structure in later S5 implementations) holds on to the inode, the file doesn't really disappear when unlinked (although there are no directory entries referring to it) until the last process releases that shared text. The only reason I've heard was something on the order of "well, if you have the system holding on to one of these 'no directory entries point to it' files, and the system crashes, it shows up as an unreferenced file", which is boguus because 1) the exact same thing happens if you remove the last link to a file which somebody has open, and UNIX doesn't forbid that, and 2) "fsck" will clean up those unreferenced files anyway. There are better reasons for the former restriction. In an unpaged system, if you wrote to the file the change would not necessarily be reflected in the copy in main memory or on the swap device; as such, until those copies last their last reference and disappeared, processes trying to execute that file would get a copy of the old text and a copy of the new data, which would be very confusing. In a paged system, it's even worse - processes currently using that file could get a mixture of old and new pages! In a system using NFS, it is impossible to prevent a file from being opened for writing by a process on one machine if another machine is using that file as a shared text (because it's impossible for the machine on which the file resides to find out who's holding on to it), so the writes are allowed to go through; however, if the process using that file tries to fetch a page from a file that has been modified since the process in question first attached to it, it gets zapped by a SIGKILL (a message is printed on the user's terminal, if there's a terminal associated with this process). -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
mangler@cit-vax.Caltech.Edu (System Mangler) (10/27/86)
In article <8545@sun.uucp>, guy@sun.uucp (Guy Harris) writes: > In a system using NFS, it is impossible to prevent a file from being opened > for writing by a process on one machine if another machine is using that > file as a shared text (because it's impossible for the machine on which the > file resides to find out who's holding on to it), so the writes are allowed > to go through; however, if the process using that file tries to fetch a > page from a file that has been modified since the process in question first > attached to it, it gets zapped by a SIGKILL (a message is printed on the > user's terminal, if there's a terminal associated with this process). This problem is even worse with dual-ported disks. The read-only side is completely clueless about the writes, and the process (usually some daemon like sendmail) gets a mixture of old and new pages. If you're lucky, the process dies. We only update the read/write side late on Saturday nights, but we still get bit. /etc/update's liking for holding certain directories open all the time causes similar problems when those directories are updated. I've never understood the purpose of that. Don Speck speck@vlsi.caltech.edu {seismo,rutgers}!cit-vax!speck
aij@k.cc.purdue.edu (Ray Moody) (10/27/86)
>> What surprised me about the list Jim replied with was that most of the >> commands >> were -rws......! Why should a setuid command *ever* be writeable? - it's just >> *inviting* attempts to find a bug and convince the command to write >> over itself. > >First off, root can overwrite any file regardless of perms, yes/no? Second, >ever see "error: text busy" ? You cannot remove or write over a file that >is running somewhere on the system (or, to be picky, has the sticky bit set >and has been run) Anyway, if a setuid program overwrites itself, it is no longer setuid! It says in the manual page for write (2): If the real user is not the super-user, then _w_r_i_t_e clears the set-user-id bit on a file. This prevents penetration of system security by a user who "captures" a writable set- user-id file owned by the super-user. >> What irks me more, though, is that the "lp" commands all run setuid-lp >> setgid-bin; this means that in a directory which lp can't access ( e.g. 700), >> lp foo >> fails, though >> lp <foo > >then make lp suid root :-) There shouldn't be any smiley face here. This is a perfectly reasonable suggestion. Just MAKE SURE IT CALLES ACCESS (2)! Out lpr program runs setuid. array array Ray Moody array ihnp4!pur-ee!pucc-s!aij array
guy@sun.UUCP (10/27/86)
> /etc/update's liking for holding certain directories open all the time > causes similar problems when those directories are updated. I've never > understood the purpose of that. Back in the days of V7, UNIX didn't treat the list of free inode table entries as an LRU cache for inodes. Holding selected directories open kept their inodes in core, and meant the system didn't have to go to the disk every time it wanted to get that inode. Of course, when you have two processors (or processes) sharing access to some data structure, and keeping local cached copies of that data structure, you have to be careful to avoid cache consistency problems like the ones you see when dual-porting. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
guy@sun.UUCP (10/28/86)
> Anyway, if a setuid program overwrites itself, it is no longer setuid! > It says in the manual page for write (2): It says this *in the 4BSD manual page for write(2)*; this is a Berkeleyism. I consider it to be an airbag; I'm not sure it's worth putting in a hack like this to protect people who don't remember to make set-UID programs writable only by the owner. (Also note that it doesn't apply if the process doing the write has a *real* UID of "root".) -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)