how to build a kernel with capabilities

[Robert Watson]

On Wed, 21 Sep 2005, [gb2312] ²Ì¼ÎÓ wrote:

> hi, I have downloaded trustedbsd-cap through cvsup, but I found there is 
> no readme tell me how to build a kernel with capabilities. the default 
> conf in sys/i386/conf is GENERIC, and there is no explict options for 
> capabilities
>
> is there any handbook tell me how to do? or you can tell me! I think the 
> conf must add options CAPABILITIES options UFS_EXTATTR options 
> UFS_EXTATTR_AUTOSTART into mykernel config, is it enough?
>
> there are a lot of directories in the cvs tree including the source file 
> in /usr/bin, I checked some of them, but could not find any 
> modification, how to get which files have been modified for capability?
>
> I currently get capability materials just through google search, are 
> there any forums or website I can find more information?

The capabilities branch is currently unsupported, and contains fairly 
complete changes against a pretty old version of FreeBSD.  You should be 
able to compile the options you've indicated above and it should work, 
however.

Our SEBSD development branch contains some of the capabilities changes in 
an updated form -- specifically, it has an updated version of the 
conversion from suser() checks to capabilities checks, in order to support 
the SEBSD policy via the MAC Framework.  However, it does not contain the 
capability logic itself, nor the user space modifications to support 
capabilities.

While capabilities are of general interest in the TrustedBSD Project, I've 
not managed to convince myself that the model described in POSIX.1e is 
particularly safe -- i.e., it has a complex, and hence error prone, 
algorithm, and many UNIX applications dealing with privilege behave poorly 
in the presence of capabilities.  For example, even though Linux contained 
only a subset of the POSIX.1e capabilities support, it suffered a rather 
nasety security hole a few years ago relating to sendmail and 
capabilities.  This was arguably a bug in Sendmail, but the circumstances 
the bug was exposed in were one of a modified security model that hadn't 
been entirely implemented.  The security benefits of finer grained 
privilege are clear, but until enough work has been invested in making 
sure the result is actually better than where we start, it's not something 
that will be merged into FreeBSD.

If you're interested in working on updating the capabilities work to a 
recent FreeBSD release, we'd be very interested in helping out though :-). 
I'd start by grabbing the SEBSD branch and merging kern_cap.c, 
capability.h, and the user space changes forward, and see where things 
get.

Robert N M Watson