From owner-trustedbsd-discuss@FreeBSD.ORG Thu Sep 14 21:53:41 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 6CF6216A407; Thu, 14 Sep 2006 21:53:41 +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 0DFBE43D46; Thu, 14 Sep 2006 21:53:41 +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 55E7546BE2; Thu, 14 Sep 2006 17:53:40 -0400 (EDT) Date: Thu, 14 Sep 2006 22:53:40 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Leidinger In-Reply-To: <20060914081703.umum0k4x3k88k4ko@webmail.leidinger.net> Message-ID: <20060914224925.W53301@fledge.watson.org> References: <20060913150912.J1823@fledge.watson.org> <20060914081703.umum0k4x3k88k4ko@webmail.leidinger.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: Thu, 14 Sep 2006 21:53:41 -0000 On Thu, 14 Sep 2006, Alexander Leidinger wrote: > Quoting Robert Watson (from Wed, 13 Sep 2006 15:29:14 > +0100 (BST)): > >> privilege list in src/sys/priv.h: > >> ... >> PRIV_UFS_SETQUOTA, /* setquota(). */ >> PRIV_UFS_SETUSE, /* setuse(). */ >> PRIV_UFS_EXCEEDQUOTA, /* Exempt from quota restrictions. */ > > Is this something special to UFS, or did you use the UFS part only because > no other filesystem in the tree has support for quotas? They were labeled as UFS because they are currently somewhat UFS-specific, but you're right: it might well make sense to rename them to VFS as other file systems may gain support in the future. I'll make this change in P4. >> It is my intent, following review, discussion, cleanup, etc, to commit the >> priv(9) work, sans mac_privs, to the 7.x tree in the next couple of weeks. >> The mac_privs policy is a sample policy that will continue to be maintained >> as part of the TrustedBSD Project, but not merged into the base tree at >> this point. > > Is the mac_privs policy just a proof of concept? It would be nice to allow > more fine grained access to some users or applications. The later one would > need some way to identify the application/binary in a safe way, maybe by > using extended attributes in the FS. Yes, I consider it a proof of concept. Per my comments in a previous e-mail, I'm hesitant to rush into a modified privilege policy that either restricts the root user, or grants privileges to other processes, without a lot of careful thinking. The POSIX.1e-like privilege models used in many operating systems contain many subtleties, and in prior work on FreeBSD to experiment with those models, it was clear the level of risk in such a change was high. You can see some of this complexity by looking at the inheritence/etc logic in the linux POSIX.1e code, the Solaris privileges(5) man page, or the POSIX.1e draft specs. A lot of the complexity comes out of the binding of privileges to files (similar to setuid) and the details of the inheritence and compatibility support for "unaware" applications. If you take a glance at the trustedbsd_cap branch, you can find an implementation of POSIX.1e capabilities on FreeBSD from several years ago. I'm not opposed to revisiting this general issue, and in fact, the priv(9) work is intended to facilitate exactly that sort of work, but we need to do it very carefully. Robert N M Watson Computer Laboratory University of Cambridge