On Mon, Mar 12, 2012 at 11:13 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> 2012/3/12 Robert Haas <robertmhaas@gmail.com>:
>> On Mon, Mar 12, 2012 at 10:58 AM, Kohei KaiGai <kaigai@kaigai.gr.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
tofoo_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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
