Date: Thu, 14 Sep 2006 02:52:58 +0200 From: Max Laier <max@love2party.net> To: freebsd-arch@freebsd.org Cc: trustedbsd-discuss@trustedbsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: New in-kernel privilege API: priv(9) Message-ID: <200609140253.06818.max@love2party.net> In-Reply-To: <20060913150912.J1823@fledge.watson.org> References: <20060913150912.J1823@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1904315.JXRpWPjbaF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 13 September 2006 16:29, Robert Watson wrote: =2E.. > - It makes it possible to migrate the "allowed in jail" decision from > the calling context to the privilege management code. This will allow > us to gradually eliminate the passing of flags to the privilege check > code under almost all circumstances. In my patch, I have added a new > function to kern_jail.c, prison_priv_check(), which essentially > contains a switch statement listing the privileges allowed in jail, and > denying the rest. Configurable privileges, raw socket access, etc, can > now occur in one place, and open the door to introducing more easy > per-jail configuration of privilege. After these changes, the > implementation is much more centralized in kern_jail.c. =2E.. > - Privileges under this model are not treated as maskable values. In > practice, there are very few situations in which it is useful to > check multiple privileges at once, and permitting that encourages > authors adding new privilege checks to combine privileges in a way that > makes it opaque to the privilege mechanism as to which privilege was > actually needed. This also has the benefit of making it much > easier/more efficient to add new privileges as required, as it doesn't > require expanding a bit string representing the privileges. Most > POSIX.1e implementations limit the total number of privileges to 32 to > 64 in order to have them fit in a bitmask easily. I tried to read with care and understand the reason behind not using=20 flags - at least partly. I didn't find any in your email so: Wouldn't=20 it make sense to mask off at least part of it to encode some general=20 decision into the privilege value directly. A la: #define ALLOW_IN_JAIL 0x8000000 #define PRIV_KTRACE (42 | ALLOW_IN_JAIL) Right now, prison_priv_check() is looking rather scary to me. If=20 something else wants to decide on finer granularity, alright, but in my=20 opinion it's easier (more obvious) to keep the "normal" information in=20 the .h file where the privileges are defined and described - as we are=20 aiming for centralization of the decision and information. On top of=20 that the caller could mask off ALLOW_IN_JAIL if they think it's not=20 appropriate in a special use case of the privilege. On an aside, it would be nice to have "optional" privilege checks i.e. in=20 pf we trust the file permissions on /dev/pf (plus securelevel) to decide=20 if someone is allowed to fiddle with the firewall. It would be nice to=20 have a way of allowing MAC (or whatever) to decide this - without=20 disallowing non-root use as long as the policy doesn't care. In code=20 that would mean a "if (flags & SUSER_OPTIONAL) return (0);" just before=20 the "if (suser_enabled) ..."-block. The policy would have it's go in=20 mac_priv_check() above. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1904315.JXRpWPjbaF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFCKfyXyyEoT62BG0RAm+oAJ0R+b7GOdcs8AWmgcTeH0zKRtcnXACfWJaz N4Ze73ntubwq04t0FmTpn9s= =Gogc -----END PGP SIGNATURE----- --nextPart1904315.JXRpWPjbaF--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200609140253.06818.max>