From owner-freebsd-arch@FreeBSD.ORG Fri Sep 15 00:08:58 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B763316A407; Fri, 15 Sep 2006 00:08:58 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E33F43D46; Fri, 15 Sep 2006 00:08:57 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.182.121] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1GO1GJ0KnT-0002n7; Fri, 15 Sep 2006 02:08:56 +0200 From: Max Laier Organization: FreeBSD To: Robert Watson Date: Fri, 15 Sep 2006 02:08:45 +0200 User-Agent: KMail/1.9.3 References: <20060913150912.J1823@fledge.watson.org> <200609140253.06818.max@love2party.net> <20060914224516.G53301@fledge.watson.org> In-Reply-To: <20060914224516.G53301@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="nextPart1696485.Dd1bkIxD5j"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200609150208.53002.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: trustedbsd-discuss@trustedbsd.org, freebsd-arch@freebsd.org Subject: Re: New in-kernel privilege API: priv(9) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2006 00:08:58 -0000 --nextPart1696485.Dd1bkIxD5j Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 14 September 2006 23:49, Robert Watson wrote: > On Thu, 14 Sep 2006, Max Laier wrote: > > 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:=20 > > 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. > > I'd like to avoid encoding the behavior of the jail policy into the > privilege mechanism if we can avoid it, or changes in prison policy > won't be properly propagated to binary modules, etc. Imagine for a > moment that the prison_check_priv() function contained none of the > commented out privileges, which will be its final state, and with > comments explaining which particular clusters of privileges are allowed > (and are safe) in Jail. The commented out privileges listed there are > primarily so I can make sure all the privileges are in sync during > development, and not required in the long term. Okay. It just looks strange/scary and I though that a flag would be a=20 good way to solve/work around that. Might be a matter of taste, though. > > 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. > > Just to make sure I understnad what you're describing: you would like a > way to tell the kernel that specific privileges can have a relaxed > policy for granting the privilege? I.e., throwing a global flag that > grants the privilege to arbitrary credentials, rather than just root > credentials? I would like to give additional policy checks (such as MAC) a chance to=20 deny privileges that do not necessarily require root right now, but might=20 be interesting nontheless. In the case of pf you might want to chown /dev/pf to "firewall operator"=20 and be able to enforce this with your policy module additionally. Right=20 now, the only way to restrict/check access to /dev/pf is the filesystem=20 privileges on it + securelevel settings. I'm coming from this very restricted use case, but I though it might be=20 worth noting that there are places where privileges are coming from=20 somewhere else. A privilege policy module might want to have a look=20 still. =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 --nextPart1696485.Dd1bkIxD5j Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFCe8UXyyEoT62BG0RApgQAJ4p1qVaNAOrOcylhEf/GYWwRb6YIwCcCG1y aByQQOSxv+Id/Oc0tBf3OKc= =zSTZ -----END PGP SIGNATURE----- --nextPart1696485.Dd1bkIxD5j--