[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
NFS security ...
Date: Wed, 29 May 1991 16:38 EDT
From: firstname.lastname@example.org (Richard Billington)
To: email@example.com, firstname.lastname@example.org
As far as I know, the nfs protocol makes no provision for security, leaving
that up to the hosts involved. Since the Symbolics has no security, that means
that someone can login as anyone on a Symbolics and have that anyone's nfs
mounted files on a "secure" nfs server completely available to them.
The Symbolics NFS client implements the same security as the UNIX one.
NFS uses the authentication mechanism built into RPC, which is based on the
client establishing a verified credential with the server, and shipping that
around whenever it wants something done. There are several flavors of RPC
authentication, but the NFS protocol is only designed to handle UNIX_AUTH.
Under UNIX_AUTH, to prove that you are "joe", you just look up what Joe's
UID (user number) and GID (group number), and present them to the server.
The server doesn't ask for a password or anything - it just believes you,
and hands you back a sort of "null verifier" for your credential.
As SUN's "Network Programming Guide" points out,
"UNIX authentication suffers from two major problems:
1. The naming is too UNIX_system oriented.
2. There is no verifier, so credentials can easily be faked."
Golly, I`m not sure I would have ordered them that way, but there you have it.
Like UNIX, the Genera NFS client will not lie about who you are, and it
makes sure you are who you claim to be by asking for a password and checking
it against what's in the Yellow Pages. Of course, you can modify the
function that does that to just skip that pesky password prompting and
comparison, and always return T.
You can also modify the NFS client that runs on your UNIX box, Macintosh,
IBM or whatever, and thereby access any files on someone's server by simply
claiming you are them. It certainly doesn't matter what language it's
written in, or what operating system is being used.
The only danger from Symbolics systems is that it's generally very easy to
write computer programs on them, and you have the source code for our NFS
implementation available to start from, so it all becomes easily tractable.
1. Under SunOS, I think you can specify the hosts your NFS server will trust.
Anyone on those hosts is free to claim to be anybody at all on the server.
2. NFS tries not let anyone claim to be "root" (UID 0), and makes them be
"nobody" (UID -2) instead, to prevent attacks as root. (That is, security
is based on the fact that only root's files are of any importance to anybody,
and then "root" is never allowed any access.)
3. There is this DES_AUTH thing, which uses an encrypted timestamp as the
verifier. (First you do a key-exchange protocol.) DES_AUTH does not
include semantics for identifying UNIX users or talking about what
permissions they are asking for. In the SunOS 4.1 documentation, SUN
has not yet specified how NFS might use DES, but they mention that
they intend to someday design, document, and implement that.
(Someone who has more UNIX and NFS/RPC expertise than I do may need to
correct me on some or all of this. My understanding of the subject is about
one hour old: I was surprised by Richard Billington`s claim that there was
no security, so I just now read the relevant part of SUN's NFS and RPC
protocol documentation, and then poked around in the Symbolics NFS code.)