In article <[email protected]>, Elad Efrat <[email protected]> wrote: >-=-=-=-=-=- > >Hi, > >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. :) > >Thanks, > >-e. > > >- break; >+ unpriv = kauth_authorize_generic(so->so_cred, KAUTH_GENERIC_ISSUSER, >NULL);
... >+ unpriv = kauth_authorize_generic(so->so_cred, >+ KAUTH_GENERIC_ISSUSER, NULL); Why two calls to kauth_authorize_generic? christos
