On Mon, Mar 12, 2012 at 11:13 AM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: > 2012/3/12 Robert Haas <robertmh...@gmail.com>: >> On Mon, Mar 12, 2012 at 10:58 AM, Kohei KaiGai <kai...@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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
