On Wed, Sep 05, 2001 at 05:12:48PM -0500, Jesse Pollard wrote:
>
> Kerberos won't help either - The only parts of NFS that were kerberized
> was the initial mount. Everything else uses filehandles/UDP. Encryption
> doesn't help either - slows the entire network down too much.
I disagree! First of all you can always use NFS over TCP, so much for
"every thing else uses filehandles/UDP". (No that this improves security,
but it can improve reliability!)
True: krb5 only authenticates the mount, but krb5i also computes a
MD5-based message authentication code on every RPC request to the server
and every RPC reply to the client, thus providing integrity protection.
krb5p uses DES encryption to provide privacy. Unfortunately only Solaris
with SEAM and SEAS (or AdminPack for Solaris 8) seems to implement this.
I would love to see a Linux implementation of this!
I would like to recommend "Managing NFS and NIS" (2nd ed) from O'Reilly,
especially chapter 12 "Network Security". That chapter discusses the
mechanismns described above as well as performance and relation to IPsec
(for the impatient: using AH+ESP will give you HOST-based security, while
using krb5+krb5i+krb5p will give you USER-based security)
As for encryption slowing down the network: security does not come for free.
It is the task of the System Administrator to evalute his security requirements
against the required performance of the installation and take the appropriate
measures. Nobody ever said that was easy. It if was every MCSE could do it!
The author of "Managing NFS and NIS" (2nd ed) gave some figures on performance
degradation using krb5 (using two Ultra 5 w Solaris 8, using NFS over TCP):
Auth Throughput Degradation CPU util.
(MB/sec) rel. to "sys"
sys 5.4 - 69%
krb5 5.26 2.6% 70%
krb5i 4.44 17.7% 77%
krb5p 1.45 73.1% 99%
(Test involved writing a 200MB file to the tmpfs of the server using the
mkfile utility. I am sure one could run better tests, but...)
Now i would be more concerned with the increas in CPU utilisation than
the throughput degradation. Why? If i truly need to protect sensitive
information with encryption, i can wait for the data. But making the
server unusable for the duration of the data transfer is in most cases
not acceptable.
Dominik Kubla
-- ScioByte GmbH, Zum Schiersteiner Grund 2, 55127 Mainz (Germany) Phone: +49 6131 550 117 Fax: +49 6131 610 99 16GnuPG: 717F16BB / A384 F5F1 F566 5716 5485 27EF 3B00 C007 717F 16BB - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:33 EST