[PATCH] Fix leaky VIEWs for RLS
in [PgSql]
|
From: KaiGai Kohei on 4 Jun 2010 06:38 (2010/06/04 18:26), Dimitri Fontaine wrote: > Tom Lane<tgl(a)sss.pgh.pa.us> writes: >> The proposal some time back in this thread was to trust all built-in >> functions and no others. That's a bit simplistic, no doubt, but it >> seems to me to largely solve the performance problem and to do so with >> minimal effort. When and if you get to a solution that's committable >> with respect to everything else, it might be time to think about >> more flexible answers to that particular point. > > What about trusting all "internal" and "C" language function instead? My > understanding is that "internal" covers built-in functions, and as you > need to be a superuser to CREATE a "C" language function, surely you're > able to accept that by doing so you get to trust it? > > How useful would that be? If we trust all the "C" language functions, it also means DBA can never install any binary functions having side-effect (e.g, pg_file_write() in the contrib/adminpack ) without security risks. If we need an intelligence to identify what functions are trusted and what ones are untrusted, it will eventually need a hint to mark a certain function as trusted, won't it? Thanks, -- KaiGai Kohei <kaigai(a)kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 4 Jun 2010 10:33 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > On 04/06/10 07:57, Tom Lane wrote: >> The proposal some time back in this thread was to trust all built-in >> functions and no others. > I thought I debunked that idea already > (http://archives.postgresql.org/pgsql-hackers/2009-10/msg01428.php). Not > all built-in functions are safe. Consider casting integer to text, for > example. Seems innocent at first glance, but it's not; if the input is > not a valid integer, it throws an error which contains the input string, > revealing it. Hmm ... that's a mighty interesting example, because it shows that any well-meaning change in error handling might render seemingly-unrelated functions "unsafe". And we're certainly not going to make error messages stop showing relevant information just because of this. Maybe the entire idea is unworkable. I certainly don't find any comfort in your proposal in the above-referenced message to trust index operators; where is it written that those don't throw errors? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 4 Jun 2010 08:26 On 04/06/10 07:57, Tom Lane wrote: > KaiGai Kohei<kaigai(a)ak.jp.nec.com> writes: >> (2010/06/04 11:55), Robert Haas wrote: >>> A (very) important part of this problem is determining which quals are >>> safe to push down. >>> >> At least, I don't have an idea to distinguish trusted functions from >> others without any additional hints, because we support variable kind >> of PL languages. :( > > The proposal some time back in this thread was to trust all built-in > functions and no others. I thought I debunked that idea already (http://archives.postgresql.org/pgsql-hackers/2009-10/msg01428.php). Not all built-in functions are safe. Consider casting integer to text, for example. Seems innocent at first glance, but it's not; if the input is not a valid integer, it throws an error which contains the input string, revealing it. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Marc Munro on 4 Jun 2010 12:49 On Fri, 2010-06-04 at 10:33 -0400, Tom Lane wrote: > Hmm ... that's a mighty interesting example, because it shows that any > well-meaning change in error handling might render seemingly-unrelated > functions "unsafe". And we're certainly not going to make error > messages stop showing relevant information just because of this. Although that looks like a show-stopper, I think it can be worked around. Errors in operations on security views could simply be caught and conditionally rewritten. The original error could still appear in the logs but the full details need not be reported to unprivileged users. If that can be done, then we would still need to be able to identify trusted functions and views used for security purposes, and ensure that (please excuse my terminology if it is incorrect) untrusted quals do not get pushed down inside secured views. If all of that can be done along with the error trapping, then we may have a solution. My big concern is still about performance, particularly when joining between multiple security views and other objects. I don't expect to get security for free but I don't want to see unnecessary barriers to optimisation. __ Marc
From: Heikki Linnakangas on 4 Jun 2010 13:46
On 04/06/10 17:33, Tom Lane wrote: > Heikki Linnakangas<heikki.linnakangas(a)enterprisedb.com> writes: >> On 04/06/10 07:57, Tom Lane wrote: >>> The proposal some time back in this thread was to trust all built-in >>> functions and no others. > >> I thought I debunked that idea already >> (http://archives.postgresql.org/pgsql-hackers/2009-10/msg01428.php). Not >> all built-in functions are safe. Consider casting integer to text, for >> example. (I meant "text to integer", of course) > Maybe the entire idea is unworkable. I certainly don't find any comfort > in your proposal in the above-referenced message to trust index > operators; where is it written that those don't throw errors? Let's consider b-tree operators for an index on the secure table, for starters. Surely a b-tree index comparison operator can't throw an error on any value that's in the table already, you would've gotten an error trying to insert that. Now, is it safe to expand that thinking to b-tree operators in general, even if there's no such index on the table? I'm not sure. But indexable operations are what we care about the most; the order of executing those determines if you can use an index scan or not. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |