New in-kernel privilege API: priv(9)

[Max Laier]

On Thursday 14 September 2006 23:49, Robert Watson wrote:
> On Thu, 14 Sep 2006, Max Laier wrote:
> > 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.
>
> I'd like to avoid encoding the behavior of the jail policy into the
> privilege mechanism if we can avoid it, or changes in prison policy
> won't be properly propagated to binary modules, etc.  Imagine for a
> moment that the prison_check_priv() function contained none of the
> commented out privileges, which will be its final state, and with
> comments explaining which particular clusters of privileges are allowed
> (and are safe) in Jail.  The commented out privileges listed there are
> primarily so I can make sure all the privileges are in sync during
> development, and not required in the long term.

Okay.  It just looks strange/scary and I though that a flag would be a 
good way to solve/work around that.  Might be a matter of taste, though.

> > 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.
>
> Just to make sure I understnad what you're describing: you would like a
> way to tell the kernel that specific privileges can have a relaxed
> policy for granting the privilege?  I.e., throwing a global flag that
> grants the privilege to arbitrary credentials, rather than just root
> credentials?

I would like to give additional policy checks (such as MAC) a chance to 
deny privileges that do not necessarily require root right now, but might 
be interesting nontheless.

In the case of pf you might want to chown /dev/pf to "firewall operator" 
and be able to enforce this with your policy module additionally.  Right 
now, the only way to restrict/check access to /dev/pf is the filesystem 
privileges on it + securelevel settings.

I'm coming from this very restricted use case, but I though it might be 
worth noting that there are places where privileges are coming from 
somewhere else.  A privilege policy module might want to have a look 
still.

-- 
/"\  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/20060915/9c72a0e0/attachment.pgp