> I want no _new_ device nodes anywhere on the system; not just "not
> below here", but rather "not at all".

Right, but that's a global system thing, and thus only semi-possible to
put into mount-point flag bits.

If you had two bits - "no devices in this mount" (nodev) and "no
devices under this mount" (nosubdev, maybe), where the second causes
any mount under it to acquire both, then you could get what you want by
doing

- mount / normally
- mount devfs nosubdev but not nodev (nosubdev so that someone can't eg
  mount something over /dev/fd)
- remount / -o update,nodev,nosubdev
- mount other mounts normally (they will get nodev,nosubdev because /
  now has nosubdev)

> Requiring that all writable filesystems have nodev set is a very
> simple and elegant way to get that.

But insufficient - see below.

> There are three ways to achieve that now:

> 1) Run at security level 2, which prohibits all new mounts.  This
>    would still work with mandatory devfs, assuming devfs does *not*
>    allow new nodes to be created after mount,

Or at least that it can be set that way.

> 2) Run at the standard security level 1, but do not include MFS
(or NFS or various other filesystems)
>    in the kernel, provide no device node for the raw device of the
>    system disk, and ensure that all existing partitions are already
>    mounted.

Possible but, as you note, fragile.

> 3) Make the simple kernel change I described earlier, such that no
>    device node on any _writable_ filesystem can be used; that is,
>    embed this policy in the kernel.

That's not enough.  Nothing then stops your putative attacker from
creating an MFS with device nodes in it and then mounting it RO.

> But it seems to me that devfs breaks this model completely, because
> it will always be possible to hook up a new devfs,

Maybe that's what we need.  "sysctl -w kern.devfs.more_mounts=0"?

That is, provide a way to totally disable mount(2) _for devfs_?

> and there's no way to really require that the config file have any
> particular attribute, whether immutable, present on nodev filesystem,
> or _whatever_ -- unless the parser is in the kernel, not userland.

Not quite.  For example, if devfs could be mounted only by PID 1, that
could perhaps do it.  (Yes, that as a bunch of other problems.
Certainly pushing the parser into the kernel is the _best_ of the ones
that I can think of; it's just not the _only_ one.)

Another thing we could do could be to have the config file parser in
userland but have a small kernel language - akin to bpf, maybe - that
vets the parsed config file before using it.  (No, I'm not sure I'd
seriously suggest that, but I'm not sure I wouldn't, either - it
occurred to me just now and I haven't put much thought into its
possible problems.)

/~\ 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