[3231] in SIPB-AFS-requests
Re: migrating rosebud to a Sun
daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Mon Jan 18 05:01:46 1999
Date: Mon, 18 Jan 1999 05:01:38 -0500
From: mhpower@MIT.EDU
To: mwhitson@MIT.EDU
Cc: zacheiss@MIT.EDU, sipb-afsreq@MIT.EDU
In-Reply-To: "[3230] in SIPB-AFS-requests"
>I believe the effective expense increases significantly when we take
>into account the delays to this upgrade involved in acquiring the disk
>and setting it up.
Do we now know that /os and /srvd won't fit? In Garry's mail, it
didn't seem that we knew a second system disk would be necessary:
> ... One
>problem here is that the system disk in the SS5 might be big enough to
>hold one copy of /os and /srvd local (although it would be tight) ...
Presumably a second system disk could be added at a later time,
such as during the outage window for the SunOS 5.7 upgrade (if there
ever is a SunOS 5.7 upgrade on the machine).
>/mit/ops/doc/admin/afs/solaris.afs.install
It references a file /mit/bootkit/solarisinstall/25/README that, as
far as I can tell, doesn't exist. (I thought I'd pass that along
following your suggestion that "having the feedback such that we can
make them more clear would be valuable to ASO".)
Also, it wasn't clear to me whether the install servers (it appears
from /mit/bootkit/solarisinstall/README that either solar2 or sunburn
could be used) would be used to install exactly the software that gets
loaded onto an Athena workstation for 8.2.15, or whether they would be
used to install some other configuration of Solaris 2.6. For the
rest of the message, I'll assume newly installed servers start out
with the standard 8.2.15 before any mkserv occurs.
>Also, the "afs", "ops", and "remote" mkserv services are used.
I don't think it's appropriate for all of the effects of "mkserv ops"
to be left in place on the machine. One issue is that I don't believe
any sipb machines should be running an update_server process. We don't
have any apparent use for the functionality it supplies, and thus it's
an unnecessary network daemon process. The sipb afs servers aren't
maintained by ASO and therefore we shouldn't provide for whatever
indirect access possibilities may exist via access to the moira
server. There was a major security hole within the last couple of
years related to lack of authorization checking in the moira update
code, and since problems of that type could conceivably arise again, I
think we are better off without update_server running.
Also, whenever mkserv ops is run it replaces syslog.conf with a
standard version that I think is the one in place on ASO servers --
this would interfere with sipb's syslog.conf customizations. (There's
also a similar effect on inetd.conf, so if we happen to run inetd that
would be an issue too.)
>In the meantime, however, I believe that there already exists a system
>that works, and while developing new ways of doing things is fine,
>there's no need to delay this upgrade fixing something that isn't
>broken. The other two sipb-cell afs servers are set up in the ASO
>fashion already; it's not like there's a lack of precedent for using
>this procedure.
Although I think it's true that an installation procedure obtained
from somewhere under /mit/ops was run for reynelda and ronald-ann, we
made dozens of changes to the system configuration right after the
installation. The specific changes aren't especially relevant (I think
[2269], [2586], and [2591] describe them) since they mainly apply to
SunOS 4 issues, but if you think precedent is of interest, there
definitely is precedent for having a sipb-supplied portion of the
installation procedure.
I think this is the major issue. Although I have a preference on the
system-packs decision, I don't think the question of whether programs
that we'll probably never run on an afs server happen to be located on
local disk or in afs is especially critical. However, I do think that
the configuration used on ASO servers has some difficulties with
respect to maintainability and potential security risks, and should
not be used as-is on sipb afs servers. In this sense, I disagree with
your statement of "isn't broken".
It may well be the case that the configuration used on ASO servers is
adequate for ASO's needs. One of the differences from sipb is that, if
a problem with an ASO server occurs at any arbitrary time of day and
year, ASO has the ability to get a qualified person to look at the
problem within (I'd expect) often less than an hour. This is not the
case for sipb. Because of that, I think sipb needs to be more careful
with its server configurations and needs to anticipate some potential
problems, in case the potential problems happen to become operational
problems at an unexpected and inconvenient time.
I'll try to give a complete list of the changes that I think are
worthwhile, although I'll likely bring up things that don't need to be
changed, because there are some aspects of the ASO afs-server
configuration that I unfortunately misunderstand even after reading
the solaris.afs.install and ss.afs files that you pointed me to.
I already mentioned the update_server issue. I think ASO afs servers
run rpcbind (or portmap on SunOS 4). This isn't needed for afs service
to function. The sipb afs servers don't run portmap. There are some
potential (not yet known-exploitable) security issues related to rpc,
such as mentioned in http://www.mit.edu:8008/menelaus/bt/6797, and I
believe it's prudent to not run the unnecessary rpcbind daemon.
Similarly, I think snmpd is unnecessary and shouldn't be run.
Some sipb afs maintainers receive syslogs via zephyr from the sipb afs
servers. (I think that ops has some alternate notification solution
involving a private zephyr class.) I think sipb afs servers running
SunOS 5 should also use a version of syslogd that supports zephyr.
(The sipb afs servers run a script called afs2sl.pl that generates
extra syslogs, but that can be set up later and doesn't especially
need to be part of the installation process.)
Another syslogd issue is that it should not process data received via
udp port 514, because of potential security and denial-of-service
issues. The current sipb afs servers are set up such that incoming
syslog udp data is discarded.
With a zephyr syslogd, zhm is needed (I think zhm is present on ASO
afs servers, but I'm not sure). I believe it's best to run zhm as a
non-root process, since zhm doesn't need root access for any
significant reason.
This is somewhat less critical, but I also think sipb servers should
move away from relying on either the Sun or Athena inetd due to
denial-of-service issues. I also feel this way about named -- I don't
believe afs servers generate enough DNS queries to warrant their own
named. Instead, I'd probably favor putting names of other sipb servers
(or other appropriate machines that do run named) into resolv.conf.
An important, although perhaps more controversial, issue is that I
don't think sipb should deploy any new servers that allow root shell
access on the basis of single-des session keys. I'm not completely
sure of the state of triple-des support in Kerberos, but I think what
I'm suggesting is that root shells be possible only via sshd (without
Kerberos), and that klogind and kshd (both V4 and V5) should be shut
off. On a similar note, I'd favor having bosserver recompiled such
that BOZO_Exec returns a failure code even if a client is a valid
privileged user.
For sshd_config, I would want to allow only RSA authentication and
password authentication (of course using ss.afs in such a way as to
get the sipb afs root password into /etc/shadow).
For maintainability, at least with SunOS 5.5.1 I believe it was best
to have root's shell in /sbin (and not rely on libraries in /usr/lib)
for some aspect of single-user-mode use (I think it was "boot -b".)
Finally, for completeness, I think the changes such as shutting off
unnecessary daemons should be made before the machine boots with those
daemons running. A procedure for doing this was documented by
ghudson in steps 2 and 3 of /afs/sipb/services/solaris/README.
I think that's all I'd find necessary for SunOS 5.6 sipb servers that
allow only root to login. (I don't think these steps are adequate for
servers that allow some user logins, and in most cases sipb servers
should allow user logins especially since we sometimes want to let new
prospectives look at the setup of our servers before they're ready to
have root access. But probably that isn't useful for an afs server.)
Matt
