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

On Fri, Oct 28, 2005 at 10:44:08AM -0400, Thor Lancelot Simon wrote:
> On Fri, Oct 28, 2005 at 07:10:24AM -0700, Jason Thorpe wrote:
> >=20
> > On Oct 28, 2005, at 12:39 AM, Jonathan A. Kollasch wrote:
> >=20
> > > Anyway, isn't having
> > >extra code for adding entries to devfs, etc. just extra bloat?
> >=20
> > No.  In fact, it's the only reasonable way to handle highly-dynamic =20
> > device discovery as found on modern systems.
>=20
> And what are we then supposed to do on another class of "modern systems",
> embedded systems which are required to have certain elements of their
> configurations static for security reasons (or in order to obtain certain
> security certifications)?  I commonly mount all read-write filesystems
> nodev, and mount all filesystems containing devices read-only, so that I
> can be *guaranteed* that no new device nodes will be available to user
> processes no matter what else changes.
>=20
> It seems like every time we discuss devfs, somewhere near the end of the
> discussion some handwaving is done about how this or that hack will be
> provided to support requirements like mine -- but at the beginning of the
> next discussion, it's entirely plain that the people advocating devfs
> couldn't really care less, because they're forgotten all about it.  This
> makes me skeptical that if devfs goes into our tree and static device
> nodes go out, I will not, in fact, lose the useful functionality of which
> I now take advantage.

Then I guess you haven't been reading my posts closely. Or I haven't been=
=20
clear enough.

I believe that I at least am taking this into account. I could
misunderstand, but I believe what would give you what you want is that 1)
no devices not explicitly configured by the startup system appear, and 2)
that at a certain security level, new devices can't be configured.

Thus only the devices explicitly configured at boot (the ones listed=20
in the config script you put in the embedded system) would be available.

Those two features shouldn't be hard, and I think they give us important=20
security abilities.

Take care,

Bill

--DSayHWYpDlRfCAAQ
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDYnTcWz+3JHUci9cRAuU0AJwJgUKogOcqtcj15ZQhbrQyJTBx8gCdHhb/
Fl2Hw0HU6QoztG3CXfkJs7k=
=RUEu
-----END PGP SIGNATURE-----

--DSayHWYpDlRfCAAQ--