Date: Fri, 15 Sep 2006 02:08:45 +0200 From: Max Laier <max@love2party.net> To: Robert Watson <rwatson@freebsd.org> Cc: trustedbsd-discuss@trustedbsd.org, freebsd-arch@freebsd.org Subject: Re: New in-kernel privilege API: priv(9) Message-ID: <200609150208.53002.max@love2party.net> In-Reply-To: <20060914224516.G53301@fledge.watson.org> References: <20060913150912.J1823@fledge.watson.org> <200609140253.06818.max@love2party.net> <20060914224516.G53301@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 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 > credentials? 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 still. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1696485.Dd1bkIxD5j Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFCe8UXyyEoT62BG0RApgQAJ4p1qVaNAOrOcylhEf/GYWwRb6YIwCcCG1y aByQQOSxv+Id/Oc0tBf3OKc= =zSTZ -----END PGP SIGNATURE----- --nextPart1696485.Dd1bkIxD5j--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200609150208.53002.max>