From owner-trustedbsd-discuss@FreeBSD.ORG Thu Sep 14 00:53:12 2006 Return-Path: X-Original-To: trustedbsd-discuss@freebsd.org Delivered-To: trustedbsd-discuss@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1335D16A407 for ; Thu, 14 Sep 2006 00:53:12 +0000 (UTC) (envelope-from max@love2party.net) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DBFD43D45 for ; Thu, 14 Sep 2006 00:53:11 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by cyrus.watson.org (Postfix) with ESMTP id AC5FF46C12 for ; Wed, 13 Sep 2006 20:53:10 -0400 (EDT) Received: from [88.64.185.148] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1GNfTY1LqT-0004Ll; Thu, 14 Sep 2006 02:53:09 +0200 From: Max Laier Organization: FreeBSD To: freebsd-arch@freebsd.org Date: Thu, 14 Sep 2006 02:52:58 +0200 User-Agent: KMail/1.9.3 References: <20060913150912.J1823@fledge.watson.org> In-Reply-To: <20060913150912.J1823@fledge.watson.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1904315.JXRpWPjbaF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200609140253.06818.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: trustedbsd-discuss@trustedbsd.org, Robert Watson Subject: Re: New in-kernel privilege API: priv(9) X-BeenThere: trustedbsd-discuss@FreeBSD.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TrustedBSD General Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2006 00:53:12 -0000 --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--