In message <20041130085000.GA16800@cs.uni-bonn.de>,
Ignatios Souvatzis writes:

>Jonathan Stone wrote:
>
>> When I put on my security-conscious hat, my first, second, and third
>> take on the matter are to `Just say No', and to go with persistent
>> in-filesystem device inodes.
>
>How is a non-writable,non-remountable static /dev different from=20
>a non-writable, system immutable devfs configuration file?
>
>I'm not not the most security conscious admin around, but in my book,
>having anything writable (that is, outside the kernel) define the
>mapping between names and devices doesn't sound to good. I think that
>devfs is better in this respect, because it makes the kernel define
>the name-device relation.
>
>Maybe somebody can explain to me why this isn't true.
>
>Regards,

Ignatios,

Thor's answer looked great to me.  I'll add just one thing,  based on
off-list discussion with Bill:

The real worry I have with devfs is the sheer volume of code
(not-yet-written code) that we'd have to trust, in order to tie down a
system the way Thor wants or I want.  The issue for me isn't the
semantic differences (and potential attacks) between in-filesystem
inodes, versus a devfs which has executed its tie-down config
rules. The issue is trusting *all* the codepath which does the
tying-down, and trusting that the code *really* enforces the tying-down.

If there's simply no code in your kernel that can cons up device
nodes, then the technology to set up a nodev system is well known,
well understood, and builds on the 20 years of collective experience
with device inodes and permissons in Kirk McKusic's FFS. That gives a
*very* high level of assurance in hardening exercises that Thor
outlined so clearly.

If those who want a devfs start on it now, as an option, and leave
support for in-fileystem inodes for those who want it, then we can
start building confidence in the (as-yet unwritten) devfs code. And
maybe we can think about removing in-filesystem inodes when and if we
_really_ trust the devfs code.  Maybe by, oh, 2010, or something.