[2222] in Release_Engineering
server inetd.conf
daemon@ATHENA.MIT.EDU (David Krikorian)
Fri Mar 23 17:07:26 1990
Date: Fri, 23 Mar 90 17:06:46 -0500
From: David Krikorian <dkk@ATHENA.MIT.EDU>
To: rel-eng@ATHENA.MIT.EDU
Cc: pete@ATHENA.MIT.EDU, salemme@ATHENA.MIT.EDU, dkk@ATHENA.MIT.EDU
Reply-To: dkk@ATHENA.MIT.EDU
Here is the /etc/inetd.conf I am installing on the Athena servers (as
they are updated to 6.4), followed by an old explanation for the
changes. Please include this version of the file in the release (ie:
in /srvd/servers).
------------
eklogin stream tcp nowait switched root /usr/etc/klogind eklogind
finger stream tcp nowait unswitched nobody /etc/fingerd fingerd
write stream tcp nowait unswitched root /etc/writed writed
kshell stream tcp nowait switched root /usr/etc/kshd kshd
klogin stream tcp nowait switched root /usr/etc/klogind klogind
time stream tcp nowait unswitched root internal internal
time dgram udp nowait unswitched root internal internal
daytime stream tcp nowait unswitched root internal internal
daytime dgram udp nowait unswitched root internal internal
rkinit stream tcp nowait switched root /etc/athena/rkinitd rkinit
------------
From David Krikorian <dkk@ATHENA.MIT.EDU> Thu Mar 22 21:49:18 1990
Date: Thu, 28 Dec 89 13:25:09 -0500
From: David Krikorian <dkk@ATHENA.MIT.EDU>
To: jis@ATHENA.MIT.EDU
Cc: ops@ATHENA.MIT.EDU, jon@ATHENA.MIT.EDU
Subject: Server security proposal
Reply-To: dkk@ATHENA.MIT.EDU
Home: 47 Lake St., Arlington, MA 02174, (617) 646-9289
Office: MIT Bldg. E40-358A, (617) 253-8651, 258-8736 (fax)
What follows is my proposal for the new server /etc/inetd.conf. After
that is the summary of email conversation (mostly a monologue)
explaining the changes. The last paragraph contains my final thoughts
on the matter, and did not appear in any previous email. There is
also a note beginning with "Correction:" in the text of an old mail
message.
------------
Service: Run as: Command to run:
eklogin root /usr/etc/klogind
finger nobody /etc/fingerd
write root /etc/writed
kshell root /usr/etc/kshd
klogin root /usr/etc/klogind
time root internal (both tcp and udp)
daytime root internal (both tcp and udp)
rkinit root /etc/athena/rkinitd
Removed:
### ftp root /etc/ftpd
### telnet root /etc/telnetd
### shell root /etc/rshd
### login root /etc/rlogind
### erlogin root /usr/etc/erlogind
### exec root /etc/rexecd
### tftp root /etc/tftpd
### comsat root /etc/comsat
### talk root /etc/talkd
### ntalk root /etc/ntalkd
------------
>From David Krikorian <dkk@ATHENA.MIT.EDU> Thu Dec 28 12:49:49 1989
Date: Wed, 22 Nov 89 00:03:07 -0500
From: David Krikorian <dkk@ATHENA.MIT.EDU>
To: ops@ATHENA.MIT.EDU
Cc: jon@ATHENA.MIT.EDU
Subject: Server security proposal
Reply-To: dkk@ATHENA.MIT.EDU
Home: 47 Lake St., Arlington, MA 02174, (617) 646-9289
Office: MIT Bldg. E40-358A, (617) 253-8651, 258-8736 (fax)
This is a DRAFT for a proposed change in Athena fileserver
network-service configuration. That translates to "my proposal for
changing /etc/inetd.conf, and a few other things." Below is my
proposed inetd.conf, simplified for readablility:
--------
Service: Run as: Command to run:
# ftp root /etc/ftpd
# telnet root /etc/telnetd
shell root /etc/rshd
# login root /etc/rlogind
# exec root /etc/rexecd
finger nobody /etc/fingerd
write root /etc/writed
tftp root /etc/tftpd
# comsat root /etc/comsat
talk root /etc/talkd
ntalk root /etc/ntalkd
kshell root /usr/etc/kshd
klogin root /usr/etc/klogind
time root internal
daytime root internal
globalmessage nobody /etc/athena/messaged
--------
The changes I propose:
Disable ftp, telnet, rlogin, rexec and comsat. The first four of
these use local passwords, and local passwords typed across the net
are a security hole we can do without. (I'm only proposing that we
install an inetd.conf of this type when we have established Kerberos
access, ie: an /etc/srvtab file.) The fifth program of this set,
comsat, seems to be utterly useless on a server. If we don't need it,
we may as well eliminate one more possibility of buggy software
opening a security hole.
I recommend that we continue to allow shell (rsh.ucb) connections,
since it will only function when there is a /.rhosts file on the
server. The brief presence of a /.rhosts file is little risk (if it
doesn't hang around) compared to the inconvenience of not having this
capability. Example: dumping one host to another from across the net.
I changed fingerd to run as "nobody" rather than root. It doesn't
need privileges to do its work, so it shouldn't have any.
I want write, kshell, klogin and globalmessage available on the
servers. I welcome any comments or disagreement.
I don't know whether it's worth having tftp, talk and ntalk. I'm also
not sure which of the time/daytime services we really use. Comments
welcome.
For the other changes:
I propose that the contents of /.klogin be rewiewed. It's growing
longer all the time... I argue that only users' root instances should
be in /.klogin (as is now the case), and that we have some less
dangerous login (daemon, operator, backup?) with null instances for
other users in its ~/.klogin. [Not operator. It has uid 0. -dkk]
I realize that last proposal is likely to meet some resistance, but
the only application of it that I forsee is the following:
On printservers, we have /.klogin containing the usual list of root
instance Kerberos principals, a few knowledgable people who don't have
root everywhere (yet) such as bwmelans.root@athena, and maybe some
accepted SysDev programmers (on the grounds that a print server is
less of a security problem). In ~operator/.klogin (or whatever) we
have larugsi@athena, moe@athena, jjdoher@athena, and other such people
for whom it is just too much trouble to deal with a second password, a
second ticket file, and so on - just to be able to maintain a print
server. [No reason not to put larugsi@athena, etc in /.klogin. -dkk]
--------
>From jon@MIT.EDU Thu Dec 28 12:50:02 1989
From: jon@MIT.EDU (Jon A. Rochlis)
To: dkk@ATHENA.MIT.EDU
Cc: ops@MIT.EDU
Subject: Re: Server security proposal
In-Reply-To: Your message of Wed, 22 Nov 89 00:03:07 -0500.
<8911220503.AA06858@PAL14.MIT.EDU>
Date: Thu, 23 Nov 89 12:52:55 EST
Disable ftp, telnet, rlogin, rexec and comsat.
I agree totally.
I recommend that we continue to allow shell (rsh.ucb) connections,
since it will only function when there is a /.rhosts file on the
server. The brief presence of a /.rhosts file is little risk (if it
doesn't hang around) compared to the inconvenience of not having this
capability. Example: dumping one host to another from across the net.
I would rather see this go away. There is a risk of leaving around a
/.rhosts. If people still type root instance passwords over the
network (via ksu) will they remember and remove temporary .rhosts ...
Also is getting kerberos tickets and doing a kerberos rsh that
difficult? If you're doing something with a server that doesn't have
a srvtab or whatever, you could put rsh.ucb back.
I changed fingerd to run as "nobody" rather than root. It doesn't
need privileges to do its work, so it shouldn't have any.
This is great. No need at all to run privileged. Morris would have
gotten in as root if that were the case more often.
I want write, kshell, klogin and globalmessage available on the
servers. I welcome any comments or disagreement.
I certainly agree with kshell and klogin. write is probably useful
enough (if somebody is doing work on a server in some random machine
room you can get hold of them), so it makes sense. I don't know about
the globalmessage daemon. I thought there was just one server there.
If so you don't need to enable that on all the servers.
I don't know whether it's worth having tftp, talk and ntalk. I'm also
not sure which of the time/daytime services we really use. Comments
welcome.
tftp can be dangerous. get rid of it. the only thing we use it for
is boot servers (for the gateways and some workstation installs), but
normal servers don't need it.
re: talk and ntalk ... if you feel the communications value of these
outweighs having two more programs around, then leave them. If you
can get by with write or the telephone, punt them.
leave time. daytime can stay but isn't important. (time returns the
time in binary, daytime returns it in ascii, the gettime command needs
time). Having these is useful if one suspects clock skew is causing
kerberos problems with a server.
These are long overdue steps in the right direction.
-- Jon
--------
>From dkk@ATHENA.MIT.EDU Thu Dec 28 12:50:11 1989
From: dkk@ATHENA.MIT.EDU
Date: Thu, 23 Nov 89 21:06:09 -0500
To: jon@MIT.EDU
Cc: ops@MIT.EDU
In-Reply-To: Jon A. Rochlis's message of Thu, 23 Nov 89 12:52:55 EST,
<8911231752.AA07350@DELWIN.MIT.EDU>
Subject: Re: Server security proposal
> I recommend that we continue to allow shell (rsh.ucb) connections,
> since it will only function when there is a /.rhosts file on the
> server. The brief presence of a /.rhosts file is little risk (if it
> doesn't hang around) compared to the inconvenience of not having this
> capability. Example: dumping one host to another from across the net.
>
> I would rather see this go away. There is a risk of leaving around a
> /.rhosts. If people still type root instance passwords over the
> network (via ksu) will they remember and remove temporary .rhosts ...
A daily sweep can be made to check for /.rhosts files. Granted, we
don't do that now, but we could start. A /.rhosts file only has to be
found once to be eliminated, but we can't prevent or undo the typing
of root instance passwords across the net.
> Also is getting kerberos tickets and doing a kerberos rsh that
> difficult? If you're doing something with a server that doesn't have
> a srvtab or whatever, you could put rsh.ucb back.
Getting Kerberos tickets on a remote server is not difficult if you're
willing to type your (root instance) password across the net. The
problem lies in that we don't have rkinit or erlogin on the servers.
I hear we will be getting encrypted rlogin in the release soon
(6-90?), but that's a bit of a wait.
[Correction: erlogin is rlogin with environment (DISPLAY variable)
passing. The correct name is eklogin, which is Kerberos encrypted
and Kerberos authenticated login. -dkk]
> I want write, kshell, klogin and globalmessage available on the
> servers. I welcome any comments or disagreement.
>
> I certainly agree with kshell and klogin. write is probably useful
> enough (if somebody is doing work on a server in some random machine
> room you can get hold of them), so it makes sense. I don't know about
> the globalmessage daemon. I thought there was just one server there.
> If so you don't need to enable that on all the servers.
I guess it is a potential security hole with little benefit. I
included it because I had just finished setting up globalmessage
service on two more servers (Themis and Aphrodite) so we can relocate
it when the previous globalmessage server is being shutdown. For
example, there's a planned shutdown of Talos on Monday morning. If
globalmessage doesn't work Monday (on Talos), many people won't know
why their login is broken...
> I don't know whether it's worth having tftp, talk and ntalk. I'm also
> not sure which of the time/daytime services we really use. Comments
> welcome.
>
> tftp can be dangerous. get rid of it. the only thing we use it for
> is boot servers (for the gateways and some workstation installs), but
> normal servers don't need it.
OK. Unless someone else can come up with a better argument, consider
it removed.
> re: talk and ntalk ... if you feel the communications value of these
> outweighs having two more programs around, then leave them. If you
> can get by with write or the telephone, punt them.
I don't use the talk programs, in general. Comments from ops?
(What is ntalk? The newer, current version?)
> leave time. daytime can stay but isn't important. (time returns the
> time in binary, daytime returns it in ascii ...
There are tcp and udp versions of each. It seems that four different
time protocols is a bit much. If only one is used here (by gettime),
are the other ones worth the security risk? Or is there, in theory,
no associated risk? [They are all done internal to inetd, so four
lines doesn't mean four ways to break in... -dkk]
--------
Final notes from dkk: [from 28 Dec 89]
6.4 has both encrypted rlogin (rlogin <hostname> -x) and rkinit, so
rsh.ucb is no longer necessary. No one defended talk or ntalk, so I
took those out, too.
