Re: security hook on authorization

I tried to revise the patch. It allows plugins to get control next to
client authentication, but before returning the status to users.

This change enables plugins which should be invoked on authentication
failed to utilize this hook, not only assignment of session security
label.
At the same time, it disables to hook on SET SESSION AUTHORIZATION.
But it is a bit unclear whether we should hook here, or not.

(2010/08/24 14:19), KaiGai Kohei wrote:
> (2010/08/22 21:38), KaiGai Kohei wrote:
>> (2010/08/22 0:20), Robert Haas wrote:
>>> On Aug 20, 2010, at 8:27 PM, KaiGai Kohei<kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>>>> (2010/08/20 23:34), Robert Haas wrote:
>>>>> 2010/8/19 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>>>> 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.
>>>
>>> You mentioned that before. I'm not totally sure I buy it, and I think
>>> there are other applications that might benefit from a hook in this area.
>>> We need to think about trying to do this in a way that is as general as
>>> possible. So I'd like to see some analysis of other possible
>>> applications.
>>>
>> Yes, I also think this kind of authorization hook should benefit other
>> applications, not only label based mac features.
>>
>> For example, something like 'last' command in operations system which
>> records username and login-time. Stephen mentioned pam_tally that locks
>> down certain accounts who failed authentication too much.
>> Perhaps, PAM modules in operating system give us some hints about other
>> possible applications.
>>
>
> I've checked some documentation files of pam modules in operating system
> to think about other possible applications.
>
> * pam_env.so
> It allows to set/unset environment variables, perhaps, per users.
> In PG, we may be able to assume a module which set/unset guc variables
> depending on authenticated user?
>
> * pam_faildelay.so
> It enables to delay to disconnect when authentication was failed.
> It prevents brute-force attack on passwords.
>
> * pam_lastlog.so
> It enables to display a line of information about the last login of
> the user. In addition, the module maintains the /var/log/lastlog file.
>
> * pam_selinux.so
> It sets up the default security context for the next execed shell.
> It is equivalent to set up a set of privileges of the authenticated
> user.
>
> * pam_tally.so
> It maintains a count of attempted accesses, can reset count on success,
> can deny access if too many attempts fail.
>
>
> If and when we try to provide something similar features of them,
> the pam_env.so, pam_lastlog.so and pam_selinux.so need to be called
> on the code path of authentication succeeded only.
> But the pam_faildelay.so needs to be called on authentication failed
> path, and the pam_tally.so needs to be called on both paths because
> it maintain a count of authentication failed and locks down certain
> user accounts which failed too many.
>
> In the current patch, I put the authorization hook on SetSessionUserId()
> but it is only called when authentication succeeded path.
>
> Here is only one place where we can put the authorization hook where
> is called on both of authentication succeeded and failed.
>
> The ClientAuthentication() has a big switch statement which branches
> to each authentication methods, then status will be updated to
> STATUS_OK or others.
> How about the security hook just after the big switch statement but
> before sending a response to the client, as follows?
> ----------------
> void
> ClientAuthentication(Port *port)
> {
> int status = STATUS_ERROR;
> :
> /*
> * Now proceed to do the actual authentication check
> */
> switch (port->hba->auth_method)
> {
> case uaReject:
> :
> }
>
> + if (ClientAuthenticationHook)
> + status = (*ClientAuthenticationHook)(port, status);
>
> if (status == STATUS_OK)
> sendAuthRequest(port, AUTH_REQ_OK);
> else
> auth_failed(port, status);
>
> /* Done with authentication, so we should turn off immediate interrupts */
> ImmediateInterruptOK = false;
> }
> ----------------
>
> Thanks,

--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>