Re: [v9.2] Add GUC sepgsql.client_label
От | Robert Haas |
---|---|
Тема | Re: [v9.2] Add GUC sepgsql.client_label |
Дата | |
Msg-id | CA+TgmoYhmqrujOHH3eNiOSSuz+uOxPMgbBOa-e67WTDBgR+pCg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [v9.2] Add GUC sepgsql.client_label (Kohei KaiGai <kaigai@kaigai.gr.jp>) |
Ответы |
Re: [v9.2] Add GUC sepgsql.client_label
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: