Prev: debug log in pg_archivecleanup
Next: Add a new backend process
From: KaiGai Kohei on 16 Jun 2010 00:54
(2010/06/15 21:37), Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kaigai(a)ak.jp.nec.com) wrote:
>> In the attached patch, the security hook was moved to ClientAuthentication()
>> from InitPostgres(), for more clarification of the purpose.
>> What I want to do is to assign additional properties to identify the client
>> (such as security label) for each authenticated session.
>>
>> Its purpose is similar to "session" module of PAM in operating system.
>> It allows to assign additional session properties more than user-id.
>
> That's all fine- but let's work within the confines of the *existing*
> hook that's been discussed to get something working first before we go
> adding hooks in other places. I think it's important that we put
> together at least a proof of concept that an SELinux module or other
> external auth module can sensible use the DML hook.
>
Yes, I'd like to introduce the reason and purpose of the hook.

At first, please assume any external security modules should be loaded
as shared preload libraries, because 'local_preload_libraries' setting
can be overwritten using connection string.
So, _PG_init() shall be invoked at the starting-up of the postmaster
daemon process at once, not per connection.

On the other hand, a security feature have to identify the client and
assign an appropriate set of privileges on the session prior to it being
available for users.
E,g. The default PG security assigns a certain database user-id on
the current session, then it will be used for access control decision.
In a similar way, an external security also wants a chance to identify,
authenticate and authorize the client. (SELinux uses getpeercon() to
obtain security label of the peer process, and applies it as privilege
of the current session.)

However, here is no hooks available for the purpose. In this case,
_PG_init() is not called for each connections, because the module is
a shared preload library, so we have to call getpeercon() in another
point.

One idea is, as Robert suggested, that we can invoke getpeercon() at
the first call of SELinux module and store it on the local variable.
It will work well as long as getpeercon() does not cause an error.

Robert pointed out we can always raise ERROR or FATAL using ereport(),
if it is troubled.
However, it seems to me a trouble of getpeercon() is fundamentally
an error within the step of client authentication.
In the case of database user-id, it immediately raises an error, and
close the connection. I think we should follow the manner of similar
features, so I proposed the new security hook at the authentication.

Thanks,

> After that, we can discuss what other hooks are needed. KaiGai, please,
> before sending in patches of any kind, propose at a high-level what the
> problem is and what the security module needs in general terms. If you
> have a recommendation, that's fine, but let's talk about it before
> implementing anything.
>
> Thanks,
>
> Stephen


--
KaiGai Kohei <kaigai(a)ak.jp.nec.com>

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: KaiGai Kohei on 16 Jun 2010 19:33
(2010/06/16 21:37), Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kaigai(a)ak.jp.nec.com) wrote:
>> On the other hand, a security feature have to identify the client and
>> assign an appropriate set of privileges on the session prior to it being
>> available for users.
> [...]
>> However, here is no hooks available for the purpose.
>
> I believe we understand the issue now, my point was that in the future
> let's have this discussion first.
>
>> One idea is, as Robert suggested, that we can invoke getpeercon() at
>> the first call of SELinux module and store it on the local variable.
>> It will work well as long as getpeercon() does not cause an error.
>
> Let's work with this approach to build a proof-of-concept that at least
> the DML hook will work as advertised. We've got alot of time till 9.1
> and I think that if we can show that a module exists that implements
> SELinux using the DML hook, and that a few other hooks are needed to
> address short-comings in that module, adding them won't be a huge issue.
>
OK, fair enough. Please wait for a few days.
I'll introduce the proof-of-concept module until this week.

Thanks,
--
KaiGai Kohei <kaigai(a)ak.jp.nec.com>

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: KaiGai Kohei on 8 Jul 2010 20:20
(2010/07/08 23:58), Stephen Frost wrote:
> * Robert Haas (robertmhaas(a)gmail.com) wrote:
>> I'm not sure what the best thing to do about this is. I think it
>> might be a good idea to start with some discussion of what problems
>> people are trying to solve (hopefully N> 1?) and then try to figure
>> out what a good solution might look like.
>
> Guess my first thought was that you'd have a database-level label that
> would be used by SELinux to validate a connection. A second thought is
> labels for roles. KaiGai, can you provide your thoughts on this
> discussion/approach/problems? I realize it's come a bit far-afield from
> your original proposal.
>

Let's sort out the point at issues from perspective of the models.

Please remind the authentication (in broad-sense) is consist of a few steps.

1) Identification
In this step, system tries to obtain the identifier of client.
Typically, it is a username provided using connection string in pgsql.

2) Authentication (in narrow-sense)
In this step, system tries to verify whether the given identifier is
correct, or not. Typically, it checks the password corresponding to
the user.

3) Authorization
In this step, system tries to assign a set of privileges on the new
session. Typically, it is user identifier itself, because DAC makes
access control decision based on the combination of user identifier
and access control list of the objects.
But all the security modules also intend to utilize the user identifier
for its own access control decision. E.g, SELinux uses a security label
of the client process. If we would have something like Oracle Label
Security, client's label may be associated with a certain database role
that is already authorized.


The purpose of my patch was to provide an external security provider
a chance to (3) authorize the new session based on or not-based on
the (1) identification and (2) authentication.

If we try to allow security providers to get control all of the 1-3,
it might be hard to find the best place to put the hook right now.
But, at least, SELinux does not have a plan to interpose identification
and authentication. All I want to do here is to authorize the client
just after authentication process.

I'd like to suggest that we focus on the (3) authorization process
for functionality of the patch. It may be also worth to control
identification and authentication using security provider, but we don't
have actual guest module right now.

Thanks,
--
KaiGai Kohei <kaigai(a)ak.jp.nec.com>

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: KaiGai Kohei on 12 Jul 2010 00:58
(2010/07/09 23:52), Stephen Frost wrote:
> * Stephen Frost (sfrost(a)snowman.net) wrote:
>> Guess my first thought was that you'd have a database-level label that
>> would be used by SELinux to validate a connection. A second thought is
>> labels for roles. KaiGai, can you provide your thoughts on this
>> discussion/approach/problems? I realize it's come a bit far-afield from
>> your original proposal.
>
> Something else which has come up but is related is the ability to
> support a "pam_tally"-like function in PG. Basically, the ability to
> lock users out if they've had too many failed login attempts. I wonder
> if we could add this hook (or maybe have more than one if necessary) in
> a way to support a contrib module for that.
>
It seems to me a good idea.

BTW, where do you intend to apply this "pam_tally" like functionality?
If it tries to lock users out on the identification stage; like the
pam_tally.so on operating systems, the hook should be placed on the
top-half of ClientAuthentication().

On the other hand, when we tries to set up properties of a certain user's
session, it needs to be placed on the authorization stage.
In the PG code, InitializeSessionUserId() just performs the role to assign
the authenticated user's identifier on the current session. It seems to me
it is a candidate where we put a hook on the authorization stage.

Of course, these are not exclusive. We can provide two hooks to provide
a chance to get control on identification and authorization stages.

Thanks,
--
KaiGai Kohei <kaigai(a)ak.jp.nec.com>

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: debug log in pg_archivecleanup
Next: Add a new backend process