elr@kb2ear.ampr.org (Ed Ravin) (04/02/91)
so the same ports used for incoming calls can be used for uucp and other dialouts. I tapped the orchestra conductor on the back (that is, ran SMIT) and set up the ports with logins enabled with "delay" (corresponds to some getty option for sharing ports). Programs like uucp and cu with setuid's set can now access the ports without trouble, but my ordinary user programs (like Kermit) cannot. A look at the protections on the tty devices shows that they're set to rw-rw--w-, or owner and group read/write, but outsiders write only. If I chmod the tty device to 666 then Kermit works fine, but after a user signs on and off again, (and getty is restarted), the protection goes back to -w- (write only) for outsiders. I tried to RTFM, and according to the manual, getty sets the protections on the tty port based on information stored in "odm". I looked up "odm" wherever I could and found instructions on how to build object databases, but none of it seemed relevant to changing existing configurations. It may be that I don't have the right manual -- IBM only sent us four or five binders, the rest is all supposed to be on a CD-ROM that won't arrive until Real Soon Now. Anybody out there know how getty gets into this "odm" stuff and how a Unix proficient manager can get their hands on changing it?
wjones@nwnexus.WA.COM (Warren Jones) (04/03/91)
elr@kb2ear.ampr.org (Ed Ravin) writes: >A look at the protections on the tty devices shows that they're set to >rw-rw--w-, or owner and group read/write, but outsiders write only. If >I chmod the tty device to 666 then Kermit works fine, but after a user >signs on and off again, (and getty is restarted), the protection goes >back to -w- (write only) for outsiders. We've run into the same problem here, and reported it to IBM software defect support. (Mention problem #5X776 if you talk to them.) Our temporary fix has been to write a one line suid root program: system( "chmod 666 /dev/tty1" ), and a shell wrapper around kermit that calls this program. Yes, I know its ugly.
jfh@greenber.austin.ibm.com (John F Haugh II) (04/05/91)
In article <6@kb2ear.ampr.org> elr@kb2ear.ampr.org (Ed Ravin) writes: >A look at the protections on the tty devices shows that they're set to >rw-rw--w-, or owner and group read/write, but outsiders write only. If >I chmod the tty device to 666 then Kermit works fine, but after a user >signs on and off again, (and getty is restarted), the protection goes >back to -w- (write only) for outsiders. You need to run Kermit set-[UG]ID so it can take control of the port you are trying to access. This is how most of the other commands which work with ttys operate. Also, you need to modify Kermit so it uses the tty-locking routines which the system comes with. These are used by getty (tsm) and UUCP - if you don't do this you will find Kermit getting in the way of other applications. -- 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)
rhcoe@buscfg.austin.ibm.com (Rich Coe) (04/06/91)
In article <6411@awdprime.UUCP> jfh@greenber.austin.ibm.com (John F Haugh II) writes: >In article <6@kb2ear.ampr.org> elr@kb2ear.ampr.org (Ed Ravin) writes: >>A look at the protections on the tty devices shows that they're set to >>rw-rw--w-, or owner and group read/write, but outsiders write only. If >>I chmod the tty device to 666 then Kermit works fine, but after a user >>signs on and off again, (and getty is restarted), the protection goes >>back to -w- (write only) for outsiders. > >You need to run Kermit set-[UG]ID so it can take control of the port you >are trying to access. This is how most of the other commands which >work with ttys operate. >-- >John F. Haugh II kermit doesn't need to be set-uid. tsm/getty/login has been modified to allow dialouts on shared/delayed ports for everyone, ie. 666. Ask the support people for ix11286. Don't take "its in 3002" for an answer. Regards, Rich Coe ----- UUCP: ...!uunet!ibmsupt!rhcoe IBM AIX BOS Field Quality ARPA: rhcoe%ibmsupt@uunet.uu.net Austin, TX rhcoe@aixwiz.austin.ibm.com internal: rhcoe@buscfg.austin.ibm.com
geoff@edm.uucp (Geoff Coleman) (04/08/91)
In article <6411@awdprime.UUCP> jfh@greenber.austin.ibm.com (John F Haugh II) writes: >In article <6@kb2ear.ampr.org> elr@kb2ear.ampr.org (Ed Ravin) writes: >>I chmod the tty device to 666 then Kermit works fine, but after a user >>signs on and off again, (and getty is restarted), the protection goes >>back to -w- (write only) for outsiders. > >You need to run Kermit set-[UG]ID so it can take control of the port you >are trying to access. This is how most of the other commands which >work with ttys operate. Also, you need to modify Kermit so it uses the >tty-locking routines which the system comes with. These are used by >getty (tsm) and UUCP - if you don't do this you will find Kermit getting >in the way of other applications. There is an APAR in for this problem and I believe a fix is also now available which will allow permissions for ports to stay at 0666. For the last time SUID is not a fix!!!!!!!!!!!!!!!! Geoff Coleman Unexsys Systems >-- >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) (04/10/91)
In article <1991Apr08.154742.19459@edm.uucp> geoff@edm.uucp (Geoff Coleman) writes: > There is an APAR in for this problem and I believe a fix is also >now available which will allow permissions for ports to stay at 0666. > > For the last time SUID is not a fix!!!!!!!!!!!!!!!! The problem with leaving the ports 0666 is that any process can then park itself on the port and pretend to be the login process. Simple trojan horses can easily take advantage of this "feature". The advantage of restricting access to the port to root processes is that you can control what is "root" better than you can control what isn't. [ Which is to say, that allowing just anyone to use the port means they can do just anything with it. ] Leaving a trojan horse behind you when you log out isn't a problem since there is some degree of accountability [ You can see who last used the port without having to resort to all manner of object auditing. ], and really can't be stopped anyhow. Third party trojan horses =can= be stopped, and therefore =should= be prevented. Accessibility and security are opposites. Serial ports should be secure since they are the mechanism used to gain access to the system. That means that changes which make them more accessible generally will make the system less "secure". -- 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)
geoff@edm.uucp (Geoff Coleman) (04/12/91)
In article <6533@awdprime.UUCP> jfh@greenber.austin.ibm.com (John F Haugh II) writes: >In article <1991Apr08.154742.19459@edm.uucp> geoff@edm.uucp (Geoff Coleman) writes: >> There is an APAR in for this problem and I believe a fix is also >>now available which will allow permissions for ports to stay at 0666. >> >> For the last time SUID is not a fix!!!!!!!!!!!!!!!! > > >Accessibility and security are opposites. Serial ports should be secure >since they are the mechanism used to gain access to the system. That >means that changes which make them more accessible generally will make >the system less "secure". >-- I guess I should have made myself clearer by saying SUID to root is not a fix. To tell somenone to set kermit to suid is asking for trouble. Kermit can and wille scape to shells etc. What I've been asking for is to allow someone other than root to own the ports but not just anybody. If I could have uucp own my bi-directional ports with permission 0660 and owned by uucp I would be happy. I can do this on SYS V r3 why not in AIX. In conclusion neither suid to root nor 0666 permissions on a port is an acceptable fix. Geoff Coleman Unexsys Systems >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) (04/13/91)
In article <1991Apr11.222123.36169@edm.uucp> geoff@edm.uucp (Geoff Coleman) writes: > What I've been asking for is to allow someone other than root to >own the ports but not just anybody. If I could have uucp own my >bi-directional ports with permission 0660 and owned by uucp I would be >happy. I can do this on SYS V r3 why not in AIX. You are correct that someone other than root should =ideally= own the ports, but the problem is that a random user ID cannot give a file back to its owner unless that process has root authority. The reason is that the chown() system call is restricted to root privileges only. Were that not the case (and it isn't in SVR3), it would be trivial to set a file to and from uucp ownership with a process that were merely setuid to uucp. However, AIX does have POSIX_CHOWN_RESTRICTED set, as required by FIPS I believe, so the more SVR3-like technique of flipping between a non-root setuid UID and the real UID doesn't work due to the failing chown() call. -- 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)
geoff@edm.uucp (Geoff Coleman) (04/19/91)
In article <6635@awdprime.UUCP> jfh@greenber.austin.ibm.com (John F Haugh II) writes: >In article <1991Apr11.222123.36169@edm.uucp> geoff@edm.uucp (Geoff Coleman) writes: >> What I've been asking for is to allow someone other than root to >>own the ports but not just anybody. If I could have uucp own my >>bi-directional ports with permission 0660 and owned by uucp I would be >>happy. I can do this on SYS V r3 why not in AIX. > >You are correct that someone other than root should =ideally= own the >ports, but the problem is that a random user ID cannot give a file back >to its owner unless that process has root authority. The reason is that >the chown() system call is restricted to root privileges only. Were >that not the case (and it isn't in SVR3), it would be trivial to set a >file to and from uucp ownership with a process that were merely setuid >to uucp. However, AIX does have POSIX_CHOWN_RESTRICTED set, as required >by FIPS I believe, so the more SVR3-like technique of flipping between >a non-root setuid UID and the real UID doesn't work due to the failing >chown() call. >-- I'll agree with the above but why not add an entry into the tty database called owner. Then in the case where you want someone else other than root to own a port you could change this attribute. If this were done then tsm/login/getty when it respawns on a port could change the ownership to that attribute. This would seem to then allow the uucp programs to not have to be owned by root. Since tsm is already so big a few more lines of code shouldn't hurt it :-) Geoff Coleman Unexsys Systems tsm = terminally sordid mess (anyone with a better explanation?) >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)
eravin@panix.uucp (Ed Ravin) (04/19/91)
In article <1991Apr18.184800.26770@edm.uucp> geoff@edm.uucp (Geoff Coleman) writes: > why not add an entry into the tty >database called owner. Then in the case where you want someone else >other than root to own a port you could change this attribute. > If this were done then tsm/login/getty when it respawns >on a port could change the ownership to that attribute. This would seem to >then allow the uucp programs to not have to be owned by root. This is exactly what appears to be documented in the manual :: try "man getty" or look up the command page with Info Avenger. It will say that getty sets the protections of a tty port based on something it finds in ODM. Alas, this must be a well-intentioned lie, because there doesn't seem to be anything in /etc/objrepos that talks about tty port protections. Or if there is, I couldn't find it and noone from IBM has stepped forth to reveal its whereabouts. -- Ed Ravin | This random number tells the computer that you are cmcl2!panix!eravin | a member in good standing. It is not related to your philabs!trintex!elr | membership number. --- Sierra Club
chip@tct.com (Chip Salzenberg) (04/21/91)
According to geoff@edm.uucp (Geoff Coleman): > If this were done then tsm/login/getty when it respawns on a port could >change the ownership to that attribute. This would seem to then allow the >uucp programs to not have to be owned by root. I have a simpler solution: make uucico getuid-uucp and setgid-system. Since the ports are mode 664 it works fine. -- Brand X Industries Custodial, Refurbishing and Containment Service: When You Never, Ever Want To See It Again [tm] Chip Salzenberg <chip@tct.com>, <uunet!pdn!tct!chip>
jfh@greenber.austin.ibm.com (John F Haugh II) (04/23/91)
In article <28108620.1309@tct.com> chip@tct.com (Chip Salzenberg) writes: >I have a simpler solution: make uucico getuid-uucp and setgid-system. >Since the ports are mode 664 it works fine. This isn't a real solution either. It is perfectly acceptable for you to disable a port after some random user has logged out and left the modes something other than 664 or with any particular owner or group. -- 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)