This is a discussion on Re: New in-kernel privilege API: priv(9) - FreeBSD ; --nextPart1696485.Dd1bkIxD5j Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 ...
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:=20
> > 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=20
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
I would like to give additional policy checks (such as MAC) a chance to=20
deny privileges that do not necessarily require root right now, but might=20
be interesting nontheless.
In the case of pf you might want to chown /dev/pf to "firewall operator"=20
and be able to enforce this with your policy module additionally. Right=20
now, the only way to restrict/check access to /dev/pf is the filesystem=20
privileges on it + securelevel settings.
I'm coming from this very restricted use case, but I though it might be=20
worth noting that there are places where privileges are coming from=20
somewhere else. A privilege policy module might want to have a look=20
/"\ Best regards, | email@example.com
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
-----END PGP SIGNATURE-----