Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!romp!auschs!d75!awdprime!greenber.austin.ibm.com!jfh
From: jfh@greenber.austin.ibm.com (John F Haugh II)
Newsgroups: comp.unix.aix
Subject: Re: Where does getty get its information?
Message-ID: <6533@awdprime.UUCP>
Date: 9 Apr 91 21:00:48 GMT
References: <6@kb2ear.ampr.org> <6411@awdprime.UUCP> <1991Apr08.154742.19459@edm.uucp>
Sender: news@awdprime.UUCP
Organization: Best Care South of the Red River, LCC, Austin, Republic of Texas
Lines: 26

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)