From owner-trustedbsd-discuss@FreeBSD.ORG Fri Apr 28 13:22:36 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 4C5D516A417 for ; Fri, 28 Apr 2006 13:22:36 +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 B11CC43D48 for ; Fri, 28 Apr 2006 13:22:35 +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 54D8646C72; Fri, 28 Apr 2006 09:22:35 -0400 (EDT) Date: Fri, 28 Apr 2006 14:22:35 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Viktor Kallinikov In-Reply-To: <7a8ada600604251707s59e94bffp8fbdf27d4834a6e4@mail.gmail.com> Message-ID: <20060428141810.Y40418@fledge.watson.org> References: <7a8ada600604251707s59e94bffp8fbdf27d4834a6e4@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: trustedbsd-discuss@freebsd.org Subject: Re: POSIX capabilities 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: Fri, 28 Apr 2006 13:22:36 -0000 On Wed, 26 Apr 2006, Viktor Kallinikov wrote: > How to enable POSIX capabilities in kernel ? Right now, POSIX.1e capabilities aren't merged into the base FreeBSD source tree. There are actually two sets of outstanding changes relating to this: (1) The TrustedBSD capabilities development tree, trustedbsd_cap, which was created several years ago and is based on a version of FreeBSD 5.x. This contains a relatively complete implementation of POSIX.1e capabilities (privileges), including support for marking binaries as granting privileges, etc. (2) In the TrustedBSD SEBSD branch, there are changes to the MAC Framework to allow MAC policy modules to restrict access to specific POSIX.1e capabilities (privileges); this allows policy modules to (at a broad level) control privilege in the system, but doesn't permit granting of privilege (currently). The reason we deferred further work on the implementation of (1) is that it had reached the point where we had to make an integration decision, and we did not convince ourselves that the benefits of the implementation outweighed the risks of modifying the OS privilege model. The subset approach being adopted in (2) paves the way for allowing the privilege model to be plugged in without a whole-sale adaptation of the remainder of the OS, and is probably the better way to go. At the upcoming FreeBSD developer summit, a discussion of privilege APIs in the kernel is on the table, and will probably result in the adoption of a replacement for suser(). The main problem with cap_check() as a replacement for suser is that it fails to offer much more useful granularity for many of the most important privileges in the OS. My current thinking is that we'll end up with a couple of different privilege APIs that offer greater granularity in various subsystems, which can then be plugged using the MAC Framework (or something along those lines). Robert N M Watson