>> If the file that specifies that the file systems are supposed to be
>> mounted nodev is not parsed by the kernel, why would devfs config be
>> different?
> Nice try, but no prize.  Your analogy doesn't hold, which can easily
> be demonstrated by working through a simple example.

> Consider a system with the following filesystems mounted:

> /dev/wd0a 	/		ffs rw
> /dev/wd0b	/var		ffs rw,nodev,noexec
> /dev/wd0e	/tmp		ffs rw,nodev,noexec

> There are no device nodes present except for /dev/tty00, /dev/tty,
> /dev/null, /dev/zero, and /dev/wd0a, which is mode 00500.  wd0 has
> only an 'a' partition of type FFS.

How did wd0b and wd0e get mounted, then?  (Just curious.)

> Since no writable filesystem is mounted such that new device nodes
> can be created and used,

(I therefore assume you mean / is mounted ro.)

> I can know that I _cannot_ have a problem with, for example, a new
> device node for /dev/mem or /dev/wd0d popping up;

It seems to me that what you want here is not nodev semantics as they
exist but rather "no device nodes anywhere under this point", which
means you need not only current "any device nodes here don't work"
semantics but you also need to enforce the same flags on any mount
whose mount point is under there (regardless of the filesystem type of
the new mount).

However, this kind of security sounds awfully fragile to me: you have
three or four avenues possible for this kind of compromise and you have
to trust that you've found them all.  Introducing a fifth doesn't
really change this much.  What you want, it seems to me, is a "disable
mount(2) completely" system-wide bit (preferably also disabling
umount(2)).  Overloading this onto securelevel is not totally
unreasonable, but maybe it should be orthogonal?  In any case, it's
orthogonal to devfs.

> Now, security level 2 forbids *all* new mounts; I did this long ago
> as a very crude hack to allow me to not worry about new mounts of MFS
> filesystems without nodev and noexec.

I thought you said the kernel didn't have MFS support in it?

> However, that _is not and should not be_ necessary just to actually
> have nodev semantics enforced,

The problem here, I think, is that you want nodev to mean something
stronger than it actually does - or rather, you want something stronger
than what nodev means.  You want that inherited-nodev mount attribute I
sketched above, plus some restriction preventing mounts over other
directories in /.  MFS - or nodev - mounts don't "bypass" the nodev
attribute, except in that they provide mounts where it doesn't apply
because it's not set; they "bypass" it in much the way that importing
your own executable "bypasses" the security given by removing the
compiler.

> With devfs, with the nodes-and-permissions structure parsed by
> userland and fed to the kernel in-memory so it cannot know its
> provenance, it is essentially the case that nodev is meaningless
> against even a moderately sophisticated attacker.

Not really.  It's just that nodev doesn't protect against that
particular avenue of attack, any more than it protects against MFS
mounts.  It still provides the protection it's specified to provide;
it's just that you want something more.  Blaming nodev for not
providing it is like blaming rm for being incapable of renaming files.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B