Return to BSD News archive
Xref: sserve comp.sys.powerpc:30675 comp.sys.intel:27024 comp.os.misc:3586 comp.unix.bsd:15734 comp.unix.pc-clone.32bit:7889 comp.unix.sys5.r4:8934 comp.unix.misc:15268 comp.os.linux.development:21751 comp.os.linux.misc:32378 comp.os.linux.misc:32379 comp.os.386bsd.development:2908 comp.os.386bsd.misc:4552 Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!uwm.edu!psuvax1!psuvax1.cse.psu.edu!schwartz From: schwartz@galapagos.cse.psu.edu (Scott Schwartz) Newsgroups: comp.sys.powerpc,comp.sys.intel,comp.os.misc,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.unix.sys5.r4,comp.unix.misc,comp.os.linux.development,comp.os.linux.misc,comp.os.linux.misc,comp.os.386bsd.development,comp.os.386bsd.misc Subject: Re: Interested in PowerPC for Linux / FreeBSD / NetBSD? Followup-To: comp.sys.powerpc,comp.sys.intel,comp.os.misc,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.unix.sys5.r4,comp.unix.misc,comp.os.linux.development,comp.os.linux.misc,comp.os.linux.misc,comp.os.386bsd.development,comp.os.386bsd.misc Date: 27 Dec 1994 20:51:46 GMT Organization: Penn State Comp Sci & Eng Lines: 72 Message-ID: <SCHWARTZ.94Dec27155146@galapagos.cse.psu.edu> References: <3cilp3$143@news-2.csn.net> <3d4ucp$sbn@hearst.cac.psu.edu> <SCHWARTZ.94Dec27135416@galapagos.cse.psu.edu> <D1HHps.27n@indirect.com> NNTP-Posting-Host: galapagos.cse.psu.edu In-reply-to: wes@indirect.com's message of Tue, 27 Dec 1994 19:20:16 GMT wes@indirect.com (Barnacle Wes) writes: Why does it not address the problem? The problem is very simple. NFS (as commonly deployed) does no authentication, with the result that any communication with the NFS server is potential subversion. That, per se, is the bug. Tactics like using the mount daemon to restrict which hosts can mount filesystems, or ip filters to restrict which hosts can communicate with your server, might be adequate in very limited instances, but they fail to repair the basic defect. This is bad engineering, since you could solve the general problem in a simple way, instead of implementing piecemeal kludges with nonobvious failure modes (like using the portmapper to subvert the mount daemon's host check). Are you looking for a secure NFS installation, or just an NFS/Kerberos installation? It's not a question of security, it's a question of avoiding a manifest defect. Network filesystems need to do authentication---end of story. So far as I know, kerberos is the only freely available multi-platform network authentication system, so it's the only viable mechanism. Man netizens seem to have this knee-jerk reaction that Kerberos will solve all of their security problems so they will never have to think about security again. Bzzt! Wrong answer! But since no one has suggested that, your comment is irrelvent. I will note that many net citizens have this knee-jerk reaction that Kerberos doesn't solve any of their security problems so they will never have to think about it again. Bzzt! Wrong Answer! If you have a site that is on the internet and you use NFS, you need a firewall that will not allow NFS traffic between your LAN and your internet provider. It is that simple, and that secure. This is true only in the status quo, where NFS does no authentication. If NFS did authentication, like AFS, you wouldn't need a firewall to identify unauthorized traffice. See? You might additionally have a firewall, but it serves a seperate purpose. AT&T has a firewall, but that is irrelevent to the fact that Plan-9 needs an authentication system, which its filesystem uses. Moreover, when you say LAN, it really means the ethernet segment between your workstation and fileserver, since unauthenticated NFS doesn't even protect you from the guy in the next room, let alone folks on the internet. Just like MS-DOS. BTW, most major vendors now support some sort of Kerberos authentication in their currently shipping NFS software. What does "support" mean? Solaris has hooks for K4 in the kernel, but Sun doesn't ship kerberos. That's pretty halfhearted "support". This is why I said before that the authentication system must be NON-OPTIONAL. That way everyone is well motivated to make it really work all of the time. Making these work between any two different vendors implemenations is another problem altogether. If the unix community can't hack it, Microsoft will be happy to supplant us. And we will deserve it, too. Sigh. If there were "one great version" of Kerberos, this might be different. Might be? Kerberos 5 is defined in a standards track RFC. That seems like the obvious choice. But even if vendors go with K4, the sample implementation of K5 from MIT can generate K4 tickets, so it's not an obstacle.