From owner-freebsd-arch@FreeBSD.ORG Thu Sep 14 21:49:24 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 41C0916A492; Thu, 14 Sep 2006 21:49:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A440643D49; Thu, 14 Sep 2006 21:49:21 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E9CA946BE2; Thu, 14 Sep 2006 17:49:19 -0400 (EDT) Date: Thu, 14 Sep 2006 22:49:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Max Laier In-Reply-To: <200609140253.06818.max@love2party.net> Message-ID: <20060914224516.G53301@fledge.watson.org> References: <20060913150912.J1823@fledge.watson.org> <200609140253.06818.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Thu, 14 Sep 2006 21:49:24 -0000 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: 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. > 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? Robert N M Watson Computer Laboratory University of Cambridge