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

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company