New in-kernel privilege API: priv(9)

Robert Watson rwatson at FreeBSD.org
Thu Sep 14 14:53:41 PDT 2006


On Thu, 14 Sep 2006, Alexander Leidinger wrote:

> Quoting Robert Watson <rwatson at FreeBSD.org> (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


More information about the trustedbsd-discuss mailing list