nfs.secure.ms

早期freebsd实现

.\" Must use  --  pic tbl eqn  --   with this one.
.\"
.\" @(#)nfs.secure.ms	2.2 88/08/09 4.0 RPCSRC
.de BT
.if \\n%=1 .tl ''- % -''
..
.ND
.\" prevent excess underlining in nroff
.if n .fp 2 R
.OH 'Secure Networking''Page %'
.EH 'Page %''Secure Networking'
.if \\n%=1 .bp
.EQ
delim $$
gsize 11
.EN
.SH
\&Secure Networking
.nr OF 1
.IX "security" "of networks" "" "" PAGE START
.IX "network security" "" "" "" PAGE START
.IX "NFS security" "" "" "" PAGE START
.LP
RPCSRC 4.0 includes an authentication system
that greatly improves the security of network environments.
The system is general enough to be used by other
.UX
and non-UNIX systems.
The system uses DES encryption and public key cryptography
to authenticate both users and machines in the network.
(DES stands for Data Encryption Standard.)
.LP
Public key cryptography is a cipher system that involves two keys:
one public and the other private.
The public key is published, while the private key is not;
the private (or secret) key is used to encrypt and decrypt data.
Sun's system differs from some other public key cryptography systems
in that the public and secret keys are used to generate a common key,
which is used in turn to create a DES key.
DES is relatively fast,
and on Sun Workstations,
optional hardware is available to make it even faster.
.#
.NH 0
\&Administering Secure RPC
.IX "administering secure RPC"
.IX "security" "RPC administration"
.LP
This section describes what the system administrator must do
in order to use secure networking.
.IP 1
RPCSRC now includes the
.I /etc/publickey
.IX "etc/publickey" "" "\&\fI/etc/publickey\fP"
database, which should contain three fields for each user:
the user's netname, a public key, and an encrypted secret key.
The corresponding Yellow Pages map is available to YP clients as
.I publickey.byname
but the database should reside only on the YP master.  Make sure
.I /etc/netid
exists on the YP master server.
As normally installed, the only user is
.I nobody .
This is convenient administratively,
because users can establish their own public keys using
.I chkey (1)
.IX "chkey command" "" "\&\fIchkey\fP command"
without administrator intervention.
For even greater security,
the administrator can establish public keys for everyone using
.I newkey (8).
.IX "newkey command" "" "\&\fInewkey\fP command"
Note that the Yellow Pages take time to propagate a new map,
so it's a good idea for users to run
.I chkey ,
or for the administrator to run
.I newkey ,
just before going home for the night.
.IP 2
Verify that the
.I keyserv (8c)
.IX "keyserv daemon" "" "\&\fIkeyserv\fP daemon"
daemon was started by
.I /etc/rc.local
and is still running.
This daemon performs public key encryption
and stores the private key (encrypted, of course) in
.I /etc/keystore :
.DS
% \fBps aux | grep keyserv\fP
root   1354  0.0  4.1  128  296 p0 I  Oct 15 0:13 keyserv
.DE
When users log in with
.I login 
.IX "login command" "" "\&\fIlogin\fP command"
or remote log in with
.I rlogin ,
these programs use the typed password to decrypt the secret key stored in
.I /etc/publickey .
This becomes the private key, and gets passed to the
.I keyserv 
daemon.
If users don't type a password for
.I login 
or
.I rlogin ,
either because their password field is empty
or because their machine is in the
.I hosts\fR.\fPequiv 
.IX "etc/hosts.equiv" "" "\&\fI/etc/hosts.equiv\fP"
file of the remote host,
they can still place a private key in
.I /etc/keystore 
by invoking the
.I keylogin (1)
.IX "keylogin command" "" "\&\fIkeylogin\fP command"
program.
Administrators should take care not to delete
.I /etc/keystore 
and
.I /etc/.rootkey 
(the latter file contains the private key for
.I root ).
.IP 3
When you reinstall, move, or upgrade a machine, save
.I /etc/keystore 
and
.I /etc/.rootkey 
along with everything else you normally save.
.LP
.LP
Note that if you
.I login ,
.I rlogin ,
or
.I telnet 
to another machine, are asked for your password, and type it correctly,
you've given away access to your own account.
This is because your secret key is now stored in
.I /etc/keystore
on that remote machine.
This is only a concern if you don't trust the remote machine.
If this is the case,
don't ever log in to a remote machine if it asks for your password.
Instead, use NFS to remote mount the files you're looking for.
At this point there is no
.I keylogout 
command, even though there should be.
.LP
The remainder of this chapter discusses the theory of secure networking,
and is useful as a background for both users and administrators.
.#
.NH 1
\&Security Shortcomings of NFS
.IX "security" "shortcomings of NFS"
.LP
Sun's Remote Procedure Call (RPC) mechanism has proved to be a very 
powerful primitive for building network services.
The most well-known of these services is the Network File System (NFS),
a service that provides transparent file-sharing
between heterogeneous machine architectures and operating systems.
The NFS is not without its shortcomings, however. 
Currently, an NFS server authenticates a file request by authenticating the
machine making the request, but not the user. 
On NFS-based filesystems, it is a simple matter of running
.I su 
.IX "su command" "" "\&\fIsu\fP command"
to impersonate the rightful owner of a file.
But the security weaknesses of the NFS are nothing new. 
The familiar command
.I rlogin 
is subject to exactly the same attacks as the NFS
because it uses the same kind of authentication. 
.LP
A common solution to network security problems
is to leave the solution to each application.
A far better solution is to put authentication at the RPC level.
The result is a standard authentication system
that covers all RPC-based applications,
such as the NFS and the Yellow Pages (a name-lookup service).
Our system allows the authentication of users as well as machines.
The advantage of this is that it makes a network environment
more like the older time-sharing environment.
Users can log in on any machine,
just as they could log in on any terminal. 
Their login password is their passport to network security.
No knowledge of the underlying authentication system is required.
Our goal was a system that is as secure and easy to use
as a time-sharing system. 
.LP
Several remarks are in order.  Given
.I root 
access and a good knowledge of network programming,
anyone is capable of injecting arbitrary data into the network,
and picking up any data from the network.
However, on a local area network, no machine is capable of packet smashing \(en
capturing packets before they reach their destination, changing the contents, 
then sending packets back on their original course \(en
because packets reach all machines, including the server, at the same time.
Packet smashing is possible on a gateway, though,
so make sure you trust all gateways on the network.
The most dangerous attacks are those involving the injection of data,
such as impersonating a user by generating the right packets,
or recording conversations and replaying them later.
These attacks affect data integrity.
Attacks involving passive eavesdropping \(en
merely listening to network traffic without impersonating anybody \(en
are not as dangerous, since data integrity had not been compromised.
Users can protect the privacy of sensitive information
by encrypting data that goes over the network.
It's not easy to make sense of network traffic, anyway.
.#
.NH 1
\&RPC Authentication
.IX "RPC authentication"
.IX "authentication" "RPC"
.LP
RPC is at the core of the new network security system.
To understand the big picture,
it's necessary to understand how authentication works in RPC.
RPC's authentication is open-ended: 
a variety of authentication systems may be plugged into it
and may coexist on the network.
Currently, we have two: UNIX and DES. 
UNIX authentication is the older, weaker system;
DES authentication is the new system discussed in this chapter.
Two terms are important for any RPC authentication system:
.I credentials
and
.I verifiers .
Using ID badges as an example, the credential is what identifies a person:
a name, address, birth date, etc.
The verifier is the photo attached to the badge:
you can be sure the badge has not been stolen by checking the photo 
on the badge against the person carrying it.
In RPC, things are similar.
The client process sends both a credential and a verifier 
to the server with each RPC request.
The server sends back only a verifier,
since the client already knows the server's credentials.
.#
.NH 2
\&UNIX Authentication
.IX "UNIX authentication"
.IX "authentication" "UNIX"
.LP
UNIX authentication was used by most of Sun's original network services.
The credentials contain the client's machine-name, 
.I uid ,
.I gid ,
and group-access-list.
The verifier contains \fBnothing\fP!
There are two problems with this system.
The glaring problem is the empty verifier,
which makes it easy to cook up the right credential using
.I hostname 
.IX "hostname command" "" "\&\fIhostname\fP command"
and
.I su .
.IX "su command" "" "\&\fIsu\fP command"
If you trust all root users in the network, this is not really a problem.
But many networks \(en especially at universities \(en are not this secure.
The NFS tries to combat deficiencies in UNIX authentication 
by checking the source Internet address of
.I mount 
requests as a verifier of the
.I hostname 
field, and accepting requests only from privileged Internet ports.
Still, it is not difficult to circumvent these measures, 
and NFS really has no way to verify the user-ID.
.LP
The other problem with UNIX authentication appears in the name UNIX.
It is unrealistic to assume that all machines on a network
will be UNIX machines.
The NFS works with MS-DOS and VMS machines,
but UNIX authentication breaks down when applied to them.
For instance, MS-DOS doesn't even have a notion of different user IDs.
.LP
Given these shortcomings,
it is clear what is needed in a new authentication system:
operating system independent credentials, and secure verifiers.
This is the essence of DES authentication discussed below.
.#
.NH 2
\&DES Authentication
.IX "DES authentication"
.IX "authentication" "DES"
.LP
The security of DES authentication is based on
a sender's ability to encrypt the current time,
which the receiver can then decrypt and check against its own clock.
The timestamp is encrypted with DES.
Two things are necessary for this scheme to work:
1) the two agents must agree on what the current time is, and
2) the sender and receiver must be using the same encryption key.
.LP
If a network has time synchronization (Berkeley's TEMPO for example), 
then client/server time synchronization is performed automatically.
However, if this is not available,
timestamps can be computed using the server's time instead of network time.
In order to do this, the client asks the server what time it is,
before starting the RPC session,
then computes the time difference between its own clock and the server's.
This difference is used to offset the client's clock when computing timestamps.
If the client and server clocks get out of sync
to the point where the server begins rejecting the client's requests,
the DES authentication system just resynchronizes with the server.
.LP
Here's how the client and server arrive at the same encryption key.
When a client wishes to talk to a server, it generates at random 
a key to be used for encrypting the timestamps (among other things). 
This key is known as the