Re: [v9.2] Add GUC sepgsql.client_label

2012/3/12 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Mon, Mar 12, 2012 at 11:13 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> 2012/3/12 Robert Haas <robertmhaas(at)gmail(dot)com>:
>>> On Mon, Mar 12, 2012 at 10:58 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>>>> It is a practical reason. In case when httpd open the connection to PG and
>>>> set a suitable security label according to the given credential prior to launch
>>>> of user application, then keep this connection for upcoming request, it is
>>>> worthwhile to reset security label of the client.
>>>
>>> But wait a minute - how is that any good?  That allows the client to
>>> pretty trivially circumvent the security restriction that we were
>>> trying to impose by doing sepgsql_setcon() in the first place.  It
>>> doesn't matter how convenient it is if it's flagrantly insecure.
>>>
>>> Am I missing something here?
>>>
>> It is a practical reason. If we would not support the reset feature,
>> the application has to know the security label of itself, as a target
>> label to be reverted. However, I'm not certain the status of script-
>> language binding of libselinux feature to obtain the self label,
>> although it is supported on Perl, Ruby and PHP (with extension
>> by myself) at least.
>
> You're still missing my point.  The issue isn't the particular choice
> of mechanism for reverting to the original security label; it's the
> fact that such a thing would be possible at all.
>
> Suppose that the connection starts out in context connection_pooler_t.
>  Based on the identity of the user, we transition to foo_t, bar_t, or
> baz_t.  If it's possible, by any method, for one of those contexts to
> get back to connection_pooler_t, then we've got a problem.  We give a
> connection to user foo which is in foo_t; he transitions it back to
> connection_pooler_t, then to bar_t, and usurps user bar's privileges.
> Unless there's some way to prevent that, the only way to make this
> secure is to make the transition to foo_t irreversible.
>
It is the reason why I advocate the idea to allow sepgsql_setcon()
inside of trusted-procedures.

The original use-case of Joshua does not allow connection_pooler_t
to execute any SQL commands except for invocation of a particular
trusted-procedures; that takes a secret credential as an argument,
then it switches the client label to foo_t, bar_t or baz_t according to
the supplied credential.
These labels are allowed to switch back to the original
connection_pooler_t, but it is unavailable to switch arbitrary label
without suitable credential.

Please also note that the reset of security label is handled as
a switch from the current one to the original one; that takes
permission check as normal manner.
So, it is an option to prevent to reset the client label to the original
one; that is allowed to switch arbitrary label, in an environment
without connection pooling.

Do we still have problematic scenario here?

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>