Subject: Re: kern.showallprocs implementation
To: Elad Efrat <elad@NetBSD.org>
From: Bill Studenmund <email@example.com>
Date: 08/30/2005 11:09:32
Content-Type: text/plain; charset=us-ascii
On Tue, Aug 30, 2005 at 07:16:23PM +0300, Elad Efrat wrote:
> Steven M. Bellovin wrote:
> > Compatibilty is a good thing, in my opinion. I suggest that we find=20
> > out why FreeBSD picked the name they did.
> ``The security.bsd sysctl hierarchy sets global properties of the BSD
> security model. The following sysctls are defined:''
> This is the name chosen for this node by FreeBSD.
> If we have a closer look at the features, we can clearly see that they
> (most of them) were definately not introduced in FreeBSD, nor any BSD:
I think you are missing the point. My understanding is it's not that the
features were definitively introduced in FreeBSD or in a BSD, it's the
model used for privilege designation and deliniation.
> see_other_uids, see_other_gids - 3rd-party patches for these were around
> for years.
> hardlink_check_uid, hardlink_check_gid - These were implemented by Solar
> Designer (first in Openwall, now Owl) for almost a decade now.
> suser_enabled - out of the question for us, at the moment.
Total tangent, why is this not possible as a readable node?
> conservative_signals, unprivileged_proc_debug,
> unprivileged_read_msgbuf, unprivileged_get_quota- don't we want these
> per-program (perhaps inside a per-program policy..?) or per-user?
> Bottom line is that these features are not any ``BSD security model''
> that was discussed; it's a collection of commonly requested features
> as implemented in FreeBSD. I see no reason to keep any compatibility.
I think you're missing the forest for the trees. Look at the names.=20
"unprivileged_" this and "unprivileged_" that. How does the kernel know if=
something's privileged or not? UID 0. And I think that's why it's the=20
"BSD security model." It runs on UID/EUID/GID/EGID and such.
Sure, it could have been the "unix" security model (modulo the fact that
"UNIX" is a trademark in the USA). It could have been the "traditional" =20
model, but that's kinda long to type. But it's not, it's "bsd". Since
there's prior art, if we are doing the same thing as prior art (even if we
do it our own way), why not use the same name?
If I thought the naming was because it was a "coherent security model=20
introduced in *BSD," then I would agree with you strongly about the name=20
being inappropriate. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----