lamy@AI.UTORONTO.CA (Jean-Francois Lamy) (05/09/89)
On three different Irises in three different groups (checked within the last few minutes), / was world-writable (apparently shipped as such). Not funny. Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4
kvancamp@PICA.ARMY.MIL (Ken Van Camp) (05/09/89)
>On three different Irises in three different groups (checked within the last >few minutes), / was world-writable (apparently shipped as such). Not funny. There was a problem on the 3000's with the tar command, whereby a 'tar x' would always restore directories with mode 777 regardless of umask and original permissions on the tape. Use 'tar xp' instead. I don't know if SGI fixed this, since I still use the 'xp' on the 3000's. Anyway, it could explain your situation if somebody (maybe even SGI) restored to that system with a 'tar x'. This is not a problem on the 4-D's. ..Ken Van Camp <kvancamp@pica.army.mil>
lamy@ai.utoronto.ca (Jean-Francois Lamy) (05/10/89)
In reference to: > >On three different Irises in three different groups (checked within the last > >few minutes), / was world-writable (apparently shipped as such). Not funny. Ken Van Camp writes: >There was a problem on the 3000's with the tar command, whereby a 'tar x' > [...] . Anyway, it could >explain your situation if somebody (maybe even SGI) restored to that system >with a 'tar x'. This is not a problem on the 4-D's. We're talking about a 4D/120, a Personal Iris, and a 3000. The 4D/120 is a new machine, and its original root had said permissions. Someone is being careless (Sun used to do same, maybe still does, but that is no excuse). Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4
fsfacca@LERC08.NAS.NASA.GOV (Tony Facca) (05/10/89)
>On three different Irises in three different groups (checked within the last >few minutes), / was world-writable (apparently shipped as such). Not funny. >> There was a problem on the 3000's with the tar command, whereby a 'tar x' >> would always restore directories with mode 777 regardless of umask and I have seen this on the 3000's as well. I believe they were shipped that way and (I'm not positive but..) I think each time the OS was revised I had to reset the permission on / after installation. -- ----------------------------------------------------------------------------- Tony Facca | phone: 216-433-8318 NASA Lewis Research Center | Cleveland, Ohio 44135 | email: fsfacca@lerc08.nas.nasa.gov -----------------------------------------------------------------------------
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates TAD/TAB ms294 x42854") (05/10/89)
I fail to see what the problem is? / has world-writable, so what?! I would be concerned if it didn't. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
fsfacca@LERC08.NAS.NASA.GOV (Tony Facca) (05/10/89)
>> I fail to see what the problem is? / has world-writable, so what?! >> I would be concerned if it didn't. I suppose its just a matter of personal preference. Some folks set the default permissions on the user's directory to 700 so that users can't go snooping aroung in each others directories. Personally, I think 755 is fine. If I have sensitive data I can explicity set the permissions. However, by default, 777 on root?? / is no place for novice user's to have write permission. Moreover, if / is writeable by anybody, why even bother with a /tmp? I don't know, it just doesn't *smell* right. I'd have to agree with the original poster "Not Funny". -- ----------------------------------------------------------------------------- Tony Facca | phone: 216-433-8318 NASA Lewis Research Center | Cleveland, Ohio 44135 | email: fsfacca@lerc08.nas.nasa.gov -----------------------------------------------------------------------------
mem%inls2@UCSD.EDU (Margaret Mikulska) (05/11/89)
>>On three different Irises in three different groups (checked within the last >>few minutes), / was world-writable (apparently shipped as such). Not funny. >I have seen this on the 3000's as well. I believe they were shipped that way >and (I'm not positive but..) I think each time the OS was revised I had to >reset the permission on / after installation. Yes, we have 3130's and all of them had always extremely "permissive permissions" (777) on all important directories, no matter which version of op sys they ran. All machines brand new. I can't understand what makes SGI ship the machines that way. (Anybody at SGI cares to comment ?...) Margaret Mikulska University of California, San Diego ucsd!beowulf!mikulska mmikulska@ucsd.edu MMIKULSKA@UCSD
merritt@iris613.gsfc.nasa.gov (John H Merritt) (05/11/89)
In article <8905101550.AA02500@lerc08.nas.nasa.gov> fsfacca@LERC08.NAS.NASA.GOV (Tony Facca) writes: > >>> I fail to see what the problem is? / has world-writable, so what?! >>> I would be concerned if it didn't. > Try: cd / rm unix You can erase unix! -- That would make me mad, how about you? +----------------------------------+-----------------------------+ |John H. Merritt | Yesterday I knew nothing, | |Applied Research Corporation | Today I know that. | |merritt@iris613.gsfc.nasa.gov | | +----------------------------------+-----------------------------+
mitch@rock.SGI.COM (Thomas P. Mitchell) (05/11/89)
In article <8905101550.AA02500@lerc08.nas.nasa.gov>, fsfacca@LERC08.NAS.NASA.GOV (Tony Facca) writes: > > >> I fail to see what the problem is? / has world-writable, so what?! > >> I would be concerned if it didn't. It is a security problem -- chmod 555 / ; is the "school solution" > > I suppose its just a matter of personal preference. Some folks set the > default permissions on the user's directory to 700 so that users can't go chmod 700 or 500 is wrong. Many tools need read and search permissions -- Programs which run with low user ID numbers run as users to limit security problems. See things like lp. > snooping aroung in each others directories. Personally, I think 755 is fine. > If I have sensitive data I can explicity set the permissions. Each user should own his own home dir. He can set it to 700 if he wishes -- but that is nearly anti-social. A better is again 755 for $HOME and 700 for $HOME/someplace_private. > However, by default, 777 on root?? / is no place for novice user's to have True. It is wrong. Also simple to fix. > write permission. Moreover, if / is writeable by anybody, why even bother > with a /tmp? I don't know, it just doesn't *smell* right. I'd have to agree ^^^^ tis wrong. Exactly -- /tmp and /usr/tmp are 777 so anyone can make tmp files. Most users should use /usr/tmp/ by default because it is larger. Many system tools must use the smaller /tmp because the /usr filesystem may not be mounted. Will the original poster email me the Serial Numbers of the machines so I can follow up on this. I am mitch@sgi.com -- ------------- Thomas P. Mitchell (mitch@sgi.com) Rainbows -- The best (well second best) reason for windows.
olson@anchor.SGI.COM (Dave Olson) (05/11/89)
It turns out that when we made the master drives from which the shipped drives are copied, no one noticed that / was permission 777. mkfs created the root of the new filesystem with this permission in the absence of a prototype. mkfs has since been fixed to create the root mode 755, and lost+found with mode 700. The master drives were updated when 3.1D was released, and all future releases will no longer have this problem (note that simply performing an upgrade will NOT fix the problem, however). The fact that it went un-noticed (or at least uncomplained about) for so long (literally years) just goes to show that most of our systems are installed in rather friendly enviroments, I guess. -- Dave Olson It's important to keep an open mind, but not so open that your brains fall out. -- Stephen A. Kallis, Jr.
fsfacca@LERC08.NAS.NASA.GOV (Tony Facca) (05/11/89)
Just a "recap" on the situation.. Original posting: >>On three different Irises in three different groups (checked within the last >>few minutes), / was world-writable (apparently shipped as such). Not funny. I said: >I have seen this on the 3000's as well. I believe they were shipped that way >and (I'm not positive but..) I think each time the OS was revised I had to >reset the permission on / after installation. Margaret Miluska said: >>Yes, we have 3130's and all of them had always extremely "permissive >>permissions" (777) on all important directories, no matter which >>version of op sys they ran. All machines brand new. I can't understand >>what makes SGI ship the machines that way. (Anybody at SGI cares to >>comment ?...) Another poster asks: >>> I fail to see what the problem is? / has world-writable, so what?! >>> I would be concerned if it didn't. To which just about everyone said: >>It is a security problem -- Tom Mitchell (of SGI) adds: >>True. It is wrong. Also simple to fix. [editorial comment: Sure its simple, if you notice it before anyone can do damage. Bye the way, how many people checked / on their systems after this posting just to be sure? I know I did.] >>Will the original poster email me the Serial Numbers of >>the machines so I can follow up on this. I am mitch@sgi.com Dave Olson (also of SGI): >>It turns out that when we made the master drives from which >>the shipped drives are copied, no one noticed that ^^^^^^^^^^^^^^^ >>/ was permission 777. mkfs created the root of the new [editorial comment: Wink, Nudge, Nudge, say no more..] >>all future releases will no longer have this problem (note that Well, that was a lot of fun, thank you SGI for jumping in. This problem has been bothering me for a couple of years now, but I never bothered to complain about it. One last question, the original poster mentioned that he's seen the problem on the 4D's. We have several 20's and some 70's and I haven't seen it on these machines. Which "master drives" are you talking about? Is it more prone to be 3000's than 4D's? (I guess that's two questions). -- ----------------------------------------------------------------------------- Tony Facca | phone: 216-433-8318 NASA Lewis Research Center | Cleveland, Ohio 44135 | email: fsfacca@lerc08.nas.nasa.gov -----------------------------------------------------------------------------
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates TAD/TAB ms294 x42854") (05/11/89)
Thanks for everyones comments. I hadn't though about some of those things. I changed the permissions on my /. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
mg@cidam.me.rmit.oz.AU ("Mike A. Gigante") (05/13/89)
The default permissions stink. Not only is / 777 (allowing *anyone) to create or remove any file in the / directory -- bad news) but executables are shipped 777 also. This is even trueof setuid programs like /bin/su which creates such a blatant security hole that any user can crack root within 2 seconds ofgetting their csh/sh prompt. When the machine arrives, I run commands like the following: find / -type f -print | xargs file | grep mipseb | cut -f1 -d: | xargs chmod og-rw and similar variations for shell scripts(og -w) and directories (og-w). Of course with directories, there are a couple of execptions (like /tmp /usr/tmp etc) Mike
dfr@CAD.USNA.MIL ("David F. Rogers") (05/14/89)
G'day, All the 777's are a bit of bad news BUT, what about the poor guy who orders a 4D/20, with no installation (not that it would help much), does not know UNIX at all, is coming from the MS-DOS world. Unpacks the machine, sets it up and can't figure out what to do to make it work because he doesn't know enough about the permissions? I have actually seen this happen. Not everyone how buys an Iris is a UNIX guru. There's at least 2 sides to every story! Dave
dfr@CAD.USNA.MIL ("David F. Rogers") (05/14/89)
I disagreed with Steve Lamont. The guy has to be able to do something even if it is only to break the thing and then have to reload it. We learn from our mistakes. Dave
mccalpin@loligo.cc.fsu.edu (John McCalpin) (05/14/89)
In article <8905101550.AA02500@lerc08.nas.nasa.gov> fsfacca@LERC08.NAS.NASA.GOV (Tony Facca) writes: > >>> I fail to see what the problem is? / has world-writable, so what?! >>> I would be concerned if it didn't. Try: mv /etc /old_etc mkdir /etc vi /etc/passwd I have gotten superuser privileges on MANY SGI machines this way.... -- John D. McCalpin - Dept of Oceanography - Florida State University mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu mccalpin@fsu (BITNET or MFENET) SCRI::MCCALPIN (SPAN)
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates TAD/TAB ms294 x42854") (05/15/89)
That isn't the case for my 3130. / was the only directory that everyone had write permission, other than /tmp /usr/tmp. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates TAD/TAB ms294 x42854") (05/15/89)
For the UNIX neophyte, I would suggest that they read all the UNIX manuals cover to cover and then find a nice beginners guide to UNIX. Installation?! What is that? Isn't that where they come in and plug the machine into the outlet, turn the machine on, and say it is installed. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates TAD/TAB ms294 x42854") (05/15/89)
That has been pointed out to me. However, on our system that wouldn't work, there isn't enough disk space to make a copy of /etc. But I do see everyone's point now and it was me that wrote that note, not Tony Facca. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov