tamir@CS.UCLA.EDU (04/09/87)
It is well known that with the current NFS you must trust
the roots of all the machines to which you export file systems.
The reason is that the root on client machine can read/write/modify
any file not owned by root on the server (by using su to become
the user who is the owner of the file on the server).
I have heard that Sun is working on a solution to this problem.
Does anyone know how this solution will work ?
I don't see how you can solve this problem with a stateless server.
Yuval Tamir
Internet: tamir@cs.ucla.edu
UUCP: ...!{ihnp4,ucbvax,sdcrdcf,trwspp,randvax,ism780}!ucla-cs!tamirdavidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (04/13/87)
Assuming that there is a public key encryption program available on the
client and server, there are a number of ways to obtain (relatively)
secure connections, validated in both directions. One very simple
variation on this:
1) client sends a message "Hi I'm so-and-so" encrypted with the
server's public key. The server must have the private key to decode the
message and discover the prospective clients identity.
2) the server generates a temporary key pair, and sends the public key
to the client encrypted with the client's public key. The client must
have the client private key to discover the session key.
3) the session key is used to encrypt the rest of the communication.
Notes:
A public key system is one in which there are two complementary keys,
and encrypting a message with one requires decryption with the other.
One key can be "public", because having the public key does not allow
the message to be read. A return message, encrypted with the private
key, will return to clear text when decrypted with the public key.
a message sent using the public key can be read only with the
private key. Anyone can send a message using the public key but
only the holder of the private key can read it.
If the holder of the private key encrypts a message, anyone with
the public key can read it, but the sender must be in possesion of
the private key. This validates the sender.
The above is a very simple case of this type of connection, and will
fail of (a) the identitfy of the client is known at the time of
connection (without reading the "here I am") message, and (b) there is a
false server intercepting the messages. Methods of avoiding
this are relatively easy to devise, but require more handshaking and
may involve several session keys.
Encryption may be nested. A message may be encrypted with the senders
private key and the recipients public key, which can be decrypted only
by having the senders public key (proving the senders identity by being
able to generate the message) and the recipients private key (proving
the recipients identity by being able to read the message).
Sometimes only the login sequence is carried out in encrypted fashion if
the messages are not critical, since the time to encrypt and decrypt
messages is fairly long on most systems.
----------------
Feel free to clarify this posting, I was trying to present an overview
to the original poster. If you must flame, do it by mail.
--
bill davidsen sixhub \
ihnp4!seismo!rochester!steinmetz -> crdos1!davidsen
chinet /
ARPA: davidsen%crdos1.uucp@ge-crd.ARPA (or davidsen@ge-crd.ARPA)devine@vianet.UUCP (04/16/87)
In article <1430@steinmetz.steinmetz.UUCP>, davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) writes: > Assuming that there is a public key encryption program available on the > client and server, there are a number of ways to obtain (relatively) > secure connections, validated in both directions. One very simple > variation on this: > > 1) client sends a message "Hi I'm so-and-so" encrypted with the > server's public key. The server must have the private key to decode the > message and discover the prospective clients identity. This does not give authentication. Imagine that clients A and C both send the string "Hi, I am A" to server B. Because both used B's public key, B can not discover who really is A. The correct solution is to send a message to B that is based on the private key; this works unless the private key has been compromised (either stolen or given away). How the private key is used to form the secure message to B depends on whether the PK algorithm is symmetric with respect to encryption/decryption. Bob Devine
mike@louis.UUCP (Mike Woods) (04/21/87)
In article <16425@sun.uucp> marks%ferne@Sun.COM (Mark Stein) writes: >Encrypted authentication information will be used in the RPCs for NFS >requests. Won't this have a significant impact on non-USA sites who don't have (and can't get) the DES chips. I seem to remember that in the cited paper there was a degradation figure of 20%! Will I be able to turn off most of the encryption (our network is not being bugged by the commies!) and still have a solution to the "su" security hole? Mike Woods PS - Can't the problem be solved by having uid/gid mapping between machines (saves all those "find / -user x -exec /etc/chown y {} \;" when you want to bring a new machine into the NFS fold too). UK JANET: mike@uk.ac.rl.vd UUCP: ..!mcvax!ukc!rlvd!mike