Subject: Re: devfs (was Re: Not updating device file inode change times)
To: Stefan Grefen <firstname.lastname@example.org>
From: Todd Vierling <email@example.com>
Date: 09/06/1998 23:46:16
[thread copied to tech-security since I'm explaining the pitfalls of a
On Sun, 6 Sep 1998, Stefan Grefen wrote:
: > Real
: > device nodes on a NFS-mounted /dev are, as said before, dangerous and a
: > serious security risk.
: But than a file just doesn't help here, or you have to authenticate the file
: with secret ...
Authentication isn't the problem. The problem is device nodes which have
the "wrong" major and minor on the NFS _server_.
Just a straw example: You log into a NetBSD/arm32 NFS client on the
console. The NFS server is NetBSD/alpha. So the arm32 client's
/dev/console, device 2,0, becomes your uid and readable and writable by you.
Log into the alpha server and do reads from /export/somebox/dev/console, and
be very surprised by the fact that you're reading the Alpha's /dev/mem!
(Remember that the device node is also _writable_ by your uid.)
This device number inconsistency is a bug in the _best_ case. When you
bring non-NetBSD systems into the picture, it's just plain dumb.
One way of helping is by providing a mechanism by which plain files on the
NFS server can become device nodes - sort of like a "rose colored
sunglasses" layer filesystem. The filesystem would just translate files via
some not yet determined mechanism, both on read/write and inode
I'm actually quite surprised to learn that our NFS implementation doesn't
support a `nomknod' export option, either. I'm submitting a PR on that one.
-- Todd Vierling (Personal firstname.lastname@example.org; Bus. email@example.com)