New in-kernel privilege API: priv(9)

[Max Laier]

On Wednesday 13 September 2006 16:29, Robert Watson wrote:
...
> - It makes it possible to migrate the "allowed in jail" decision from
> the calling context to the privilege management code.  This will allow
> us to gradually eliminate the passing of flags to the privilege check
> code under almost all circumstances.  In my patch, I have added a new
> function to kern_jail.c, prison_priv_check(), which essentially
> contains a switch statement listing the privileges allowed in jail, and
> denying the rest. Configurable privileges, raw socket access, etc, can
> now occur in one place, and open the door to introducing more easy
> per-jail configuration of privilege.  After these changes, the
> implementation is much more centralized in kern_jail.c.
...
> - Privileges under this model are not treated as maskable values.  In
>    practice, there are very few situations in which it is useful to
> check multiple privileges at once, and permitting that encourages
> authors adding new privilege checks to combine privileges in a way that
> makes it opaque to the privilege mechanism as to which privilege was
> actually needed.  This also has the benefit of making it much
> easier/more efficient to add new privileges as required, as it doesn't
> require expanding a bit string representing the privileges.  Most
> POSIX.1e implementations limit the total number of privileges to 32 to
> 64 in order to have them fit in a bitmask easily.

I tried to read with care and understand the reason behind not using 
flags - at least partly.  I didn't find any in your email so:  Wouldn't 
it make sense to mask off at least part of it to encode some general 
decision into the privilege value directly.  A la:

#define ALLOW_IN_JAIL	0x8000000

#define PRIV_KTRACE	(42 | ALLOW_IN_JAIL)

Right now, prison_priv_check() is looking rather scary to me.  If 
something else wants to decide on finer granularity, alright, but in my 
opinion it's easier (more obvious) to keep the "normal" information in 
the .h file where the privileges are defined and described - as we are 
aiming for centralization of the decision and information.  On top of 
that the caller could mask off ALLOW_IN_JAIL if they think it's not 
appropriate in a special use case of the privilege.

On an aside, it would be nice to have "optional" privilege checks i.e. in 
pf we trust the file permissions on /dev/pf (plus securelevel) to decide 
if someone is allowed to fiddle with the firewall.  It would be nice to 
have a way of allowing MAC (or whatever) to decide this - without 
disallowing non-root use as long as the policy doesn't care.  In code 
that would mean a "if (flags & SUSER_OPTIONAL) return (0);" just before 
the "if (suser_enabled) ..."-block.  The policy would have it's go in 
mac_priv_check() above.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20060914/1ade3d61/attachment.pgp