[PATCH] Fix leaky VIEWs for RLS
in [PgSql]
|
From: KaiGai Kohei on 7 Jun 2010 22:10 (2010/06/08 10:17), Stephen Frost wrote: > KaiGai, > > * KaiGai Kohei (kaigai(a)ak.jp.nec.com) wrote: >> Perhaps, pg_proc takes a new flag to represent it. > > Without an actual well-formed approach for dealing with this which > requires it, it's far too soon to be asking for changes in the catalog. > Please stop suggesting individual maybe-this-would-help changes. We > need an actual solution which addresses all, or at least most, of the > concerns described, followed by a patch which implements the mechanics > of the solution. If the solution calls for an additional pg_proc field, > then the patch should include it. > OK, it was too implementation-specific. Please return to the categorization with 3-level that I mentioned at the previous message. I guess nobody opposes to disable pushing down on functions categorized to high-threat, such as lowrite() and so on. It actually can move given arguments to other tables, files, ... And, I guess nobody wants to tackle an issue categorized to low-threat, such as EXPLAIN, PK/FK constraints and so on. It can imply existence of invisible objects, but no leaks of actual value. Our headache is on functions categorized to middle-threat. It enables to leak the given arguments using error messages. Here are several ideas, but they have good and bad points. At first, it is necessary whether we should fix up the threat in this level, or not. It seems to me majority of the -hackers want to fix both of high and middle level. If we should fix up the issue, I think we have only two options semantically. (A) It prevents leaky functions to be pushed down, so no invisible information will be provided. But it makes performance regression. (B) It prevents leaky functions to raise an error, although we allow it to be pushed down. But is needs large scale of code changes. Of course, it has trade-off. As TCSEC mentioned, we are facing with the large potential cost of reducing the bandwidths of such covert channel > Not sure if this would translate well, but asking for new flags to be > added to pg_proc right now is putting the cart before the horse. We > don't even know which functions we might mark as trusted or not yet, nor > is it even clear that adding such a flag would actually help. Adding a > flag to pg_proc is certainly nothing like a solution to this problem by > itself. > For built-in functions, the code should be reviewed to ensure it does not expose the given argument using error messages. Then, we can mark it as trusted. Thanks, -- KaiGai Kohei <kaigai(a)ak.jp.nec.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: Robert Haas on 7 Jun 2010 22:15 2010/6/7 KaiGai Kohei <kaigai(a)ak.jp.nec.com>: > Our headache is on functions categorized to middle-threat. It enables to > leak the given arguments using error messages. Here are several ideas, > but they have good and bad points. I think we are altogether off in the weeds here. We ought to start with an implementation that pushes nothing down, and then try to figure out how much we can relax that without too much compromising security. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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: Stephen Frost on 7 Jun 2010 22:19 * Robert Haas (robertmhaas(a)gmail.com) wrote: > 2010/6/7 KaiGai Kohei <kaigai(a)ak.jp.nec.com>: > > Our headache is on functions categorized to middle-threat. It enables to > > leak the given arguments using error messages. Here are several ideas, > > but they have good and bad points. > > I think we are altogether off in the weeds here. We ought to start > with an implementation that pushes nothing down, and then try to > figure out how much we can relax that without too much compromising > security. I agree with this- and it's more-or-less what I was trying to propose in my previous comments. I'm not even sure we need to focus on not pushing anything down at this point- I'd start with trying to get enough information passed around/through the system to even *identify* the case where there's a problem in the first place.. Thanks, Stephen
From: KaiGai Kohei on 7 Jun 2010 22:25 (2010/06/08 11:15), Robert Haas wrote: > 2010/6/7 KaiGai Kohei<kaigai(a)ak.jp.nec.com>: >> Our headache is on functions categorized to middle-threat. It enables to >> leak the given arguments using error messages. Here are several ideas, >> but they have good and bad points. > > I think we are altogether off in the weeds here. We ought to start > with an implementation that pushes nothing down, and then try to > figure out how much we can relax that without too much compromising > security. > It seems to me fair enough. I think we can adjust what functions are harmless, and whats are not later. Thanks, -- KaiGai Kohei <kaigai(a)ak.jp.nec.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: Stephen Frost on 7 Jun 2010 22:28
For the sake of clarity.. * KaiGai Kohei (kaigai(a)ak.jp.nec.com) wrote: > OK, it was too implementation-specific. No, that wasn't the problem. There isn't an actual implementation yet for it to be too-specific on. The problem is that proposing a change to the catalog without figuring out what it'd actually be used for in an overall solution is a waste of time. > Please return to the categorization with 3-level that I mentioned at > the previous message. As Robert said, we're off in the weeds here. I'm not convinced that we've got 3 levels, for starters. It could well be fewer, or more. Let's stop making assumptions about what's OK and what's not OK. > For built-in functions, the code should be reviewed to ensure it does not > expose the given argument using error messages. > Then, we can mark it as trusted. One thing that I think *is* clear- removing useful information from error messages is *not* going to be an acceptable "solution". Thanks, Stephen |