Re: New in-kernel privilege API: priv(9)
- From: Max Laier <max@xxxxxxxxxxxxxx>
- Date: Thu, 14 Sep 2006 02:52:58 +0200
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@xxxxxxxxxxx
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Attachment:
pgpRgzNo7cgdp.pgp
Description: PGP signature
- Follow-Ups:
- Re: New in-kernel privilege API: priv(9)
- From: Robert Watson
- Re: New in-kernel privilege API: priv(9)
- From: Robert Watson
- Re: New in-kernel privilege API: priv(9)
- References:
- New in-kernel privilege API: priv(9)
- From: Robert Watson
- New in-kernel privilege API: priv(9)
- Prev by Date: Re: New in-kernel privilege API: priv(9)
- Next by Date: Re: New in-kernel privilege API: priv(9)
- Previous by thread: Re: New in-kernel privilege API: priv(9)
- Next by thread: Re: New in-kernel privilege API: priv(9)
- Index(es):
Relevant Pages
|
|
