[3236] in SIPB-AFS-requests
Re: migrating rosebud to a Sun
daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Mon Jan 18 19:23:51 1999
Date: Mon, 18 Jan 1999 19:23:44 -0500
From: mhpower@MIT.EDU
To: hartmans@MIT.EDU
Cc: mwhitson@MIT.EDU, zacheiss@MIT.EDU, sipb-afsreq@MIT.EDU
In-Reply-To: "[3232] in SIPB-AFS-requests"
>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.
I think the issue that we've perhaps discussed enough is the overall
choice of "put a lot of OS data including all of Sun's patches onto
local disk and rely on UFS backups for fast disk-crash recovery"
versus "put relatively little OS data and few Sun patches onto local
disk, and rely on reinstalling the machine for fast disk-crash
recovery". I'm not opposed to either option. There is a separate
question of whether, in general, it's a good idea to have a
sipb-specific component to the installation procedure that makes sipb
afs servers run different software than ASO afs servers. It seems that
Sam and I agree that the general answer is "yes", but I don't want to
claim consensus since our mail was only sent today.
> mhpower> ... 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.
Ok, this is a useful perspective to know about. However, my comments
that you quoted just before this statement weren't intended to be
about UFS backups. What I meant by "more careful" was instead related
to concerns about not running processes (e.g., rpcbind) that are
unnecesary for afs service, even if we do not current know of them
causing security or performance problems, and even if not running the
daemon would make a sipb server setup diverge from an ASO setup.
>Is there a zephyr-enabled syslogd that accomplishes this? If it
>already works on Solaris, this sounds reasonable ...
Yes, I think this may be as simple as running /etc/athena/syslogd
instead of /usr/sbin/syslogd. In any case, I don't think it needs
to be part of the installation tasks. I just think that sipb afs
maintainers who wish to receive zephyr syslogs and can set that up
afterwards without creating addaitional problems should be free
to go ahead and change the syslogd setup.
>What inetd do you propose?
My preference is to run daemons normally started from inetd via
tcpserver (ftp://koobera.math.uic.edu/www/ucspi-tcp.html). This
addresses only denial-of-service issues with no other known security
component, so I think it should be fine to have the installation set
up Athena inetd (possibly also Sun inetd) and allow for a later switch
to tcpserver where appropriate.
>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.
My threat model isn't attacks against the integrity of the data on the
afs server. My threat model is an attacker interested in logging into
any machine on the sipb machine-room Ethernet to perform a network
flooding attack and deny access to all sipb services. Flooding attacks
against parts of MITnet are, unfortunately, quite common nowadays.
I'll accept the possibility that no one wishing to launch a flooding
attack yet has the capability of coming up with the single-des private
key for a sipb afs maintainer, but I'm certainly not confident that
the capability is nonexistent.
>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 guess it would help to change it and ensure that the /etc/shadow
file never traverses the network in the clear. We could leave password
authentication unavailable for now and reconsider whether this would
be helpful, based in part on whether we hear reports of single-des
Kerberos keys being successfully cracked.
>I also object to only allowing RSA authentication ..
Can I infer from this that individual sipb afs maintainers who wish
to set up ssh access for themselves should feel free to add an entry
to root's authorized_keys file and alter sshd_config to allow
RSA authentication, as long as they announce to other maintainers that
they have done so, keep their identity file and passphrase as well
protected as feasible, and don't insist that others use RSA?
Matt
