Path: utzoo!attcan!uunet!husc6!mailrus!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: NFS security
Keywords: NFS, mknod
Message-ID: <67200@sun.uucp>
Date: 7 Sep 88 19:09:46 GMT
References: <126@leibniz.UUCP> <670028@hpclscu.HP.COM> <1394@basser.oz> <14186@comp.vuw.ac.nz>
Sender: news@sun.uucp
Lines: 51

> The way I interpreted the comment that Guy is responding to was, "on
> all versions of SunOS without NFS, mknod does not have a problem, and
> since (as desribed in a previous article) there is a problem with
> mknod on systems with NFS, it is an NFS problem".  Given this
> interpretation the reasoning doesn't seem so silly.

Considering he didn't try it on any 1.x releases, and therefore didn't try it
on any versions without NFS, it is difficult to see how the comment could be
interpreted in that fashion.  (In fact, he didn't try it on 3.0; 3.0 *did* have
NFS, but I suspect it didn't have this problem, because I don't think it
allowed "mknod"s over the wire.)

Furthermore, the problem occurs when you succeed in doing a "mknod" system
call, and you can only do so when you are running as root; he didn't try
running "mknod" as root, because the message in question only comes out when
you're *not* root.

The message from the "mknod" command has nothing to do with any attempt to
close the security hole in question:

	1) putting a check into the "mknod" command doesn't close the hole, it
	   only narrows it slightly, since anybody who can build a program at
	   all (i.e., has access to the requisite tools and knows enough e.g.
	   C) can build a program that calls "mknod"

and

	2) the check in the "mknod" command merely duplicates the check
	   performed by the "mknod" system call, for reasons unknown to me.

The correct fix is to make UNIX NFS servers refuse to create special files
other than FIFOs if the credentials *after* any UID mapping is performed don't
say the user is root.  The best way to do this on a kernel with the VFS
mechanism would be to change the UFS or System V file system "create" vnode
operation to check the credentials it's handed, and refuse to do the operation
(returning EPERM) if they don't say the user is root.  (The check in the
"mknod" call itself could then be removed, as it would be redundant at best and
incorrect at worst - somebody might actually not want to require a process to
be running as super-user in order to make non-FIFO "mknod"s on their particular
file system type.)

I've submitted a bug report on this.

> My only information regarding this feature in SunOS 4.0 is a brief
> mention in the 4.0 release notes, so I may have mis-interpreted it.
> No doubt someone will correct me if I have.

No, it should be correct; if you do not specify that "/dev/console" is "secure"
in "/etc/ttytab", it should require you to give a password before going
single-user.  (I haven't tried it, so I don't know whether there are any
problems.)