Subject: Re: kern.showallprocs implementation
To: Bill Studenmund <>
From: Rui Paulo <>
List: tech-kern
Date: 08/30/2005 03:18:41
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2005.08.29 19:03:29 +0000, Bill Studenmund wrote:
| 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=
| we want one yes and the other no.
| Really, please explain a likely case where we want one blocking and not=
| 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=
| 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=
| "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=
| 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 wa=
| all the time. Thus it strikes me as error-prone to have a lot of switches=
| 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=
| 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=
| can add sub-knobs if we find applications that need them. We are, after=
| all, going to evolve the interface. :-)

So, explain me why we have securelevel -1, 0, 1 and 2. :)
But anyway, we'll get nowhere if we keep discussing how many knobs will we
have... Just go for one knob and then let's see what happens.

		-- Rui Paulo

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

Version: GnuPG v1.4.1 (NetBSD)