robert@pvab.UUCP (Robert Claeson) (08/24/87)
I'm about to use an asynchronus terminal as console to a Sun-2/130.
I 've heard that this dumb machine will ehter the prom monitor if I'll
ever try to unplug the console, plug out its power cord or if I press
the Break button. Is there any way to circumvent this strange behaviour?
Are there any pins on the ttya port (the one I use as console port for
my async terminal) I can fool to make the machine think the console
terminal is connected all the time?
--
SNAIL: Robert Claeson, PVAB, P.O. Box 4040, S-171 04 Solna, Sweden
UUCP: {seismo,mcvax,munnari}!enea!pvab!robert
ARPA: enea!pvab!robert@seismo.arpaguy%gorodish@Sun.COM (Guy Harris) (08/25/87)
> I'm about to use an asynchronus terminal as console to a Sun-2/130. > I 've heard that this dumb machine will ehter the prom monitor if I'll > ever try to unplug the console, plug out its power cord or if I press > the Break button. Is there any way to circumvent this strange behaviour? There is nothing intrinsically strange about this behavior. Modern machines tend to use a terminal, rather than a bunch of buttons and lights, as a control panel. Such machines often tend to "double up", using the same terminal for the system console ("/dev/console" for UNIX) and for the control panel. This is often done by having some magic key or keys that switch the terminal between the two modes. Using a control character can be a nuisance if this behavior cannot be disabled; the character tends to be ^P on DEC systems, which would probably annoy people whose systems have a CRT as their console and who use EMACS on that console. (One Sun I use has a CRT as its console and yes, I do use EMACS on it.) Using a "break" as the signal in question has some advantages; the BREAK key less likely to be typed as part of normal use than might a control key, and it's easier to produce if your terminal is somehow gronked - just unplug the terminal and plug it back in again. If you have a "console processor", jumping to console mode may not be noticeable, as the CPU will continue. Suns (and many other machines) don't have console processors, so this magic signal has to stop the machine. If you end up going to the PROM monitor as a result of a BREAK signal, you can type the "c" (continue) command, followed by a RETURN, and it will pick up where it left off (in most cases, anyway; I haven't seen any cases where it couldn't do this and it wasn't already wedged, but they may exist). Perhaps there should have been a "disable" switch; I don't know whether this was not considered or was considered and rejected (for e.g. cost reasons). > Are there any pins on the ttya port (the one I use as console port for > my async terminal) I can fool to make the machine think the console > terminal is connected all the time? The pin on the tty port that it uses for break detection is, of course, the RxD pin; you probably don't want to fool that pin.... Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
david@elroy.Jpl.Nasa.Gov (David Robinson) (08/26/87)
In article <26419@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: ... Discussion of CRT as console > > Perhaps there should have been a "disable" switch; I don't know whether this > was not considered or was considered and rejected (for e.g. cost reasons). This brings up a problem that exists with Suns that I have. The Suns are inherently insecure because anyone using a 3/50 can just power off the machine and reboot it in single user mode and become root. I hope some marketroids are listening, it would be real nice to have a hardware switch that disables the console from interuptting the CPU with an L1-A or BREAK, with a key lock of course. I realize that this would be tough to add in the existing machines because the PROM monitor would need to be rewritten but I think a lot of organizations would pay for the feature in the future. -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov (new) seismo!cit-vax!elroy!david UUCP Disclaimer: No one listens to me anyway!
steve@mimsy.UUCP (Steve D. Miller) (08/26/87)
We had a similar problem with Suns here at U. of Maryland. We have a
graphics lab with some Suns in it, and we too worried about people hosing
things on our net by powering one down and becoming root. The solution we
(we == Fred Blonder, with input from some others as to what should be done;
I wasn't involved) implemented was to hack init to ask for a password before
going into single-user mode. Of course, we had to hard-code the password,
but it's better than nothing and doesn't require hacking the PROMs.
As many of you probably realize, this isn't the most secure of solutions,
either.
-Steve
--
Spoken: Steve Miller ARPA: steve@mimsy.umd.edu Phone: +1-301-454-4251
CSNet: steve@mimsy.umd.edu UUCP: {seismo,allegra}!mimsy!steve
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742barnett@vdsvax.steinmetz.UUCP (Bruce G Barnett) (08/26/87)
In article <4341@elroy.Jpl.Nasa.Gov> david@elroy.Jpl.Nasa.Gov (David Robinson) writes: |This brings up a problem that exists with Suns that I have. The Suns |are inherently insecure because anyone using a 3/50 can just |power off the machine and reboot it in single user mode and become |root. The solution we use here is to add login root to /.profile Voila! Any other ideas/suggestions? -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
chapman@eris.BERKELEY.EDU (Brent Chapman) (08/27/87)
In article <2363@vdsvax.steinmetz.UUCP> barnett@vdsvax.steinmetz.UUCP (Bruce G Barnett) writes: #In article <4341@elroy.Jpl.Nasa.Gov> david@elroy.Jpl.Nasa.Gov (David Robinson) writes: #|This brings up a problem that exists with Suns that I have. The Suns #|are inherently insecure because anyone using a 3/50 can just #|power off the machine and reboot it in single user mode and become #|root. #The solution we use here is to add # # login root # #to /.profile I don't think this is sufficient, because if 'login' exits (in the case of a timeout, or whatever), the execution of /.profile continues as normal. So all you need to do to beat this installation is to wait sixty seconds for the login to timeout... The solution, of course, is to put "/etc/halt" as the next line in the /.profile after the "login root". That way, if the login times out, the system just halts. You might also want to add traps for interrupts to the /.profile, to prevent someone from interrupting the /.profile execution before it reaches the "login root" line (tricky, I know, but possible none the less). -Brent -- Brent Chapman Senior Programmer/Analyst chapman@mica.berkeley.edu Capital Market Technology, Inc. ucbvax!mica!chapman 1995 University Ave., Suite 390 Phone: 415/540-6400 Berkeley, CA 94704
beede@hubcap.UUCP (09/01/87)
in article <2363@vdsvax.steinmetz.UUCP>, barnett@vdsvax.steinmetz.UUCP (Bruce G Barnett) says: -> -> In article <4341@elroy.Jpl.Nasa.Gov> david@elroy.Jpl.Nasa.Gov (David Robinson) writes: -> |This brings up a problem that exists with Suns that I have. The Suns -> |are inherently insecure because anyone using a 3/50 can just -> |power off the machine and reboot it in single user mode and become -> |root. -> -> The solution we use here is to add -> -> login root -> -> to /.profile -> -> Voila! -> -> Any other ideas/suggestions? I tried this with the result everyone seems to predict (at least here): you get in an infinite login duel with the workstation. When sh starts up, it executes /.profile, which starts a login, etc. If you put ``login root'' in /etc/rc.boot, the results are even worse. Unless there is a trick, adding ``login root'' to /.profile is not effective, and writing an access checker is the way to go. Needless to say (but I will . . .) I'd like to hear about said trick. -- Mike Beede Computer Science Dept. UUCP: . . . !hubcap!beede Clemson University INET: beede@hubcap.clemson.edu Clemson SC 29634-1906 YOUR DIME: (803)656-{2845,3444}
matt@oddjob.UChicago.EDU (Matt Crawford) (09/01/87)
In article <418@hubcap.UUCP> beede@hubcap.UUCP (Mike Beede) writes:
) Unless there is a trick, adding ``login root'' to /.profile is not
) effective, and writing an access checker is the way to go.
Hmmm. What if you do this, and then make root's shell be /bin/csh?
________________________________________________________
Matt University matt@oddjob.uchicago.edu
Crawford of Chicago {astrovax,ihnp4}!oddjob!mattron@topaz.rutgers.edu.UUCP (09/01/87)
Rutgers hacked the bootstrap to ask for a password you ask to boot single user. It's not fool proof, but probably nothing is. -Ron
gdelong@cvbnet.UUCP (Gary Delong) (09/04/87)
In article <418@hubcap.UUCP>, beede@hubcap.UUCP (Mike Beede) writes: -> in article <2363@vdsvax.steinmetz.UUCP>, barnett@vdsvax.steinmetz.UUCP (Bruce G Barnett) says: -> -> -> -> In article <4341@elroy.Jpl.Nasa.Gov> david@elroy.Jpl.Nasa.Gov (David Robinson) writes: -> -> |This brings up a problem that exists with Suns that I have. The Suns -> -> |are inherently insecure because anyone using a 3/50 can just -> -> |power off the machine and reboot it in single user mode and become -> -> |root. -> -> -> -> The solution we use here is to add -> -> -> -> login root -> -> -> -> to /.profile -> -> -> -> Voila! -> -> -> -> Any other ideas/suggestions? -> -> I tried this with the result everyone seems to predict (at least -> here): you get in an infinite login duel with the workstation. When -> sh starts up, it executes /.profile, which starts a login, etc. -> -> If you put ``login root'' in /etc/rc.boot, the results are even -> worse. -> -> Unless there is a trick, adding ``login root'' to /.profile is not -> effective, and writing an access checker is the way to go. -> -> Needless to say (but I will . . .) I'd like to hear about said trick. On our sun 3/160s, I have "login root" as the first line in /.profile and it works like a champ. BTW: You might want to make sure your /etc/passwd entry for root uses /bin/csh as the startup shell. -- _____ / \ / All spelling errors | Gary A. Delong, N1BIP | \ / intentional for testing | linus!raybed2!cvbnet!gdelong \____\/ rn spellcorrector v1.02A. | (617) 275-1800 x5232