On 2004-11-30 tls@rek.tjls.com wrote:

> 2) Typically, my hardened systems run with all writable filesystems mounted
>    nodev.  Let me just venture to guess that if I weren't pointing it out
>    right now, nobody would bother to think that devfs must refuse to mount
>    if its configuration file were on a nodev filesystem.
>
> 3) Enforcing the restriction necessary due to #2 means that the file
>    parser *must* be in the kernel (think about it: you *cannot* allow
>    a userland program to feed you a devfs config structure from RAM,
>    or there is no point to ever trying to mount anything nodev; the
>    kernel *must* read the config file itself so it can know where it
>    is stored and check for nodev).  That means quite a bit of complicated
>    code in the kernel (including a parser, and code to read files from
>    the filesystem, which AFAIK only LFS does right now, and that only
>    for the ifile)

  I don't understand point #3.  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?  Continued use of the file from RAM might
be bad, but this could easily be avoided.

>    and all of this code seems likely prone to bugs which
>    could have significant security implications.  That's particularly
>    scary to me.

  I don't think a good devfs should be particularly complex.  Certainly
careful consideration and testing of particular implementation would be
necessary, and this is a good argument for keeping the current system
around until the new system is proven, not just until an arbitrary
deadline.

Matthew Orgass
darkstar@city-net.com