dave@safari.UUCP (dave munroe) (11/15/88)
In release 3.5 at least, /etc/shutdown has permissions -rwxr-xr-x, which is obviously a bad idea. -dave
alex@umbc3.UMD.EDU (Alex S. Crain) (11/17/88)
In article <234@safari.UUCP> dave@safari.UUCP (dave munroe) writes: >In release 3.5 at least, /etc/shutdown has permissions -rwxr-xr-x, which is >obviously a bad idea. Yea, but does it really matter? I think that you have to be root to have /etc/shutdown work anyway, because the shutdown system call (in syslocal(5)) must be executed by the root user. Now -rwsr-sr-x would be a different story.... -- :alex. Systems Programmer nerwin!alex@umbc3.umd.edu UMBC alex@umbc3.umd.edu
jr@amanue.UUCP (Jim Rosenberg) (11/20/88)
In article <1349@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes: >In article <234@safari.UUCP> dave@safari.UUCP (dave munroe) writes: >>In release 3.5 at least, /etc/shutdown has permissions -rwxr-xr-x, which is >>obviously a bad idea. > > Yea, but does it really matter? I think that you have to be root >to have /etc/shutdown work anyway, because the shutdown system call >(in syslocal(5)) must be executed by the root user. > > Now -rwsr-sr-x would be a different story.... For a while I had an account on my machine for a student programmer type. He was working part time for a company I was also consulting for, & I needed a way for us to be in touch by email on days when I woulnd't be down there. I run process accounting & kept a very sharp eye on what he did on my machine. (Yes, Virginia, process accounting works on the 3b1, even if they were too negligent to give us the utilities to turn it on or log the results!) I just about jumped out of my skin when I saw killall in the log. I had his login shell as ksh & was able to peruse his history file, & sure enough, he had executed /etc/shutdown. It is *very* true that he didn't in fact succeed in shutting my system down, but it gave me a very nasty scare!! I went through /etc with a fine tooth comb removing permissions left and right. This fellow *would* crack a system if it were easy for him. He was more the kind of guy who would pull a lever just because it happened to stick out from the wall -- just to see what would happen -- rather than a determined cracker. I'm not at all comfortable with the idea of o+x permissions on /etc/shutdown, relying on the fact that shutdown is smart enough not to let anyone but root succeed. If a user is allowed to execute shutdown that may convey an idea that security is lax on your machine, and that person may go wandering around looking for a more serious target. Of course the opposite case could be argued too: a determined cracker likes nothing better than a challenge. The most obvious approach to security is the ring approach where you hope you have in place a ring of defenses, and that it will take several successive failures before you get cracked. Lax permissions on system administration commands is not a ring, it's an open door. YOU ARE ASKING FOR TROUBLE if you don't tighten up on /etc, in my opinion. To be truthful, I can hardly believe in light of all the concern for security prompted by the (apparently) Morris Worm that anyone would seriously propose leaving 755 permissions on something like /etc/shutdown, for crying out loud! The off-the-shelf permissions on the 7300 are probably the worst of any commercially released UNIX box ever seen on the face of the earth. You should give your machine a thorough going over. Hey folks, wormville & virusville mean a whole new ball game when it comes to security!!! If your machine has a security hole you might very well never get cracked. In order to be cracked you have to have (1) a security hole (2) a cracker who has access to your machine or knows its phone number (3) the cracker has to know how to exploit the hole (4) the cracker has to have the desire to invoke the hole. Only so many machines with a given hole will in fact get cracked through it. Viruses & worms make it a whole different ball game. *EVERY* machine with a virusable hole is *QUITE LIKELY* to be cracked. The fingerd bug that the Morris Worm used still has me shaking my head. How may other programs are suceptible to that same attack?? Are we *REALLY* sure that uuxqt can't be penetrated? Think about it. For crying out loud, being safe and sane in your permissions for system administration commands is the *SIMPLEST* security thing you can do. Do it, do it today, for heavens sake!! -- Jim Rosenberg CIS: 71515,124 decvax!idis! \ WELL: jer allegra! ---- pitt!amanue!jr BIX: jrosenberg uunet!cmcl2!cadre! /
mml@magnus.UUCP (Mike Levin) (11/20/88)
In article <234@safari.UUCP> dave@safari.UUCP (dave munroe) writes: >In release 3.5 at least, /etc/shutdown has permissions -rwxr-xr-x, which is >obviously a bad idea. > -dave It's also that way in release 3.51, *BUT* if you are NOT root, it gives the appearance of proceeding to do it's thing, and then it fails. For example, it warns of killing active phone conversations, etc., but then when it tries to do it's thing, it fails for "unable to send signal to init". So, it is probably safe. IN ANY CASE, it is ONLY a shell script, and as such it is something that (from a security standpoint) somebody could simply create with an editor themselves. It *CAN'T* be setuid'd, it can't be removed or altered by anybody but the owner, and so I don't think that any security is actually compromised by the way it's done. Of course, maybe I'm missing something. :-) Mike Levin -- +---+ P L E A S E R E S P O N D T O: +---+ * * * * * * * * * * | Michael M. Levin, Silent Radio, Los Angeles | I never thought I'd be LOOKING |{aeras|csun|mtune|pacbell|srhqla}!magnus!levin| for something to say! ! ! +----------------------------------------------+------------------------------+
cks@ziebmef.uucp (Chris Siebenmann) (11/24/88)
In article <336@magnus.UUCP> mml@magnus.UUCP (Mike Levin) writes: ... >It's also that way in release 3.51, *BUT* if you are NOT root, it gives the >appearance of proceeding to do it's thing, and then it fails. For example, >it warns of killing active phone conversations, etc., but then when it tries >to do it's thing, it fails for "unable to send signal to init". So, it is >probably safe. It will however shut down your lp spooling system; /usr/lib/lpshut is setuid root, setgid bin, and world executable. For that matter, all of the /usr/lib/lp* lp admin stuff is setuid and world executable, so anyone can play with your line printer setup. I'll second the opinion of the person who called the 3B1 one of the most unsecure Unix systems around straight out of the box. Numerous important directories are world or group writeable, unsecure setuid applications about, and other similiar problems exist. If you're running any sort of public access site, you should take a good hard look at your system for security holes (interested people can send me mail and I'll write up a description of the holes I plugged here). -- "The hell I will!" WHAK! "Surpise, kid -- they retract! Try that again and I'll kick you back. With my claws." Chris Siebenmann uunet!utgpu!{ontmoh!moore,ncrcan}!ziebmef!cks cks@ziebmef.UUCP or .....!utgpu!{,ontmoh!,ncrcan!brambo!}cks
bzs@encore.com (Barry Shein) (11/25/88)
From: jr@amanue.UUCP (Jim Rosenberg) >To be truthful, I can hardly believe in light of all the concern for security >prompted by the (apparently) Morris Worm that anyone would seriously propose >leaving 755 permissions on something like /etc/shutdown, for crying out loud! >The off-the-shelf permissions on the 7300 are probably the worst of any >commercially released UNIX box ever seen on the face of the earth. You should >give your machine a thorough going over. Jim, with all due respect, this is awful, panic-stricken advice... If shutdown can be run w/o being root then it should take a 5 line C-program to effect the same thing if you protect it. You are wholly dependent on the fact that some syscalls are root-only and if you can't rely on it you are SOL, no amount of running around shutting off permissions on files will protect you. On my unix-pc running shutdown simply gives an error message and exits. All this kind of advice is doing is panicking people, making them waste their time doing things of questionable value and hence avoiding real issues (or at the very least burying it in a bad signal to noise ratio, distracting folks from understanding what they really need to do to get proper security on their system etc.) I'll turn it on its head, make your /etc/shutdown 755, if executing it from a non-super-uid account does anything then you've got much deeper problems that changing the mode on that file won't help at all and you'd better deal with those problems first. There are certainly ways to improve security *in general* by changing files to correct permissions, but let's get the list of correct, specific suggestions that actually will help before we start hearing "omigod i did as you said and made foo unexecutable and now i can't login/boot/compile [whatever]!!" etc and other incredible wastes of time. -Barry Shein, ||Encore||
jr@amanue.UUCP (Jim Rosenberg) (11/27/88)
In article <4272@encore.UUCP> bzs@encore.com (Barry Shein) writes: >From: jr@amanue.UUCP (Jim Rosenberg) >>To be truthful, I can hardly believe in light of all the concern for security >>prompted by the (apparently) Morris Worm that anyone would seriously propose >>leaving 755 permissions on something like /etc/shutdown, for crying out loud! >>The off-the-shelf permissions on the 7300 are probably the worst of any >>commercially released UNIX box ever seen on the face of the earth. You should >>give your machine a thorough going over. > >Jim, with all due respect, this is awful, panic-stricken advice... > >If shutdown can be run w/o being root then it should take a 5 line >C-program to effect the same thing if you protect it. You are wholly >dependent on the fact that some syscalls are root-only and if you >can't rely on it you are SOL, no amount of running around shutting off >permissions on files will protect you. ... >All this kind of advice is doing is panicking people, making them >waste their time doing things of questionable value and hence avoiding >real issues (or at the very least burying it in a bad signal to noise >ratio, distracting folks from understanding what they really need to >do to get proper security on their system etc.) ... >There are certainly ways to improve security *in general* by changing >files to correct permissions, but let's get the list of correct, >specific suggestions that actually will help before we start hearing >"omigod i did as you said and made foo unexecutable and now i can't >login/boot/compile [whatever]!!" etc and other incredible wastes of >time. Your points are certainly well-taken. I am more than willing to listen to sage advice from someone with as much UNIX experience as you have that I may be overreacting. But frankly I still stand by my general points, which are: (1) Good security means defense in depth. It is *NOT* being paranoid or panic-stricken to think of the permission system as the first line of defense, to try to get those permissions correct. (2) I still fail to see the wisdom of leaving o+x permissions on system administration commands -- unless there is some special reason for doing so and the sysadmin knows what [s]he is is doing. Of course the real protection is at the system call level. (2nd. line of defense.) In the case of my disagreeable user, the fellow knew enough about the UNIX permission system to know what to try to help himself to, but not enough to be compiling programs that make system calls. Tightening permissions was my way of telling him that I wasn't kidding. I could perfectly well turn around your argument that the kernel won't let ordinary users do the dirty work of shutdown [true] and say that making /etc/shutdown o-x won't make anything break, either [also true]. Holy smokes, Barry, we're talking about a system that as delivered has a setuid-root program with shell escapes that don't even change the effective uid back to the real uid!! It *is* true that 7300/3b1 as delivered *DOES NEED* a thorough going-over if it's to be put where security matters. That's been widely discussed up here. If you charge me of not being very enlightening to a novice system administrator as to how to do this, well I guess I'll plead guilty on that one. It would be silly to swap accusations of overreacting vs. underreacting -- now that would be *REAL* noise and no signal. We had a request for help on /etc/shutdown. o+x won't succeed, o-x won't hurt. Should we not, perhaps, help out some of those hundreds of fire-sale buyers by trying to come to some kind of agreement on where the real 3b1/7300 weaknesses are? -- Jim Rosenberg CIS: 71515,124 decvax!idis! \ WELL: jer allegra! ---- pitt!amanue!jr BIX: jrosenberg uunet!cmcl2!cadre! /
ins_anmy@jhunix.JHU.EDU (Norman Yarvin) (11/29/88)
In article <435@amanue.UUCP> jr@amanue.UUCP (Jim Rosenberg) writes: >... Good security means defense in depth. To quote Mark Twain: "Put all your eggs in one basket, and WATCH THAT BASKET!" This is the usual Unix metaphor for security: rectrict yourself to one level of defense, but make that level completely airtight. For instance, /etc/passwd is readable by the world. This is highly reasonable, as _the_ line of defense against password reading is the encryption of passwords. None other is needed. And the readability of the password file has the mental-attitude advantage that it focuses effort on the need for an uncrackable encryption algorithm. As emphasis, let me state that: - To have many imperfect levels of security is to have no security. - To have many imperfect levels and one perfect level of security is to have perfect security; but the imperfect levels might as well be bagged. - To have many perfect levels of security is to have perfect security, but again the extra perfect levels are surplus, and can be discarded. And it is possible, if one assumes the operating system to have no leaks, to have a perfect level of security (i.e. Unix with no setuid programs and no uid root daemons) Norman Yarvin (seismo!umcp-cs | allegra!hopkins) !jhunix!ins_anmy "Christmas -- the day when we celebrate the birth of a 2000 year old superstition by watching pine trees slowly die in our living rooms"
jr@amanue.UUCP (Jim Rosenberg) (11/30/88)
In article <295@jhunix.JHU.EDU> ins_anmy@jhunix.UUCP (Norman Yarvin) writes: >In article <435@amanue.UUCP> jr@amanue.UUCP (Jim Rosenberg) writes: > >>... Good security means defense in depth. > >To quote Mark Twain: "Put all your eggs in one basket, and WATCH THAT BASKET!" >This is the usual Unix metaphor for security: rectrict yourself to one level of >defense, but make that level completely airtight. For instance, /etc/passwd >is readable by the world. This is highly reasonable, as _the_ line of defense >against password reading is the encryption of passwords. None other is needed. >And the readability of the password file has the mental-attitude advantage that >it focuses effort on the need for an uncrackable encryption algorithm. I suggest you take this up with AT&T. Please tell them that they were full of horse puckey when they put shadow passwords into SVr3[.1? Too bad on the 3b1 we'll never see Vr3.anything.] If you think that the encryption algorithm of /etc/passwd is safe you are living in dreamland. In possession of /etc/passwd an algorithm to guess passwords will succeed if someone has used all kinds of categories of obvious passwords. The recent Worm succeeded something like 5% of the time just by guessing passwords!! The encryption algorithm is *NOT* "_the_" line of defense. crypt + poorly chosen password + public password file == no security. This is one of the reasons why AT&T has **DONE AWAY WITH** publicly readable passwords. Just to take this one example, a proper approach to password security includes the following layers: 1. Proper people procedures. (Do not write down your password next to your terminal, do not share your password with your co-workers, etc.) 2. Well-chosen passwords. This is currently being beaten to death on the net right now. 3. Password encryption. 4. o-r on the shadow password file. (/etc/passwd has all the fields that tools like ls need; the password field is there but not used.) That's 4 layers. Defense in depth means plan each layer as if it were all you had, then hope at least one of them holds. I think what you are suggesting is an invitation to disaster. I think defense in depth is just plain common sense. I will be most interested if you can site a literature reference showing where the defense in depth concept just plain doesn't work. Now I'm not an expert, but I have read some of the literature, & I know that there are some pretty smart people who make a convincing case that some security procedures are counter-productive. I've read a reasonable argument against too much su logging. I don't know if I agree with it, but a case was certainly made. But saying that the defense in depth concept makes no sense is like saying if you keep your brakes in good repair having a quick reaction time on the brake pedal isn't necessary. So, I still stand by defense in depth. *SHOW ME* a break-in that happened that points out a genuine flaw in the *concept*. -- Jim Rosenberg CIS: 71515,124 decvax!idis! \ WELL: jer allegra! ---- pitt!amanue!jr BIX: jrosenberg uunet!cmcl2!cadre! /
ins_anmy@jhunix.JHU.EDU (Norman Yarvin) (12/06/88)
In article <440@amanue.UUCP> jr@amanue.UUCP (Jim Rosenberg) writes: > ... Just to take this one example, a proper approach >to password security includes the following layers: > >1. Proper people procedures. (Do not write down your password next to your >terminal, do not share your password with your co-workers, etc.) > >2. Well-chosen passwords. This is currently being beaten to death on the net >right now. > >3. Password encryption. > >4. o-r on the shadow password file. (/etc/passwd has all the fields that >tools like ls need; the password field is there but not used.) > >That's 4 layers. It's two layers. One layer is composed of #1, #2, and #3; the other is #1, #2, and #4. A "layer" means a complete line of defense. Note that #1 and #2 are common to both layers, so that in some areas only one level has to be broken to completely break through the defenses. Thus one might further classify the above system as two layers in some respects, one layer in others. A multi-layer system is only as strong as the strongest layer. The only exception is when, although both layers are incomplete, all holes in the first layer are completely patched by the second. If the second layer is easier to put in place than to fix the first, then this is reasonable; normally it is easier to fix the first level. Thus if it is judged easier and as effective to add a shadow password file (#4) than to educate users (fix #2), then adding a shadow password file is reasonable. Adding a shadow password file to bolster the encryption algorithm is not reasonable, as the encryption algorithm is still the strongest layer. > ... I think defense in depth is just plain common >sense. IBM-style common sense, maybe. > ... I will be most interested if you can site a literature reference >showing where the defense in depth concept just plain doesn't work. Adding another level of defense will never lessen the security of a system, except in two ways: either (1) people get lax, seeing as they now have a backup layer, and forget the importance of maintaining the existing layers, or (2) the backup layer introduces a bug into the existing layers. The issue here is the sacrifice of elegant, small, fast systems at the altar of security. Or does anyone except me care about that sort of thing any more? > ... But saying that the defense in depth concept makes no sense is >like saying if you keep your brakes in good repair having a quick reaction time >on the brake pedal isn't necessary. More like saying that if you keep your windshield clean, having an extra mirror on the side of the car to see forward is unnecessary. Norman Yarvin (seismo!umcp-cs | allegra!hopkins) !jhunix!ins_anmy "Unix is a hard nut to crack: once you get off the shell, there's nothing there but the kernel."