Date: Fri, 28 Apr 2006 14:22:35 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Viktor Kallinikov <viktorkallinikov@googlemail.com> Cc: trustedbsd-discuss@freebsd.org Subject: Re: POSIX capabilities Message-ID: <20060428141810.Y40418@fledge.watson.org> In-Reply-To: <7a8ada600604251707s59e94bffp8fbdf27d4834a6e4@mail.gmail.com> References: <7a8ada600604251707s59e94bffp8fbdf27d4834a6e4@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060428141810.Y40418>