NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/unix/question/10524

Internet Message Format | 1992-08-30 | 3.6 KB

Xref: sparky comp.unix.questions:10524 comp.unix.admin:4773
Path: sparky!uunet!auspex-gw!guy
From: [e-mail] (Guy Harris)
Newsgroups: comp.unix.questions,comp.unix.admin
Subject: Re: NFS security flawed (was: Re: chown : HELP!)
Message-ID: <[e-mail]>
Date: 30 Aug 92 01:28:37 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Followup-To: comp.unix.questions
Organization: Auspex Systems, Santa Clara
Lines: 60
Nntp-Posting-Host: auspex.auspex.com

>    The NFS concept that you shouldn't by default trust uid=0 has
>a fatal flaw.  If a person breaks root on a client machine, all he
>has to do is su to any other user on the system (like bin, adm,
>daemon, or sys) and have root access within minutes anyway.  NFS
>will just accpet the remote uid to be the same user as the local uid,
>and you're in.  No authentication.

That's not a fatal flaw with the notion that you shouldn't, by default,
trust a UID of 0.

It's a fatal flaw with the notion that you *should* trust any *other*
credentials that come over the wire if there's no way of making sure
that they aren't faked.

>    Unfortunately, there really isn't a better solution out there.

Well, there are a variety of *other* solutions; whether they're
"better", or "worse", or "just the same" probably depends on the person
judging them, and their requirements for security.

NFS, when using "UNIX authentication" has a simple "UID-mapping" scheme;
the NFS server can map a user ID of 0 to another user ID.  AT&T's RFS,
and, I believe, some NFS implementations, allow a more elaborate mapping
to be done, which can map other user IDs as well; RFS may support
different UID maps for different clients, but I don't know if any NFS
implementations do so.

Some ONC RPC implementations support "DES authentication", and allow NFS
to use that as well as "UNIX authentication".  With "DES
authentication", the credentials are encrypted with a password derived,
in part, from the user's password, and include an encrypted "verifier"
to make it harder to forge credentials and have the forged credentials
appear valid.  It can be a pain to set up and get working, and I've
heard claims that it's possible to crack the encryption scheme.

Sun will, I think, also have a "Kerberos authentication" flavor in
future ONC RPC implementations (SunOS 5.0, the OS component of Solaris
2.0, may already have it); the credentials include, I believe, a ticket
handed out by a Kerberos server.

Vernon's point remains valid - if a remote file server of *ANY* sort
blindly trusts the credentials on all incoming requests, then somebody
else has to make sure nobody will forge credentials.  Maybe you have a
community where you can trust everybody not to cheat; maybe you can
arrange that nobody become root on their machine, and thus can arrange
that nobody "su" to another user, or install OS software that puts out
forged credentials; or maybe you can find people who do forge
credentials, and hunt them down and kill them.

If that happens to be true, you can, at least with NFS and, I think,
with RFS, turn off *all* user ID mapping, in which case NFS and, I
think, RFS will act just like a local UNIX file system, at least in that
regard.  There's nothing *intrinsic* to NFS that means that you *can't*
get root access, under *any* circumstances; were that true, my
workstation would have all sorts of fun trying to do various things, as
it has to use NFS to get at *all* its files.

I don't know what the Andrew File System does to detect forged
credentials, nor what OSF's DCE DFS will do, nor what any other
distributed file systems do.