Excerpts from mail: 9-Feb-94 Re: [EMAIL PROTECTED] (994*)
> > The drawback to this kind of system, obviously, is
> > that your AFS security becomes vulneralbe to the same breaches that NFS
> > is susceptible to.
> Actually, this is not at all obvious. I would like to see a careful
> analysis of the additional security risks posed by the NFS translator.
> I asked this list about this a while back and got nothing.
Just off the top of my head:
1. You have to run knfs on the translator machine to associate
tokens with a specific hostname and userid for an nfs mount. Using
telnet or rsh into the translator machine to do this results in your
password being sent over the network in the clear.
2. You have to run knfs on the translator machine to destroy your
tokens. Users forget to do this.
3. An imposter can set up a machine/account to pose as someone
else's hostname/userid, thereby fooling the translator into using
someone else's tokens to access AFS.
4. The translator machine's IP address is used for the AFS accesses
it makes on behalf of its NFS clients. If the translator's IP
address or subnet is placed on an ACL, all of its NFS clients will
be granted those access rights. Of course, IP addresses on ACLs
aren't a great idea, even if they worked reliably, which they don't.
Plus, the NFS/AFS Translator is buggy, and Transarc isn't making
perceptible progress in fixing it. We can hardly wait to get rid of it
here.
Other possibilities for accessing AFS from PCs are to use various ports
of MicroSoft's Lan Manager for UNIX (LMU) or Novell's Netware for UNIX.
We're just beginning to do this, but expect (at least) to run into
authentication problems we'll have to get around.
Please let me know if you hear of other ideas.
Thanks,
-keith
