nfs.secure.ms

早期freebsd实现

there is no checking of credentials during file requests,
which brings up the second problem.
If a file system has been mounted from a server that serves multiple clients
(as is typically the case), there is no protection
against someone who has root permission on their machine using
.I su 
(or some other means of changing
.I uid )
gaining unauthorized access to other people's files.
The third problem with the NFS is the severe method it uses to circumvent
the problem of not being able to authenticate remote client super-users: 
denying them super-user access altogether. 
.LP
The new authentication system corrects all of these problems. 
Guessing file handles is no longer a problem since in order to gain 
unauthorized access, the miscreant will also have to guess the right 
encrypted timestamp to place in the credential,
which is a virtually impossible task.
The problem of authenticating root users is solved,
since the new system can authenticate machines.
At this point, however,
secure NFS is not used for root filesystems.
Root users of nonsecure filesystems are identified by IP address.
.LP
Actually, the level of security associated with each filesystem
may be altered by the administrator.  The file
.I /etc/exports 
.IX "etc/exports" "" "\&\fI/etc/exports\fP"
contains a list of filesystems and which machines may mount them. 
By default, filesystems are exported with UNIX authentication,
but the administrator can have them exported with DES authentication
by specifying
.I -secure 
on any line in the
.I /etc/exports 
file.  Associated with DES authentication is a parameter:
the maximum window size that the server is willing to accept.
.#
.NH 1
\&Security Issues Remaining
.IX "security" "issues remaining"
.IX "remaining security issues"
.LP
There are several ways to break DES authentication, but using
.I su 
is not one of them.  In order to be authenticated,
your secret key must be stored by your workstation.
This usually occurs when you login, with the
.I login 
program decrypting your secret key with your login password,
and storing it away for you.
If somebody tries to use
.I su 
to impersonate you, it won't work,
because they won't be able to decrypt your secret key.  Editing
.I /etc/passwd 
isn't going to help them either, because the thing they need to edit, 
your encrypted secret key, is stored in the Yellow Pages.
If you log into somebody else's workstation and type in your password,
then your secret key would be stored in their workstation and they could use
.I su 
to impersonate you.  But this is not a problem since you should not
be giving away your password to a machine you don't trust anyway. 
Someone on that machine could just as easily change
.I login 
to save all the passwords it sees into a file. 
.LP
Not having
.I su 
to employ any more, how can nefarious users impersonate others now?
Probably the easiest way is to guess somebody's password,
since most people don't choose very secure passwords.
We offer no protection against this;
it's up to each user to choose a secure password.
.LP
The next best attack would be to attempt replays.
For example, let's say I have been squirreling away
all of your NFS transactions with a particular server.
As long as the server remains up,
I won't succeed by replaying them since the server always demands timestamps
that are greater than the previous ones seen.
But suppose I go and pull the plug on your server, causing it to crash.
As it reboots, its credential table will be clean,
so it has lost all track of previously seen timestamps,
and now I am free to replay your transactions.
There are few things to be said about this.
First of all, servers should be kept in a secure place
so that no one can go and pull the plug on them.
But even if they are physically secure,
servers occasionally crash without any help.
Replaying transactions is not a very big security problem,
but even so, there is protection against it.
If a client specifies a window size that is smaller than the time it takes
a server to reboot (5 to 10 minutes), the server will reject
any replayed transactions because they will have expired.
.LP
There are other ways to break DES authentication, 
but they are much more difficult.
These methods involve breaking the DES key itself,
or computing the logarithm of the public key,
both of which would would take months of compute time on a supercomputer.
But it is important to keep our goals in mind.
Sun did not aim for super-secure network computing.
What we wanted was something as secure as a good time-sharing system,
and in that we have been successful.
.LP
There is another security issue that DES authentication does not address, 
and that is tapping of the net.
Even with DES authentication in place, 
there is no protection against somebody watching what goes across the net.
This is not a big problem for most things,
such as the NFS, since very few files are not publically readable, and besides,
trying to make sense of all the bits flying over the net is not a trivial task.
For logins, this is a bit of a problem because you wouldn't 
want somebody to pick up your password over the net.
As we mentioned before,
a side effect of the authentication system is a key exchange, 
so that the network tapping problem can be tackled on a per-application basis.
.#
.NH 1
\&Performance
.IX "performance of DES authentication"
.IX "authentication" "performance"
.LP
Public key systems are known to be slow,
but there is not much actual public key encryption going on in Sun's system.
Public key encryption only occurs in the first transaction with a service,
and even then, there is caching that speeds things up considerably.
The first time a client program contacts a server,
both it and the server will have to calculate the common key.
The time it takes to compute the common key is basically the time it takes
to compute an exponential modulo $M$.
On a Sun-3 using a 192-bit modulus, this takes roughly 1 second, 
which means it takes 2 seconds just to get things started,
since both client and server have to perform this operation.
This is a long time,
but you have to wait only the first time you contact a machine.
Since the keyserver caches the results of previous computations, 
it does not have to recompute the exponential every time.
.LP
The most important service in terms of performance is the secure NFS,
which is acceptably fast.
The extra overhead that DES authentication requires versus UNIX authentication 
is the encryption.
A timestamp is a 64-bit quantity,
which also happens to be the DES block size.
Four encryption operations take place in an average RPC transaction:
the client encrypts the request timestamp, the server decrypts it,
the server encrypts the reply timestamp, and the client decrypts it.
On a Sun-3, the time it takes to encrypt one block is about
half a millisecond if performed by hardware,
and 1.2 milliseconds if performed by software.
So, the extra time added to the round trip time is about 
2 milliseconds for hardware encryption and 5 for software.
The round trip time for the average NFS request is about 20 milliseconds,
resulting in a performance hit of 10 percent if one has encryption hardware, 
and 25 percent if not.
Remember that this is the impact on network performance.
The fact is that not all file operations go over the wire,
so the impact on total system performance will actually be lower than this.
It is also important to remember that security is optional, 
so environments that require higher performance can turn it off.
.#
.NH 1
\&Problems with Booting and \&\fBsetuid\fP Programs
.IX "problems with booting and \&\fIsetuid\fP programs"
.IX "booting and \&\fIsetuid\fP problems"
.LP
Consider the problem of a machine rebooting,
say after a power failure at some strange hour when nobody is around.
All of the secret keys that were stored get wiped out,
and now no process will be able to access secure network services,
such as mounting an NFS filesystem.
The important processes at this time are usually root processes,
so things would work OK if root's secret key were stored away, 
but nobody is around to type the password that decrypts it.
The solution to this problem is to store root's decrypted secret key in a file,
which the keyserver can read.
This works well for diskful machines that can store the secret key
on a physically secure local disk,
but not so well for diskless machines,
whose secret key must be stored across the network.
If you tap the net when a diskless machine is booting,
you will find the decrypted key.
This is not very easy to accomplish, though.
.LP
Another booting problem is the single-user boot.
There is a mode of booting known as single-user mode, where a
.I root 
login shell appears on the console.
The problem here is that a password is not required for this. 
With C2 security installed,
a password is required in order to boot single-user.
Without C2 security installed,
machines can still be booted single-user without a password,
as long as the entry for
.I console 
in the
.I /etc/ttytab 
.IX "etc/ttytab" "" "\&\fI/etc/ttytab\fP"
file is labeled as physically
.I secure 
(this is the default).
.LP
Yet another problem is that diskless machine booting is not totally secure.
It is possible for somebody to impersonate the boot-server,
and boot a devious kernel that, for example, 
makes a record of your secret key on a remote machine.
The problem is that our system is set up to provide protection
only after the kernel and the keyserver are running.
Before that, there is no way to authenticate
the replies given by the boot server.
We don't consider this a serious problem,
because it is highly unlikely that somebody would be able to write
this funny kernel without source code.
Also, the crime is not without evidence.
If you polled the net for boot-servers, 
you would discover the devious boot-server's location.
.LP
Not all
.I setuid 
programs will behave as they should.
For example, if a 
.I setuid 
program is owned by
.I dave ,
who has not logged into the machine since it booted,
then the program will not be able to access any secure network services as
.I dave .
The good news is that most
.I setuid 
programs are owned by root, 
and since root's secret key is always stored at boot time, 
these programs will behave as they always have.
.#
.NH 1
\&Conclusion
.IX "network security" "summary"
.LP
Our goal was to build a system as secure as a time-shared system. 
This goal has been met.
The way you are authenticated in a time-sharing system
is by knowing your password.
With DES authentication, the same is true.
In time-sharing the person you trust is your system administrator,
who has an ethical obligation
not to change your password in order to impersonate you.
In Sun's system, you trust your network administrator,
who does not alter your entry in the public key database.
In one sense, our system is even more secure than time-sharing,
because it is useless to place a tap on the network
in hopes of catching a password or encryption key, 
since these are encrypted.
Most time-sharing environments do not encrypt data emanating from the terminal;
users must trust that nobody is tapping their terminal lines.
.LP
DES authentication is perhaps not the ultimate authentication system. 
In the future it is likely there will be sufficient advances 
in algorithms and hardware to render the public key system
as we have defined it useless.
But at least DES authentication offers a smooth migration path for the future.
Syntactically speaking,
nothing in the protocol requires the encryption of the conversation 
key to be Diffie-Hellman, or even public key encryption in general. 
To make the authentication stronger in the future,
all that needs to be done is to strengthen the way
the conversation key is encrypted. 
Semantically, this will be a different protocol,
but the beauty of RPC is that it can be plugged in
and live peacefully with any authentication system.
.LP
For the present at least, DES authentication satisfies our requirements
for a secure networking environment.
From it we built a system secure enough for use in unfriendly networks,
such as a student-run university workstation environment.
The price for this security is not high.
Nobody has to carry around a magnetic card or remember
any hundred digit numbers.
You use your login password to authenticate yourself, just as before.
There is a small impact on performance,
but if this worries you and you have a friendly net,
you can turn authentication off.
.#
.NH 1
\&References
.IX "references on network security"
.LP
Diffie and Hellman, ``New Directions in Cryptography,''
\fIIEEE Transactions on Information Theory IT-22,\fP
November 1976.
.LP
Gusella & Zatti, ``TEMPO: A Network Time Controller
for a Distributed Berkeley UNIX System,''
\fIUSENIX 1984 Summer Conference Proceedings,\fP
June 1984.
.LP
National Bureau of Standards, ``Data Encryption Standard,''
\fIFederal Information Processing Standards Publication 46,\fP
January 15, 1977.
.LP
Needham & Schroeder, ``Using Encryption for Authentication
in Large Networks of Computers,''
\fIXerox Corporation CSL-78-4,\fP
September 1978.
.EQ
delim off
.EN
.IX "security" "of networks" "" "" PAGE END
.IX "network security" "" "" "" PAGE END
.IX "NFS security" "" "" "" PAGE END