Re: security hook on authorization

(2010/08/20 23:34), Robert Haas wrote:
> 2010/8/19 KaiGai Kohei<kaigai@ak.jp.nec.com>:
>> (2010/08/20 11:45), Robert Haas wrote:
>>> 2010/8/19 KaiGai Kohei<kaigai@ak.jp.nec.com>:
>>>> I also plan to add a security hook on authorization time.
>>>> It shall allow external security providers to set up credential of
>>>> the authenticated clients.
>>>>
>>>> Please note that it is not intended to control authentication process.
>>>> It is typically checked based on a pair of username and password.
>>>> What I want to discuss is things after success of this authentication
>>>> steps.
>>>>
>>>>   From viewpoint of SE-PostgreSQL, it uses getpeercon(3) which obtains
>>>> a security label of the peer process, so it does not need to consider
>>>> database username. But we can easily assume other security mechanism
>>>> which assigns a certain label based on the authenticated database user
>>>> such as Oracle Label Security.
>>>>
>>>> So, I think this hook should be also invoked on the code path of
>>>> SET SESSION AUTHORIZATION, not only database login time, although
>>>> SE-PostgreSQL ignores this case.
>>>>
>>>> So, I think SetSessionUserId() is a candidate to put this hook which is
>>>> entirely called from both of the code path.
>>>> This routine is to assign credential of the default database privilege
>>>> mechanism, so it seems to me it is a good point where external security
>>>> provider also assigns its credential of the authenticated database user.
>>>
>>> How is this different from what we rejected before?
>>>
>> It made clear the purpose of this hook.
>>
>> I also intended to use the previous hook for authorization purpose,
>> but it was deployed just after initialize_acl() without no argument.
>> It might be suitable for SE-PostgreSQL, because it does not depend on
>> authenticated database user, but might be too specific.
>>
>> The new hook shall be invoked on two code paths (database login and
>> SET SESSION AUTHORIZATION). It allows upcoming security module which
>> may assign client's credential based on the database user to utilize
>> this hook also.
>
> I think our standard criteria for the inclusion of hooks is that you
> must demonstrate that the hook can be used to do something interesting
> that couldn't be done without the hook.  So far I'm unconvinced.
>
We cannot handle an error of labeled networking (getpeercon(3)),
if we don't have any hook during client authorization stage.

If and when a connection came from a host but we don't accept the
delivered security label, or labeled networking is misconfigured,
getpeercon(3) returns NULL. In this case, server cannot identify
what label should be applied on the client, then, we should
disconnect this connection due to the error on database login,
not any access control decision.

In similar case, psm_selinux.so disconnect the connection when
it cannot identify what security label shall be assigned on the
session, due to some reasons such as misconfigurations.

Without any hooks at authorization stage (but it might be different
place from this patch, of course), we need to delay the error
handling by the time when SE-PostgreSQL module is invoked at first.
But it is already connection established and user sends a query.
It seems to me quite strange behavior.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>