2012/3/12 Robert Haas <robertmh...@gmail.com>: > 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. > 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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
