--8P1HSweYDcXXzwPJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 29, 2004 at 11:48:37AM -0800, Jonathan Stone wrote:
> In message <20041127225340.GB25324@netbsd.org>Bill Studenmund writes
>=20
>=20
> >If you're creating such images, you're creating an image of the root file
> >system as part of creation (I'd expect you're shoving it into a kernel
> >like what we do for install kernels, but you might do something else).
> >So just build into this image a devfs file (of whatever form we end up
> >with) that has your devices as you like them. Add a mount flag, and new
> >devices don't show up. So you get exactly what you configured.
>=20
> The dynamic creation aspect -- the need for a separate list of
> device-nodes-to-be-created-and-create-permissions, plus the separate
> in-kernel code to do all that -- is highly undesirable.

Why?

While you're getting closer to you're thought process, you still aren't
explaining all the steps. You're still starting part way along the path; =
=20
you've assumed things and aren't explaining why. You're saying "[it's]
highly undesirable," without explaining why. You aren't describing attacks
nor expressing concerns that can turn into requirements on an
implementation.

I really don't get why having a separate list for device nodes is an=20
issue. Mainly since we have that now.

Right now, as part of the unprivileged builds, we generate a metalog that=
=20
includes the names, device IDs, and permissions of all of the devices.=20
Like:

=2E/dev/null type=3Dchar device=3Dnetbsd,2,2 mode=3D666 gid=3D0 uid=3D0

So we already have everything we all have been talking about. All I'm
really describing is that stanzas like the above don't get processed by
tar (and turned into device entries in the tar ball), but instead get
processed by a tool that spits out a file that gets put in the image. And=
=20
since all the magic currently happens in=20
src/distrib/common/Makefile.makedev, we just add a separate tool to the=20
chain and presto, we have the devfs file we need.

So other than the fact that there's a kernel part, I don't see how things=
=20
are different from a wiring-down point of view.

I will make note of one thing I, and I thought others, mentioned earlier,=
=20
which is that we envision a way to mark devfs as these-devices-only. That=
=20
way devices that weren't listed don't just appear in the wired-down=20
system.

> If we can consider for a moment just those applications I'm thinking
> of (say, hardened devices running off an in-kernel mfs, as you guessed
> earlier) the whole idea of devfs strikes me as unnecessary bloat.
> 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.  And (amonst people with similar security
> concerns) I am not alone in that.

"bloat" is an objection I can understand. I disagree with it, but at=20
least I can understand it. As we don't have a concrete implementation,=20
it's hard to say how much bloat we're talking about.

However NetBSD isn't the first OS to consider a devfs. Others have it, and=
=20
I've not been lead to believe that they are any less secure for it.

> Again, for these hardened embedded systems,I don't care how good the
> dynamic-devfs machinery is: for some applications, I *don't want any of i=
t*.
>=20
> Bill, I don't like to feel like I'm shouting at you, but we seem to be
> not-communicating on the actual technical issues. Lets try to talk
> offline (phone?), and see if that works better.

While I wouldn't mind other communications channels, I think the real=20
thing we'd need would be to meet in person. Unfortunately I'm not going to=
=20
be able to head to the bay area any time soon. :-|

Also, I think keeping the discussion on the list helps in that other folks=
=20
will (hopefully) contribute. And folks who are bored can hit the 'd' key.=
=20
:-)

Take care,

Bill

--8P1HSweYDcXXzwPJ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFBq7tmWz+3JHUci9cRAtKjAJ4vyJXTmWcoYjrMJ0dTbl2PJKghWACfc12Q
FR10H7aNP5U4VZmquZ+nRAE=
=BiL8
-----END PGP SIGNATURE-----

--8P1HSweYDcXXzwPJ--