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

On Tue, Aug 30, 2005 at 01:50:12AM +0100, Rui Paulo wrote:
> On 2005.08.29 17:05:35 +0000, Bill Studenmund wrote:
> | security.bsd.what? What name do you propose for the last component?
>=20
> security.bsd.hideproc
> security.bsd.hideinet

Please, use one knob. Or please explain to me a realistic situation where=
=20
we want one yes and the other no.

Really, please explain a likely case where we want one blocking and not=20
the other.

All the times I can think I'd like to deny a proc/user knowledge about=20
other processes, I also want to deny that proc/user knowledge about open=20
sockets (and file descriptors and all the other things we can think to=20
extend this to).

Say the admin blocks process visibility. If I can still see there's an
open listen socket on tcp/80, what do you bet there's a web server on the
box?  Likewise, say I block sockets visibility but not process. If I see=20
"httpd" in ps, what do you bet something fun is at 80, 8000, or 8080? :-)

So I think if we want blocking, we want all blocks on or all off.

While it doesn't matter much with just two knobs, I already would love us=
=20
to add fstat support. So that would be a third knob. Then we add it to=20
another subsystem, and we have a fourth knob. And so on.

So we will have all these knobs, and we want to flip them all the same way=
=20
all the time. Thus it strikes me as error-prone to have a lot of switches=
=20
that need to be flipped together. It seems much safer to make one big=20
switch.

I agree there is an intelectual purity to having separate knobs for each=20
subsystem. However I think we'll be better off making one knob for now.

Also, we are taking an incrimental step. Let's add the one knob, then we=20
can add sub-knobs if we find applications that need them. We are, after=20
all, going to evolve the interface. :-)

Take care,

Bill

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

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

iD8DBQFDE75xWz+3JHUci9cRAg7AAJ9wwsa/Xt7Bz00lzMU3dtoOUVT8/wCeNa3q
2oAcieKvR3s/QKEdrJqM1g0=
=EdFp
-----END PGP SIGNATURE-----

--dLXnlYbDJNCwF3YM--