trebor@biar.UUCP (Robert J Woodhead) (03/07/89)
Thanks to the many people who mailed me on how to set up an AUTO account. You got me pointed in the right direction, although there were a few twists and turns that nobody expected. Here is the procedure that works for me: ---------------------------------------------------------------------------- How to set up an AUTO login account in SCO Xenix in XX easy steps. 1) Select the port you want to use for AUTO login. I chose tty08, one of my multiscreens, for my testing. 2) Disable the port; execute "disable tty08" (everything done from root) 3) Examine /etc/ttys and note the entry for tty08. In my case it was "0mtty08". 4) Edit /etc/gettydefs and find the current entry for tty08. This is the entry that starts with the letter that was the second character in the /etc/ttys entry. In this case, it is "m", which in my file was m # B9600 HUPCL # B9600 CS8 SANE HUPCL TAB3 ECHOE IXANY # \r\n@ login: # m Make a copy of this entry, paste it in at the end of the file, and modify it as follows: change the two m's to the first unused entry, in my case, "p". Add "# AUTO /etc/login" to the end of the line. Most important, take all the entries in the third field and add them to the second field. If you don't do this, your login will come up in RAW mode, which is disconcerting to say the least. It seems that when you do an AUTO login, a stty with the arguments in the third field is not done, because getty is being bypassed. Thus my new entry looked like this: p # B9600 HUPCL CS8 SANE TAB3 ECHOE IXANY # B9600 CS8 SANE HUPCL TAB3 \ ECHOE IXANY # \r\n@ login: # p # AUTO /etc/login All on one line, of course. When you save this file, make sure that your editor doesn't muck up the permissions (mg did). 5) Use mkuser to create a new user named for the terminal; in my case the user was named "tty08". 6) Edit /etc/passwd and change the password field of "tty08" to null. Otherwise you will be asked for a password. Note that this opens up a security hole in your system as anyone who is in the know can now log into your system under this account. 7) enable the port with "enable tty08" and you should be up and running. If not, reboot your system (We did a lot of mucking around because of the raw mode problem, so it's unclear to us if you need to reboot and we are too lazy to go check). Thats all there is to it. I am however VERY disturbed about the security hole created by the AUTO process. It seems to me that if they have gone to the trouble to provide the AUTO escape, then there should be a way to restrict certain accounts to certain terminals. In this case I can just put some code in the .profile to check if tty returns '/dev/tty08' and log the user out if not (right?), but is there a better way to do this? And is the above approach secure? +---------------------------------------------------------------------------+ | Robert J Woodhead !uunet!cornell!biar!trebor CompuServe 72447,37 | | Biar Games, Inc., 10 Spruce Lane, Ithaca NY 14850 607-257-1708,3864(fax) | +---------------------------------------------------------------------------+ | Games written, Viruses killed "I'm the head honcho of this here spread; | | While U Wait. Take a number. I don't need no stinking disclaimers!!!" | +---------------------------------------------------------------------------+
richard@neabbs.UUCP (RICHARD RONTELTAP) (03/09/89)
[ AUTO in XENIX gettydefs ] I can think of two ways for secure AUTO usage. (We use it to start up our BBS software) 1 - Let the login come up in RAW mode. In stead of editing gettydefs so that SANE mode is set (move stuff to the second field), keep it in RAW mode. Set up your .profile (or .cshrc) so that interrupt signals are trapped or ignored before you go to SANE with stty, and start up your 'safe' software. (In our case, the BBS) 2 - Let the AUTO user log in to a restricted shell (rsh). The restricted shell will terminate immediately on receipt of the interrupt character. A minor annoyance of this method is, when you start a shell from your own software, it is still restricted. To circumvent this, make a small C program that sets the environment variable SHELL to "/bin/sh", and *subsequently* starts up "/bin/sh". Richard (...!mcvax!neabbs!richard)
andrew@stl.stc.co.uk (Andrew Macpherson) (03/11/89)
In article <190@biar.UUCP> trebor@biar.UUCP (Robert J Woodhead) writes: | | Thats all there is to it. I am however VERY disturbed about the security | hole created by the AUTO process. It seems to me that if they have gone | to the trouble to provide the AUTO escape, then there should be a way to | restrict certain accounts to certain terminals. In this case I can just | put some code in the .profile to check if tty returns '/dev/tty08' and | log the user out if not (right?), but is there a better way to do this? And | is the above approach secure? | You missed out 1 step, since the "AUTO" account is going to be running your dedicated process "/etc/mylogin" or whatever, replace tty08's shell with something useless of your own devising which will give an appropriate rude message to anyone trying to login as tty08 on another port. Andrew Macpherson | God bless the King! --- I mean the Faith's Defender PSI%234237100122::andrew | God bless (no harm in blessing) the Pretender! andrew@stl.stc.co.uk | But who Pretender is, or who the King, --- ..mcvax!ukc!stl!andrew | God bless us all! That's quite another thing.
geertj@nlgvax.UUCP (Geert Jan de Groot) (03/13/89)
In article <190@biar.UUCP> trebor@biar.UUCP (Robert J Woodhead) writes: >How to set up an AUTO login account in SCO Xenix in XX easy steps. > >4) Edit /etc/gettydefs and find the current entry for tty08. > [Add a new entry like:] >p # B9600 HUPCL CS8 SANE TAB3 ECHOE IXANY # B9600 CS8 SANE HUPCL TAB3 \ >ECHOE IXANY # \r\n@ login: # p # AUTO /etc/login > >6) Edit /etc/passwd and change the password field of "tty08" to null. > Otherwise you will be asked for a password. Note that this opens > up a security hole in your system as anyone who is in the know can > now log into your system under this account. > >Thats all there is to it. I am however VERY disturbed about the security >hole created by the AUTO process. I found a workaround for that too. My solution isn't nice, but it works, and maybe helps you.. I use the '-' option of su, which provides a full login, without asking passwords.. However, the AUTO feature of getty does not allow command-like arguments, so I made something like this: (program calles 'su-.c') /* su- - exec "su - <args>" */ main(argc, argv) int argc; char *argv[]; { if (argc == 2) execl("/bin/su", "su", "-", argv[1], (char *) 0); } Compile this program, and place it in your favorite local bin directory. It does not need special privileges. If you execute this program, you really execute 'su - <loginname>' which provides a full-blown login, without password checking. Of course, the password test is only skipped if the program is executed by root, but since getty runs under root, it has that privilege. Now, change the /etc/gettydefs entry to use su- instead of login: p # B9600 CS8 SANE HUPCL TAB3 ECHOE IXANY # # # p # AUTO /u/local/bin/su- Now you can place a password in the autostart-account passwd entry. One final note: I found getty requires something after a AUTO gettydefs entry. Therefore, if you add the new entry at the end, append a comment line as last line to /etc/gettydefs or the trick may not work. I found the -c option of getty very handy. I hope this is secure. Geert Jan _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. Geert Jan de Groot, Email: geertj@nlgvax.pcg.philips.nl Philips Research Laboratories, ..!mcvax!nlgvax!geertj Project Centre Geldrop, Building XP, Room 4, Willem Alexanderlaan 7B, "MS-DOS is just a bootstrap" - me 5664 AN Geldrop, The Netherlands. phone: +31 40 892204 [Standard disclaimers apply]