From owner-trustedbsd-discuss@FreeBSD.ORG Wed Sep 13 20:28:30 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 3B3CC16A403; Wed, 13 Sep 2006 20:28:30 +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 4DC1543D55; Wed, 13 Sep 2006 20:28:29 +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 B7AD946C08; Wed, 13 Sep 2006 16:28:24 -0400 (EDT) Date: Wed, 13 Sep 2006 21:28:24 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ceri Davies In-Reply-To: <20060913184115.GE93949@submonkey.net> Message-ID: <20060913194559.U53301@fledge.watson.org> References: <20060913150912.J1823@fledge.watson.org> <20060913184115.GE93949@submonkey.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org 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: Wed, 13 Sep 2006 20:28:30 -0000 On Wed, 13 Sep 2006, Ceri Davies wrote: > On Wed, Sep 13, 2006 at 03:29:14PM +0100, Robert Watson wrote: > >> What does this all mean in practice? It means replacing suser(9) and >> suser_cred(9) with calls that express the specific privilege being checked >> for. I took the most straight forward possible implementation: I reviewed >> all privilege checks in the kernel, identified all identical privileges and >> categorized all privileges by subsystem. I then assigned unique numeric >> constants to each unique privilege, and added a privilege identifier >> argument to the two new functions, priv_check(9) and priv_check_cred(9). > > Is this wilfully different from the privileges(5) model in Solaris 10 > (http://docs.sun.com/app/docs/doc/816-5175/6mbba7f3b?a=view) ? > > It seems that there would be some benefit in having at least a minimal > common API and set of privilege names, not least to help with issues such as > that raised in http://issues.apache.org/bugzilla/show_bug.cgi?id=34671. > > Having only just started to look over your work, I'll be happy to be put > straight if we're talking about completely different things, but on the > surface they're looking very similar. A couple of points: First, the system present in Solaris is, in effect, a variant of some draft of POSIX.1e (or possibly vice versa), albeit with differently named constants. All the comments I made regarding POSIX.1e apply to it. Specifically, the priv(9) kernel API offers much more fine-grained assignment of rights relating to system administration, etc, corresponding specifically to the set of privileges defined in our kernel. Second, privileges(5) describes an alternative privilege model exposed to userspace, whereas the work I've described is an in-kernel API for privilege checking. It doesn't imply (or, for that matter, implement) a change in the OS privilege model, although clearly it would facilitate doing that in the future. Since priv(9) is not an application API, it's not clear that application portability is an immediate concern. FYI, we have previously implemented POSIX.1e capabilities (privileges) on FreeBSD as part of the TrustedBSD work, and rejected it for inclusion based on a number of criteria. The most important were: - The risk associated with changing the OS privilege model -- notice that the inheritence/effective/permitted behavior of POSIX.1e is quite complex, not to mention the application compatibility risks (recall the Linux sendmail problem a few years ago). - The lack of granularity is a significant problem for most implementations of POSIX.1e. The base set of privileges is fairly carefully designed to match the instances of privilege in POSIX, and so does fairly well, all systems require extensions to the basic POSIX set (as they all extend POSIX), and the common extensions are generally not fine-grained at all. Witness CAP_SYS_ADMIN on Linux, which is a catch-all for may different privileges. I selected the PRIV_ privilege names in order to avoid conflicting with the POSIX.1e CAP_ naming scheme, so that if that scheme is implemented as a wrapper to the underling priv(9) privilege API in the kernel, there won't be problems. Avoiding conflicts with the Solaris scheme would be useful, but is more tricky (possibly because it is more sensible :-). I think it's useful to compare the Solaris privilege set, and also consider whether in the future we want to adopt a privilege model along similar lines. However, given that the privilege models across various UNIX and non-UNIX systems are all similar and yet completely different, I'm not sure that being similar and yet different from Solaris is particularly a problem -- more, say, than being similar but different from IRIX, Linux, Windows, etc. Robert N M Watson Computer Laboratory University of Cambridge