(2010/07/08 23:58), Stephen Frost wrote:
> * Robert Haas (robertmhaas@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@ak.jp.nec.com>
