[3232] in SIPB-AFS-requests
Re: migrating rosebud to a Sun
daemon@ATHENA.MIT.EDU (Sam Hartman)
Mon Jan 18 05:37:47 1999
To: mhpower@MIT.EDU
Cc: mwhitson@MIT.EDU, zacheiss@MIT.EDU, sipb-afsreq@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 18 Jan 1999 05:37:39 -0500
In-Reply-To: mhpower@MIT.EDU's message of "Mon, 18 Jan 1999 05:01:38 -0500"
>>>>> "mhpower" == mhpower <mhpower@MIT.EDU> writes:
I think we are approaching consensus on this issue. Having watched
the discussion, I believe that mhpower has brought up some good
points, but I also believe he has brought up some points for which
there is not a consensus on this list. That zacheiss, kcr and I can
move forward on this issue, I'm going to formally ask this group for
consensus on some things, noting that in some cases, mhpower's
disagreement may not represent a lack of consensus. I think this
discussion and other discussions on sipb-machine-room have given
sufficient time to the issues that we understand what they issues are
and reasons for agreeing/disagreeing.
mhpower> Do we now know that /os and /srvd won't fit? In Garry's
mhpower> mail, it didn't seem that we knew a second system disk
mhpower> 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) ...
mhpower> Presumably a second system disk could be added at a later
mhpower> time, such as during the outage window for the SunOS 5.7
mhpower> upgrade (if there ever is a SunOS 5.7 upgrade on the
mhpower> machine).
Does anyone besides Matt believe that the effort involved in setting
1up this configuration and maintaining it is worthwhile? Personally,
while I wouldn't object to local srvd and os if they fit, I'm not sure
I support the idea enough to actively expend effort to make it happen.
I don't anticipate not being able to find the commands that I need
during an outage, and if that does become a problem, I suspect I
could get AFS or NFS working well enough to recover, even booted from
single user or install media.
>> /mit/ops/doc/admin/afs/solaris.afs.install
>> Also, the "afs", "ops", and "remote" mkserv services are used.
mhpower> I don't think it's appropriate for all of the effects of
mhpower> "mkserv ops" to be left in place on the machine. One
mhpower> issue is that I don't believe any sipb machines should be
mhpower> running an update_server process. We don't have any
mhpower> apparent use for the functionality it supplies, and thus
mhpower> it's an unnecessary network daemon process. The sipb afs
mhpower> servers aren't maintained by ASO and therefore we
mhpower> shouldn't provide for whatever indirect access
mhpower> possibilities may exist via access to the moira
mhpower> server. There was a major security hole within the last
mhpower> couple of years related to lack of authorization checking
mhpower> in the moira update code, and since problems of that type
mhpower> could conceivably arise again, I think we are better off
mhpower> without update_server running.
I strongly agree that we should not run update servers for the
reasons pointed out.
mhpower> Also, whenever mkserv ops is run it replaces syslog.conf
mhpower> with a standard version that I think is the one in place
mhpower> on ASO servers -- this would interfere with sipb's
mhpower> syslog.conf customizations. (There's also a similar
mhpower> effect on inetd.conf, so if we happen to run inetd that
mhpower> would be an issue too.)
Another set of good points.
mhpower> ASO servers is adequate for ASO's needs. One of the
mhpower> differences from sipb is that, if a problem with an ASO
mhpower> server occurs at any arbitrary time of day and year, ASO
mhpower> has the ability to get a qualified person to look at the
mhpower> problem within (I'd expect) often less than an hour. This
mhpower> is not the case for sipb. Because of that, I think sipb
mhpower> needs to be more careful with its server configurations
mhpower> and needs to anticipate some potential problems, in case
mhpower> the potential problems happen to become operational
mhpower> problems at an unexpected and inconvenient time.
In my experience, solutions like using UFS backups tend to complicate
rather than simplify recovery. I agree that having simpler
configurations would be good, but I disagree that what you propose is
actually simpler, more maintainable, or more useful in a critical
situation.
mhpower> I'll try to give a complete list of the changes that I
mhpower> think are worthwhile, although I'll likely bring up
mhpower> things that don't need to be changed, because there are
mhpower> some aspects of the ASO afs-server configuration that I
mhpower> unfortunately misunderstand even after reading the
mhpower> solaris.afs.install and ss.afs files that you pointed me
mhpower> to.
mhpower> I already mentioned the update_server issue. I think ASO
mhpower> afs servers run rpcbind (or portmap on SunOS 4). This
mhpower> isn't needed for afs service to function. The sipb afs
mhpower> servers don't run portmap. There are some potential (not
mhpower> yet known-exploitable) security issues related to rpc,
mhpower> such as mentioned in
mhpower> http://www.mit.edu:8008/menelaus/bt/6797, and I believe
mhpower> it's prudent to not run the unnecessary rpcbind daemon.
Sounds reasonable.
mhpower> Similarly, I think snmpd is unnecessary and shouldn't be
mhpower> run.
Sounds reasonable to me at least.
mhpower> Some sipb afs maintainers receive syslogs via zephyr from
mhpower> the sipb afs servers. (I think that ops has some
mhpower> alternate notification solution involving a private
mhpower> zephyr class.) I think sipb afs servers running SunOS 5
mhpower> should also use a version of syslogd that supports
mhpower> zephyr. (The sipb afs servers run a script called
mhpower> afs2sl.pl that generates extra syslogs, but that can be
mhpower> set up later and doesn't especially need to be part of
mhpower> the installation process.)
mhpower> Another syslogd issue is that it should not process data
mhpower> received via udp port 514, because of potential security
mhpower> and denial-of-service issues. The current sipb afs
mhpower> servers are set up such that incoming syslog udp data is
mhpower> discarded.
Is there a zephyr-enabled syslogd that accomplishes this? If it
already works on Solaris, this sounds reasonable; otherwise, it
doesn't appear to be worthwhile.
mhpower> With a zephyr syslogd, zhm is needed (I think zhm is
mhpower> present on ASO afs servers, but I'm not sure). I believe
mhpower> it's best to run zhm as a non-root process, since zhm
mhpower> doesn't need root access for any significant reason.
I'm not sure that this is worth the configuration change from
standard Athena. Several critical ASO servers, including moira appear
to be running zhm; given access to one of these servers--possibly
through a zhm security hole--it would not take long to compromise the
account of at least one SIPB AFS maintainer. Thus, I do not believe
this provides significant security advantages, and at this time, it is
not clear that non-root zhm is worth maintaining a variation from
Athena.
mhpower> This is somewhat less critical, but I also think sipb
mhpower> servers should move away from relying on either the Sun
mhpower> or Athena inetd due to denial-of-service issues. I also
mhpower> feel this way about named -- I don't believe afs servers
mhpower> generate enough DNS queries to warrant their own
mhpower> named. Instead, I'd probably favor putting names of other
mhpower> sipb servers (or other appropriate machines that do run
mhpower> named) into resolv.conf.
What inetd do you propose? I do not consider the solution provided
below reasonable.
mhpower> An important, although perhaps more controversial, issue
mhpower> is that I don't think sipb should deploy any new servers
mhpower> that allow root shell access on the basis of single-des
mhpower> session keys. I'm not completely sure of the state of
mhpower> triple-des support in Kerberos, but I think what I'm
mhpower> suggesting is that root shells be possible only via sshd
mhpower> (without Kerberos), and that klogind and kshd (both V4
mhpower> and V5) should be shut off. On a similar note, I'd favor
mhpower> having bosserver recompiled such that BOZO_Exec returns a
mhpower> failure code even if a client is a valid privileged user.
This is ludicrous. AFS uses single DES, and doesn't even checksum
files. You are proposing protecting your servers with significantly
more protection than you use in order to modify the data on these
servers. Given s:a in the SIPB cell, it would not take long to
compromise a maintainer's account and gain access to the server,
although arguably the ability to modify any file in the cell is almost
as bad as root on the server. I certainly do not think this change
is going to be worth building our own AFS bosserver and maintaining
this server.
Also, there have been times when bos exec was useful in dealing with
outages. In the spirit of maintaining flexibility to deal with
outages, since as you point out, we do not have the same response time
as ASO, we should be increasing rather than decreasing our ability to
easily remotely administer the server.
I realize that security is an important consideration. However, when
I evaluate the tradeoffs of these restrictions against the complexity
of the configuration changes and the decreased maintainability, I do
not believe they are justified.
mhpower> For sshd_config, I would want to allow only RSA
mhpower> authentication and password authentication (of course
mhpower> using ss.afs in such a way as to get the sipb afs root
mhpower> password into /etc/shadow).
I object to allowing password authentication; the current SIPB AFS
password is not particularly strong, and is reasonable only if used
from a protected machine room.
I also object to only allowing RSA authentication; this makes it
significantly harder to get onto the server for maintainers who do not
have dedicated machines on which to store an RSA key. For the rest of
us, it means we have to store additional authentication information,
keeping yet another password secure and another key secure.
mhpower> Finally, for completeness, I think the changes such as
mhpower> shutting off unnecessary daemons should be made before
mhpower> the machine boots with those daemons running. A procedure
mhpower> for doing this was documented by ghudson in steps 2 and 3
mhpower> of /afs/sipb/services/solaris/README.
I do not think this complexity is justified. This again falls into
the category of things I wouldn't mind Matt doing were he doing the
work but that I think it is unreasonable for him to insist others do.
[I realize you are not insisting--just stating a preference.]
mhpower> I think that's all I'd find necessary for SunOS 5.6 sipb
mhpower> servers that allow only root to login. (I don't think
mhpower> these steps are adequate for servers that allow some user
mhpower> logins, and in most cases sipb servers should allow user
mhpower> logins especially since we sometimes want to let new
mhpower> prospectives look at the setup of our servers before
mhpower> they're ready to have root access. But probably that
mhpower> isn't useful for an afs server.)
I think the server security requirements on machines that we allow
somewhat trusted prospectives to log into is significantly lower than
machines that we allow for wider use. I realize that some SIPB
servers, like rtfm, would require much greater attention to security
details than we propose for the AFS server.
