[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: IPSEC (both stacks) slight adaptation to kauth(9)
In article <4B3C2C8E.7010706%NetBSD.org@localhost>, Elad Efrat
>Our IPSEC stacks both have a SP PCB structure with a 'priv' field,
>indicating whether this SP is "privileged" or not. The SP, which is
>attached to a socket, gets this value set by by querying the socket's
>uid, from the uidinfo field in the socket. In turn, the 'priv' field
>is used in authorization. (If the uid is zero, it's privileged, and
>This of course doesn't fit with our transition to centralized
>authorization and support for changing security policy (e.g. a MAC
>policy that changed will not have any effect if the authorization is
>done internally against a cached decision.)
>The attached diff addresses this last abuse for uidinfo for
>authorization by doing the following:
> 1. Reorganize the switch statements so they are easier to understand.
> They differ only slightly, and as the networking stacks have enough
> duplicated code as it is, this is a step in the right direction if
> we are to eventually clean them up.
> 2. Remove the 'priv' field of the SP PCB structures from both IPSEC
> and FAST_IPSEC. Isolate it to the relevant context, and retrieve
> its value in runtime and don't cache it.
> 3. Replace uid comparison for privileged/unprivileged distinction with
> kauth(9) calls. For now, these are done on the generic scope as I
> have other changes in the pipe; once committed, these will be
> changed to use the network scope.
>Please review. :)
>+ unpriv = kauth_authorize_generic(so->so_cred, KAUTH_GENERIC_ISSUSER,
>+ unpriv = kauth_authorize_generic(so->so_cred,
>+ KAUTH_GENERIC_ISSUSER, NULL);
Why two calls to kauth_authorize_generic?
Main Index |
Thread Index |