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
[-- Attachment #1 --] On Wednesday 13 September 2006 16:29, Robert Watson wrote: ... > - 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. ... > - 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 flags - at least partly. I didn't find any in your email so: Wouldn't it make sense to mask off at least part of it to encode some general 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 something else wants to decide on finer granularity, alright, but in my opinion it's easier (more obvious) to keep the "normal" information in the .h file where the privileges are defined and described - as we are aiming for centralization of the decision and information. On top of that the caller could mask off ALLOW_IN_JAIL if they think it's not appropriate in a special use case of the privilege. On an aside, it would be nice to have "optional" privilege checks i.e. in pf we trust the file permissions on /dev/pf (plus securelevel) to decide if someone is allowed to fiddle with the firewall. It would be nice to have a way of allowing MAC (or whatever) to decide this - without disallowing non-root use as long as the policy doesn't care. In code that would mean a "if (flags & SUSER_OPTIONAL) return (0);" just before the "if (suser_enabled) ..."-block. The policy would have it's go in mac_priv_check() above. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFCKfyXyyEoT62BG0RAm+oAJ0R+b7GOdcs8AWmgcTeH0zKRtcnXACfWJaz N4Ze73ntubwq04t0FmTpn9s= =Gogc -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200609140253.06818.max>