This is a discussion on Re: New in-kernel privilege API: priv(9) - FreeBSD ; 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 > ...
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.
> 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?
Robert N M Watson
University of Cambridge
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"