tech-kern archive

[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 <>, Elad Efrat  
<> wrote:
>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
>vice versa.)
>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. :)
>-                      break;
>+      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?


Home | Main Index | Thread Index | Old Index