rusty@belch.Berkeley.EDU (Rusty Wright) (12/11/90)
I just upgraded my DECstation 5000 to Ultrix 4.1 and the su bug from Ultrix 4.0 is still there. For those of you who missed my tirade when I upgraded to Ultrix 4.0, here's a synopsis of the problem. If your security level is set to ENHANCED you can't use the su command unless the tty line you're on is marked secure in /etc/ttys. On a time sharing system like a DECserver or a large VAX that's not so bad. But on a workstation running windows you'll almost always be on a tty that's a pseudo tty (unless you happen to have a dialin modem connected to your workstation) because of course that's what dxterm, xterm, etc. use. So you might think you could just edit /etc/ttys and add the secure keyword to all of the pseudo tty lines, but that would be a mistake because that would make your system less secure because that allows root logins over the network via rlogin or telnet; i.e., then some cracker could try to guess your root password. When I upgraded to Ultrix 4.0 I called the 800 number and reported this bug to the folks in Atlanta. The person I talked to understood the problem and agreed that it was a problem but there wasn't any patch available. He said the next thing to do was for me to bring it up with my local Field Service, which I did. They didn't understand the problem but they did investigate and their response was "that's the way it's supposed to be."
collins@triton.unm.edu (Bill Collins CIRT) (12/11/90)
In article <RUSTY.90Dec10144456@belch.Berkeley.EDU> rusty@belch.Berkeley.EDU (Rusty Wright) writes: >I just upgraded my DECstation 5000 to Ultrix 4.1 and the su bug from >Ultrix 4.0 is still there. For those of you who missed my tirade when >I upgraded to Ultrix 4.0, here's a synopsis of the problem. I haven't. I have noticed the "bug." >If your security level is set to ENHANCED you can't use the su command >unless the tty line you're on is marked secure in /etc/ttys. > ... >add the secure keyword to all of the pseudo tty lines, but that would >be a mistake because that would make your system less secure because >that allows root logins over the network via rlogin or telnet; i.e., >then some cracker could try to guess your root password. Repeated login failures are recorded. Guessing from outside would(should) be noticed, especially in ENHANCED mode. > They didn't understand >the problem but they did investigate and their response was "that's >the way it's supposed to be." I supposed it may be argued either way. Adding "secure" after a device could mean that root access is allowed, how Digital seems to understand it. Or adding "secure" means that initial root access(eg, rlogin, telnet.) The former suggestion is that a device, any device, is considered safe and "secure"(ie, allowed root access) or it isn't. "Root" access is the same here, regardless of the method(eg, su(1), telnet(1), rlogin(1).) The latter suggests that if a user has an account, legitimate or otherwise, and accesess to su(1), then the device which he/she is on is secured by the fact the user has an account. This may not always be true. The avenue does provide some additional tracking, by chance, as the account which uses su(1) is given. Perhaps the questions may be posed in this fashon, "is the 'network' secure?" To what extent to you mean to secure root access? After all, you can write your own su program if you wish, it's not hard. 4.x ENHANCED behavior doesn't seem to hard to accept, or work around. Bug? perhaps not. Just a different understanding. Bill collins@triton.unm.edu p.s. beware of the 5th column! -- Internet: collins@ariel.unm.edu BITnet: collins@unmb.bitnet
mjr@hussar.dco.dec.com (Marcus J. Ranum) (12/11/90)
rusty@belch.Berkeley.EDU (Rusty Wright) writes: >I just upgraded my DECstation 5000 to Ultrix 4.1 and the su bug from >Ultrix 4.0 is still there. For those of you who missed my tirade when >I upgraded to Ultrix 4.0, here's a synopsis of the problem. > >If your security level is set to ENHANCED you can't use the su command >unless the tty line you're on is marked secure in /etc/ttys.[...] >But on a workstation running windows you'll almost always be on a tty >that's a pseudo tty[...] I see the idea of 'su' and ENHANCED security as mutually exclusive, to tell you the truth. If you are running under ENHANCED mode, you should be serious enough about security not to want anyone rooting around on the machine as "root" unless they log in as "root" on a secure tty (in this case, *the* secure tty). I mean, if you want to be able to 'su' to "root" on an unsecure terminal, the code is trivial to write - a setuid "root" program that checks "root"'s password, then execs a shell. But, then, you've bypassed your security, and you may as well not run ENHANCED. I'm not convinced what you've got is a bug. It may be a feature. :) mjr. -- I'd trade all the CASE tools in the world for one real programmer. [From the programming notebooks of a heretic, 1990]
barmar@think.com (Barry Margolin) (12/12/90)
In article <1990Dec11.045743.27648@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: > I see the idea of 'su' and ENHANCED security as mutually exclusive, >to tell you the truth. If you are running under ENHANCED mode, you should >be serious enough about security not to want anyone rooting around on the >machine as "root" unless they log in as "root" on a secure tty (in this case, >*the* secure tty). You're missing the point. He would like to limit use of "root" to *the* secure tty, which is the workstation's console. However, when using a window system, the console device is taken over, and all the ttys on the console are implemented using pseudo ttys. However, pseudo ttys are also used by the servers for telnet and rlogin. There's no way to distinguish the two uses in configuring the security parameters; either tty[p-w]* are marked secure or they aren't. Furthermore, it's not even good enough to distinguish terminal emulator windows from remote logins. With X windows, terminal windows may be displayed on remote terminals. You only want terminal windows displaying on the console to be considered secure. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
Sm@cerberus.bhpese.oz.au (Scott Merrilees) (12/12/90)
mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: > I see the idea of 'su' and ENHANCED security as mutually exclusive, >to tell you the truth. If you are running under ENHANCED mode, you should >be serious enough about security not to want anyone rooting around on the >machine as "root" unless they log in as "root" on a secure tty (in this case, >*the* secure tty). It seems that your ideas and mine are totally opposed. I think that log in as root should be avoided in just about all cases, and that the priviledged user should first log into their own account, then su to root where necessary. This provides much better tracking of root access than having someone log into root to do something, which leaves you with the problem: Who was it? Programmer A or B or C ? If you are logged into a workstation, and need to do something, and you have to root password, then you should be able to su, and do it, and su will even write a nice audit record for you. Sm -- Scott Merrilees, BHP Information Technology, Newcastle, Australia Internet: Sm@bhpese.oz.au Phone: +61 49 402132
mjr@hussar.dco.dec.com (Marcus J. Ranum) (12/12/90)
Sm@cerberus.bhpese.oz.au (Scott Merrilees) writes: > This provides much better tracking of root >access than having someone log into root to do something, which leaves >you with the problem: Who was it? Programmer A or B or C ? If you're running enhanced security, presumably your environment isn't the type where you have 3 programmers just logging in as root or 'su'ing at the drop of a hat. *enhanced* implies you're serious about security, and presumably you have some kind of additional controls or change tracking in place - not just "I needed to edit the password file so I su'd to root". We're talking having programmer A notify the site security officer that they're going to log in as root and add the following accounts, thank you - if you're not *that* serious about security, either re-write 'su' or don't run enhanced. It's my impression that running enhanced means you're into security enought that you are also using the other C2 stuff - access failure logging, file creation, modification logging - the whole ball of wax. (which nobody in their right mind but a spook is going to want to do) mjr. -- Somehow, "features" became the driving force behind applications, rather than getting the job done efficiently and cleanly. Conceptually, this is the equivalent of selling cars based only on the layouts of their dashboards. [From the programming notebooks of a heretic, 1990]
catone@scrolls.wharton.upenn.edu (Tony Catone) (12/14/90)
In article <1990Dec12.024324.13947@cerberus.bhpese.oz.au> Sm@cerberus.bhpese.oz.au (Scott Merrilees) writes: >It seems that your ideas and mine are totally opposed. I think that >log in as root should be avoided in just about all cases, and that the >priviledged user should first log into their own account, then su to >root where necessary. . . This would be fine, except that the su command does not work properly on all Unix implementations. That is, command behavior is not identical for root login and su'ing to root. My most recent encounter with this problem has been IBM AIX PS/2 1.1. The same problem existed in IBM AIX RT 2.2.1; behavior was even worse that PS/2 1.1. I don't know how Ultrix behaves on this scale, since we are just setting up our 5000/200's, but in general I am wary of the su command for these reasons. Root logins always work; su may or may not; life is complicated enough without these problems. - Tony catone@desci.wharton.upenn.edu
ellhan@raxco.UUCP (Elliot Hans) (12/14/90)
In article <RUSTY.90Dec10144456@belch.Berkeley.EDU>, rusty@belch.Berkeley.EDU (Rusty Wright) writes: | | If your security level is set to ENHANCED you can't use the su command | unless the tty line you're on is marked secure in /etc/ttys. On a | time sharing system like a DECserver or a large VAX that's not so bad. | But on a workstation running windows you'll almost always be on a tty | that's a pseudo tty (unless you happen to have a dialin modem | connected to your workstation) because of course that's what dxterm, | xterm, etc. use. So you might think you could just edit /etc/ttys and | add the secure keyword to all of the pseudo tty lines, but that would | be a mistake because that would make your system less secure because | that allows root logins over the network via rlogin or telnet; i.e., | then some cracker could try to guess your root password. I wonder how many things would break if DEC were to assign a different class of pseudo-ttys strictly for use with DECwindows? Does anyone know whether it would be feasible (instead of ttyp1, ttyp2, etc., DECwindows would use ttydw1, ttydw2, and so on)? You could then make the windows secure without opening up root access to the network.
treese@crl.dec.com (Win Treese) (12/14/90)
I can imagine sites that want the C2 features but allow the ability to su on a pseudo-tty without letting root login there directly. It seems to me that there is a straightforward solution to this: add another keyword for /etc/ttys (e.g., "allowsu"). I'm not speaking for Digital, of course. Just a thought. Win Treese Cambridge Research Lab treese@crl.dec.com Digital Equipment Corp.