Re: [v9.2] Add GUC sepgsql.client_label - Mailing list pgsql-hackers

2012/3/13 Kohei KaiGai <kaigai@kaigai.gr.jp>:
> 2012/3/12 Robert Haas <robertmhaas@gmail.com>:
>> On Mon, Mar 12, 2012 at 12:30 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>>>> 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.
>>
>> Oh, I get it.
>>
>> Given that that's the intended use case, the current design does make
>> sense, but it seems awfully special-purpose.  Not knowing that this is
>> what you had in mind, I never would have guessed the reason for all
>> this complexity.  I worry that this is too much of a purpose-built
>> mechanism, and that nobody will ever be able to use it for much of
>> anything beyond the extremely specific use case that you've laid out
>> here.  I think that, at the very least, the comments and documentation
>> need to make it clear that this is very deliberately intended to
>> modify only the toplevel security context of the session, which may be
>> different from the currently active context if a TP is in use; and
>> also that the change will apply to future transactions only if the
>> current transaction commits.
>>
> OK, I try to update the documentation and test cases with related
> security policy, rather than the code base itself.
>
The attached patch contains the documentation updates and test
cases that simulate a typical behavior of connection pooling
software.

In this test case, sepgsql_regtest_pool_t is only allowed to translate
to sepgsql_regtest_(foo|var)_t via trusted procedure, and these
domains are unavailable to reference the tables related to other
domains. It is according to the original explanation I got from Joshua
Brindle. In actual cases, the trusted procedure will take an argument
of the credential being stored within CAC card.

I didn't touch the code portion from the previous version.

If it is ready to commit, please remember the credit to Yeb's volunteer
on this patch.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>