Re: security hook on authorization

On Wed, Oct 13, 2010 at 2:13 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 2010/8/24 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> 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.
>
> Stephen -
>
> You've been listed as a reviewer for this in the CF app since 9/17 -
> are you planning to review it?

I guess not.

I took a brief look at this tonight, and it seems to me that it still
fails the test I proposed nearly two months ago:

http://archives.postgresql.org/pgsql-hackers/2010-08/msg01458.php

KaiGai responded with:

> 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.

I don't find this very convincing. We are still several patches from
having a working SE-PostgreSQL module, and I think we should be
worried about getting off the ground before we worry about this sort
of fine-tuning. I don't see reporting an SE-PostgreSQL error slightly
sooner is worth a separate hook, especially given that we're still
several patches from having even a toy SE-PostgreSQL implementation.
For example, we may find that some other hook that is more certainly
necessary can also serve the purpose intended for this one.

And later with:

> 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.

This is closer to the mark, but mostly speculative, and not detailed
enough to determine whether the proposed hook is properly located. It
seems rather early to me: this is before we've sent the authentication
packet to the client, so we couldn't, for example, log the success or
failure of the authentication; we don't know whether it will succeed
or fail.

I am going to mark this Returned with Feedback. I would like to
request that any future submissions to add a hook in this area be
accompanied by a working sample contrib module that is not SE-Linux
specific.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company