New in-kernel privilege API: priv(9)

[Robert Watson]

On Wed, 13 Sep 2006, Ceri Davies wrote:

> On Wed, Sep 13, 2006 at 03:29:14PM +0100, Robert Watson wrote:
>
>> What does this all mean in practice?  It means replacing suser(9) and 
>> suser_cred(9) with calls that express the specific privilege being checked 
>> for.  I took the most straight forward possible implementation: I reviewed 
>> all privilege checks in the kernel, identified all identical privileges and 
>> categorized all privileges by subsystem.  I then assigned unique numeric 
>> constants to each unique privilege, and added a privilege identifier 
>> argument to the two new functions, priv_check(9) and priv_check_cred(9).
>
> Is this wilfully different from the privileges(5) model in Solaris 10 
> (http://docs.sun.com/app/docs/doc/816-5175/6mbba7f3b?a=view) ?
>
> It seems that there would be some benefit in having at least a minimal 
> common API and set of privilege names, not least to help with issues such as 
> that raised in http://issues.apache.org/bugzilla/show_bug.cgi?id=34671.
>
> Having only just started to look over your work, I'll be happy to be put 
> straight if we're talking about completely different things, but on the 
> surface they're looking very similar.

A couple of points:

First, the system present in Solaris is, in effect, a variant of some draft of 
POSIX.1e (or possibly vice versa), albeit with differently named constants. 
All the comments I made regarding POSIX.1e apply to it.  Specifically, the 
priv(9) kernel API offers much more fine-grained assignment of rights relating 
to system administration, etc, corresponding specifically to the set of 
privileges defined in our kernel.

Second, privileges(5) describes an alternative privilege model exposed to 
userspace, whereas the work I've described is an in-kernel API for privilege 
checking.  It doesn't imply (or, for that matter, implement) a change in the 
OS privilege model, although clearly it would facilitate doing that in the 
future.  Since priv(9) is not an application API, it's not clear that 
application portability is an immediate concern.

FYI, we have previously implemented POSIX.1e capabilities (privileges) on 
FreeBSD as part of the TrustedBSD work, and rejected it for inclusion based on 
a number of criteria.  The most important were:

- The risk associated with changing the OS privilege model -- notice that the
   inheritence/effective/permitted behavior of POSIX.1e is quite complex, not
   to mention the application compatibility risks (recall the Linux sendmail
   problem a few years ago).

- The lack of granularity is a significant problem for most implementations of
   POSIX.1e.  The base set of privileges is fairly carefully designed to match
   the instances of privilege in POSIX, and so does fairly well, all systems
   require extensions to the basic POSIX set (as they all extend POSIX), and
   the common extensions are generally not fine-grained at all.  Witness
   CAP_SYS_ADMIN on Linux, which is a catch-all for may different privileges.

I selected the PRIV_ privilege names in order to avoid conflicting with the 
POSIX.1e CAP_ naming scheme, so that if that scheme is implemented as a 
wrapper to the underling priv(9) privilege API in the kernel, there won't be 
problems.  Avoiding conflicts with the Solaris scheme would be useful, but is 
more tricky (possibly because it is more sensible :-).

I think it's useful to compare the Solaris privilege set, and also consider 
whether in the future we want to adopt a privilege model along similar lines. 
However, given that the privilege models across various UNIX and non-UNIX 
systems are all similar and yet completely different, I'm not sure that being 
similar and yet different from Solaris is particularly a problem -- more, say, 
than being similar but different from IRIX, Linux, Windows, etc.

Robert N M Watson
Computer Laboratory
University of Cambridge