(2010/08/20 23:34), Robert Haas wrote:
2010/8/19 KaiGai Kohei<kai...@ak.jp.nec.com>:
(2010/08/20 11:45), Robert Haas wrote:
2010/8/19 KaiGai Kohei<kai...@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 <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
