*BSD News Article 39961


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.