arnold@emory.uucp (Arnold D. Robbins {EUCC}) (09/08/88)
In article <14186@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes: >.... I think SunOS 4.0 can be configured to require the >superuser password before coming up in single user mode. > >My only information regarding this feature in SunOS 4.0 is a brief >mention in the 4.0 release notes, so I may have mis-interpreted it. >No doubt someone will correct me if I have. This feature is straight-forward, and fairly elegant. The file /etc/ttytab is in the format of the 4.3BSD /etc/ttys: # name getty type status comments # console "/usr/etc/getty std.9600" sun on secure The 'secure' on the line for the console has the usual meaning of "root can log in on this terminal", and is also overloaded to mean "OK, you can come up with a single user root shell". If 'secure' is missing, or /etc/ttytab is not there, then the system prompts for the root password when booting single user. This could profitably be incorporated into future BSD releases. -- Arnold Robbins -- Emory University Computing Center DOMAIN: arnold@unix.cc.emory.edu (finally!) UUCP: { decvax, gatech, skeeve }!emory!arnold BITNET: arnold@emoryu1 PHONE: +1 404 727-7636
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (09/08/88)
In article <14186@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes: >.... I think SunOS 4.0 can be configured to require the >superuser password before coming up in single user mode. I posted to Sun-Spots (v6n24) a simple program that can be used to make a Sun 3.X machine require a password when booting up single user. It gets executed at the end of /.profile (which is only executed on single user boot). The same scheme should work for any other machine with a similar boot mechanism. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
ndd@romeo.cs.duke.edu (Ned D. Danieley) (09/08/88)
In article <3168@emory.uucp> arnold@emory.UUCP (Arnold D. Robbins {EUCC}) writes: >In article <14186@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes: >>.... I think SunOS 4.0 can be configured to require the >>superuser password before coming up in single user mode. >> ... >This feature is straight-forward, and fairly elegant. The file /etc/ttytab ... >The 'secure' on the line for the console has the usual meaning of "root >can log in on this terminal", and is also overloaded to mean "OK, you can >come up with a single user root shell". If 'secure' is missing, or /etc/ttytab >is not there, then the system prompts for the root password when booting >single user. ... >Arnold Robbins -- Emory University Computing Center >DOMAIN: arnold@unix.cc.emory.edu (finally!) If I understand what you've described, the only way to protect a workstation from someone booting it single user is to deny root the ability to log in on that workstation. Doesn't sound very elegant to me. Ned Danieley (ndd@sunbar.mc.duke.edu) Basic Arrhythmia Laboratory Box 3140, Duke University Medical Center Durham, NC 27710 (919) 684-6807 or 684-6942
loverso@encore.UUCP (John Robert LoVerso) (09/08/88)
In article <3168@emory.uucp> arnold@emory.UUCP (Arnold D. Robbins) writes: > This feature is straight-forward, and fairly elegant. The file /etc/ttytab > is in the format of the 4.3BSD /etc/ttys: > > # name getty type status comments > # > console "/usr/etc/getty std.9600" sun on secure > > The 'secure' on the line for the console has the usual meaning of "root > can log in on this terminal", and is also overloaded to mean "OK, you can > come up with a single user root shell". If 'secure' is missing, or /etc/ttytab > is not there, then the system prompts for the root password when booting > single user. > > This could profitably be incorporated into future BSD releases. I hope not. Sun has managed to corrupt "secure". It originally meant "it's ok for root to login on this line WITH A PASSWORD in multi-user mode". Now it additionally means "DON'T prompt for a password when coming up single user". Without "secure" on the console, single-user mode will prompt for a password. I maintain that allowing a root login on a line in multi-user AT ALL and allowing a single-user root shell without password are entirely different things, and at best they ought to use a different flag than "secure" in the ttys [ttytab] file. John Robert LoVerso Encore Computer Corp encore!loverso, loverso@multimax.arpa, [soon: loverso@Encore.COM]
stevo@judy.Jpl.Nasa.Gov (Steve Groom) (09/09/88)
In article <12397@duke.cs.duke.edu> ndd@romeo.UUCP (Ned D. Danieley) writes: >If I understand what you've described, the only way to protect a >workstation from someone booting it single user is to deny root >the ability to log in on that workstation. Doesn't sound very elegant >to me. But it only denies them the ability to *log in* as root. It doesn't stop you from using su to become root, which I view as preferable to logging in as root anyway. As a policy, we use su instead of logging in as root. We haven't enforced it completely by turning of 'secure', but we've thought about it. The reason is simple. Su leaves a better trail around, telling you who that really was. If all you have is the fact that root logged in on ttyx at nn:nn:nn, that doesn't tell you anything about who it might have been that did it. Sounds pretty elegant to me. -steve /* Steve Groom, Jet Propulsion Laboratory, Pasadena, CA 91109 * Internet: stevo@elroy.jpl.nasa.gov UUCP: {ames,cit-vax}!elroy!stevo * Disclaimer: (thick German accent) "I know noothingg! Noothingg!" */
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (09/09/88)
In article <12397@duke.cs.duke.edu> ndd@romeo.UUCP (Ned D. Danieley) writes: |If I understand what you've described, the only way to protect a |[SunOS 4.0] workstation from someone booting it single user is to deny root |the ability to log in on that workstation. Doesn't sound very elegant |to me. The "secure" flag means the console is in a secure (i.e. private) location. When the flag is missing, (i.e. anyone has access to the console) the password is needed to boot up single user mode. Also, root cannot log in on that terminal. Instead, you have to log in as a user and do a 'su'. You can restrict the people allows to su to root by an entry in /etc/group. You can still rlogin as root, if the /.rhosts lets you. The solution seems "elegant" and consistant to me. I don't find it to me a problem. I can quickly log in as root from MY workstation. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
ndd@romeo.cs.duke.edu (Ned D. Danieley) (09/09/88)
In article <9182@elroy.Jpl.Nasa.Gov> stevo@jane.jpl.nasa.gov (Steve Groom) writes: >In article <12397@duke.cs.duke.edu> ndd@romeo.UUCP (Ned D. Danieley) writes: (my complaint about the 'secure' feature not being elegant) > >But it only denies them the ability to *log in* as root. It doesn't >stop you from using su to become root, which I view as preferable to >logging in as root anyway.... ... >The reason is simple. Su leaves a better trail around, telling you who >that really was.... ... >Sounds pretty elegant to me. > >-steve >/* Steve Groom, Jet Propulsion Laboratory, Pasadena, CA 91109 > * Internet: stevo@elroy.jpl.nasa.gov UUCP: {ames,cit-vax}!elroy!stevo > * Disclaimer: (thick German accent) "I know noothingg! Noothingg!" > */ I knew when I sent out the original article I should have mentioned su. Of course, you can still su to root, but >I< don't want to have to log in as me and then su to root every time I need to, say, do a quick shutdown. Especially when it's trivial to add a passwd check to init; this avoids bastardizing the meaning of 'secure'. Of course, you can turn this argument around on me, and say that you don't want to have to type in the root passwd every time you boot single-user, but I log in as root much more often than I boot single user. Put a passwd check in init, and those who want to allow root logins can do so without giving people root access on single user boots; seems like a much more elegant solution to me. Ned Danieley (ndd@sunbar.mc.duke.edu) Basic Arrhythmia Laboratory Box 3140, Duke University Medical Center Durham, NC 27710 (919) 684-6807 or 684-6942
rwhite@nusdhub.UUCP (Robert C. White Jr.) (09/13/88)
in article <12397@duke.cs.duke.edu>, ndd@romeo.cs.duke.edu (Ned D. Danieley) says: > If I understand what you've described, the only way to protect a > workstation from someone booting it single user is to deny root > the ability to log in on that workstation. Doesn't sound very elegant > to me. Actually, I don't see what would be wrong with requiring a user to log in as themselves and then su to root. That way you would have some record of who did what when. Of course a smart little sniper would just empty/edit sulog, but making only normal logins legal, and then allowing su generally makes sense to me. Rob.
eirik@tekcrl.TEK.COM (Eirik Fuller) (09/14/88)
In article <1157@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
< ...
< That way you would have some record of who did
< what when. Of course a smart little sniper would
< just empty/edit sulog, but making only normal logins
< legal, and then allowing su generally makes sense to
< me.
He'd have to be a pretty smart sniper to edit the decwriter console
log on our vax :-)
I know, I know, this has nothing to do with a workstation whose
console is the screen.