como@max.bnl.gov (Andrew T. Como) (06/13/91)
I need a mechanism to restrict root logins to the console. If I change the user characteristics "valid TTYs" to the console you can only "su" to "root" from the console. (this is not practical) I have submitted a system change request to IBM and they refused. Can anyone give me advice on a work around? Andrew Como INTERNET: como@bnl.gov BITNET: como@bnlux0.BITNET UUCP: ...philabs!sbcs!bnl!como or bnlux0!como@uunet.uu.net
shaggy@kleikamp.austin.ibm.com (David J. Kleikamp) (06/13/91)
In article <1991Jun12.180648.27815@bnlux1.bnl.gov> como@max.bnl.gov (Andrew T. Como) writes: > >I need a mechanism to restrict root logins to the console. > >If I change the user characteristics "valid TTYs" to the console >you can only "su" to "root" from the console. (this is not practical) > > Andrew Como Okay, I'll ask. What good is it to restrict root logins to the console if you do allow other users to su to root from other TTY's? Anyway, one way of doing this would be to write your own authentication method. I've never done this myself, but you define the authentication methods in the /etc/security/login.cfg file. -- --------------------------------------------------------------------------- David J. "Shaggy" Kleikamp dave@kleikamp.austin.ibm.com The content of this posting is independent of official IBM position. External: uunet!cs.utexas.edu!ibmaus!auschs!kleikamp.austin.ibm.com!dave
gs26@prism.gatech.EDU (Glenn R. Stone) (06/14/91)
In <8439@awdprime.UUCP> shaggy@kleikamp.austin.ibm.com (David J. Kleikamp) writes: >In article <1991Jun12.180648.27815@bnlux1.bnl.gov> como@max.bnl.gov (Andrew T. Como) writes: >>I need a mechanism to restrict root logins to the console. >>If I change the user characteristics "valid TTYs" to the console >>you can only "su" to "root" from the console. (this is not practical) >Okay, I'll ask. >What good is it to restrict root logins to the console if you do allow other >users to su to root from other TTY's? It means that you have two levels of security.... you have to either crack another account or get in the machine room door before getting a shot at root. >Anyway, one way of doing this would be to write your own authentication >method. I've never done this myself, but you define the authentication >methods in the /etc/security/login.cfg file. Sounds like the best way to go to me.... somethng like (pseudocode follows) if (I'm on the console) or (root does NOT own my tty (i.e. I'm su'ed)) exit successfully else rant, rave, raise red flags endif should work.... I assume there's TFM on secondary authentication methods.... -- Glenn R. Stone gs26@prism.gatech.edu
vrbass@atlvmic1.vnet.ibm.com (06/14/91)
>>>I need a mechanism to restrict root logins to the console. chuser telnet=false rlogin=false should do the trick if your other terminals are on the network. If you have both network and serial terminals, you're going to have to go to the secondary authentication methods mentioned earlier. From: Vance R. Bass AIX Systems Specialist, IBM Knoxville Internet: vrbass@atlvmic1.vnet.ibm.com VNET: ATLVMIC1(VRBASS) Any resemblance between the above and the official IBM position is purely coincidental. +----------------------------------------------------------------------+ | You think you know when you learn, are more sure when you can write, | | even more when you can teach, but certain when you can program. | +----------------------------------------------------------------------+
jfh@greenber.austin.ibm.com (John F Haugh II) (06/14/91)
In article <1991Jun12.180648.27815@bnlux1.bnl.gov> como@max.bnl.gov (Andrew T. Como) writes: >I need a mechanism to restrict root logins to the console. > >If I change the user characteristics "valid TTYs" to the console >you can only "su" to "root" from the console. (this is not practical) > >I have submitted a system change request to IBM and they refused. > >Can anyone give me advice on a work around? The information you are looking for is documented with the system security features. What you want is an authentication method that will allow you to specify that the method only runs on the console (the easy way) or that there is a file containing user/port mappings. First the easy way ... --- iscon.c --- main () { char *cp; if ((cp = ttyname (0)) && strcmp (cp, "/dev/console") == 0) exit (0); else exit (1); } --- Compile that command and store it in /etc as /etc/iscon. It should be executable by everyone - mode 555. Now, in the file /etc/security/user, make the "auth1" attribute in the root stanza have the value "auth1 = CONSOLE;SYSTEM". Then edit the file /etc/security/login.cfg and added the stanza CONSOLE: program = /etc/iscon Now root is able to login only on the console. DISCLAIMER: I've not tried this, but I did work on the code that implements the security features and this =should= work. I don't make any guarantees about this working, and none should be inferred. -- John F. Haugh II | I've Been Moved | MaBellNet: (512) 838-4340 SneakerNet: 809/1D064 | AGAIN ! | VNET: LCCB386 at AUSVMQ BangNet: ..!cs.utexas.edu!ibmchs!auschs!snowball.austin.ibm.com!jfh (e-i-e-i-o)
jfh@greenber.austin.ibm.com (John F Haugh II) (06/14/91)
In article <8439@awdprime.UUCP> shaggy@kleikamp.austin.ibm.com (David J. Kleikamp) writes: >In article <1991Jun12.180648.27815@bnlux1.bnl.gov> como@max.bnl.gov (Andrew T. Como) writes: >What good is it to restrict root logins to the console if you do allow other >users to su to root from other TTY's? It prevents remote attacks against the system. Someone can't dialup your system and pound away on the modem hoping to get the root password. Even if they do get the root password, they still can't login. >Anyway, one way of doing this would be to write your own authentication >method. I've never done this myself, but you define the authentication >methods in the /etc/security/login.cfg file. See an earlier posting f mine where I describe exactly how to do this. -- John F. Haugh II | I've Been Moved | MaBellNet: (512) 838-4340 SneakerNet: 809/1D064 | AGAIN ! | VNET: LCCB386 at AUSVMQ BangNet: ..!cs.utexas.edu!ibmchs!auschs!snowball.austin.ibm.com!jfh (e-i-e-i-o)
brian@is.UUCP (Brian Zimbelman) (06/14/91)
In article (David J. Kleikamp) writes: > In article (Andrew T. Como) writes: > > > >I need a mechanism to restrict root logins to the console. > > > >If I change the user characteristics "valid TTYs" to the console > >you can only "su" to "root" from the console. (this is not practical) > > > > Andrew Como I have used "valid TTYs" a number of times with no difficulties. Actually, I did have one problem, AIX requires a full pathname for this field. valid TTYs = tty0 FAILS valid TTYs = /dev/tty0 WORKS I do not remember if I tried '/dev/console' or not, but '/dev/tty?' works fine. This will restrict LOGINS of the user to this device, however it will not restrict others from switching user to this user while logged in on other devices. > Okay, I'll ask. > > What good is it to restrict root logins to the console if you do allow other > users to su to root from other TTY's? > > Anyway, one way of doing this would be to write your own authentication > method. I've never done this myself, but you define the authentication > methods in the /etc/security/login.cfg file. > -- > --------------------------------------------------------------------------- > David J. "Shaggy" Kleikamp dave@kleikamp.austin.ibm.com > The content of this posting is independent of official IBM position. > External: uunet!cs.utexas.edu!ibmaus!auschs!kleikamp.austin.ibm.com!dave Good Luck, Brian Zimbelman President Innovative Solutions Disclaimer: Works for me!!! ----------------------------------------------------------------------------- Innovative Solutions (505) 883-4252 3547 Colorado NE is!brian@bbx.basis.com Albuquerque, NM 87110 bbx.basis.com!is!brian
sef@kithrup.COM (Sean Eric Fagan) (06/14/91)
In article <8439@awdprime.UUCP> shaggy@kleikamp.austin.ibm.com (David J. Kleikamp) writes: >What good is it to restrict root logins to the console if you do allow other >users to su to root from other TTY's? Anyone can log in, and you won't know whom it was. On the other hand, su keeps a log (or can; I believe it does under AIX). True, someone can edit the log file, but that's less likely. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
jfh@rpp386.cactus.org (John F Haugh II) (06/15/91)
In article <9106132050.AA27815@ucbvax.Berkeley.EDU> vrbass@atlvmic1.vnet.ibm.com writes: >>>>I need a mechanism to restrict root logins to the console. > > chuser telnet=false rlogin=false > >should do the trick if your other terminals are on the network. >If you have both network and serial terminals, you're going to >have to go to the secondary authentication methods mentioned >earlier. Secondary authentication methods will not work. The "auth2" method does not cause the authentication to fail if the method exits with a failure code. In order to do what he is trying to accomplish you have to have the method be one of the primary ("auth1") methods. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "UNIX signals are not interrupts. Worse, SIGCHLD/SIGCLD is not even a UNIX signal, it's an abomination." -- Doug Gwyn
jfh@rpp386.cactus.org (John F Haugh II) (06/15/91)
In article <1991Jun14.045407.23003@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >In article <8439@awdprime.UUCP> shaggy@kleikamp.austin.ibm.com (David J. Kleikamp) writes: >>What good is it to restrict root logins to the console if you do allow other >>users to su to root from other TTY's? > >Anyone can log in, and you won't know whom it was. On the other hand, su >keeps a log (or can; I believe it does under AIX). True, someone can edit >the log file, but that's less likely. As I recall (and I can ask Tom when I see him tomorrow), "su" does not support the /usr/adm/sulog like other "su"'s do. It performs auditing, which is implmented in such a way that it can be made untamperable. To find out who is su'ing to root, turn on auditing for the appropriate audit event for all of your users. su will then cut an audit record everytime someone uses it. Each record contains enough information to figure out who done it. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "UNIX signals are not interrupts. Worse, SIGCHLD/SIGCLD is not even a UNIX signal, it's an abomination." -- Doug Gwyn
julie@levell.austin.ibm.com (Julie A. Levell) (06/18/91)
>>In article <8439@awdprime.UUCP> shaggy@kleikamp.austin.ibm.com (David J. Kleikamp) writes: > >As I recall (and I can ask Tom when I see him tomorrow), "su" does not >support the /usr/adm/sulog like other "su"'s do. It performs auditing, >which is implmented in such a way that it can be made untamperable. > Well, thanks to apar ix16167, su will now report to syslog. Just add auth.debug /tmp/yourfile /* OR /dev/console, or whatever */ to /etc/syslog.conf file, and wa-la su's will be recorded. The fix should be in 2007, otherwise you can request it from defect support. >John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh -- *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Julie A. Levell IBM Austin, Texas Internet: julie@aixwiz.austin.ibm.com IBMNET: JULIEL at AUSVMQ 4C-29/994 SpeakNet: 823-5178 (Tie 793-5178) "Let's use the ODM Interface" Commander William Riker STTNG "The Nth Degree"