Re: [v9.2] Add GUC sepgsql.client_label - Mailing list pgsql-hackers
From | Kohei KaiGai |
---|---|
Subject | Re: [v9.2] Add GUC sepgsql.client_label |
Date | |
Msg-id | CADyhKSW+Ojnn1KPf2O-_m5hY+8pGS+cCtunY32=t8SnckaB91g@mail.gmail.com Whole thread Raw |
In response to | Re: [v9.2] Add GUC sepgsql.client_label (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: [v9.2] Add GUC sepgsql.client_label
(Robert Haas <robertmhaas@gmail.com>)
|
List | pgsql-hackers |
2012/3/12 Robert Haas <robertmhaas@gmail.com>: > 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 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@kaigai.gr.jp>
pgsql-hackers by date: