From: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Yeb Havinga <yebhavinga(at)gmail(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org>, Joshua Brindle <jbrindle(at)tresys(dot)com> |
Subject: | Re: [v9.2] Add GUC sepgsql.client_label |
Date: | 2012-03-14 15:10:39 |
Message-ID: | CADyhKSVr2iRKXnYY0xnx-MerJLjpPhRt7z6sT-nwF+TqwWqU4Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2012/3/13 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>:
> 2012/3/12 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Mon, Mar 12, 2012 at 12:30 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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(at)kaigai(dot)gr(dot)jp>
Attachment | Content-Type | Size |
---|---|---|
pgsql-v9.2-sepgsql-setcon.part2-v6.patch | application/octet-stream | 39.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-03-14 15:20:53 | Re: CREATE FOREGIN TABLE LACUNA |
Previous Message | Tom Lane | 2012-03-14 15:02:24 | Re: Weird behaviour |