[PATCH] Fix leaky VIEWs for RLS
in [PgSql]
|
From: KaiGai Kohei on 7 Jun 2010 00:59 (2010/06/07 10:38), Robert Haas wrote: > On Fri, Jun 4, 2010 at 4:12 PM, Tom Lane<tgl(a)sss.pgh.pa.us> wrote: >> Heikki Linnakangas<heikki.linnakangas(a)enterprisedb.com> writes: >>> On 04/06/10 22:33, Tom Lane wrote: >>>> A counterexample: suppose we had a form of type "text" that carried a >>>> collation specifier internally, and the comparison routine threw an >>>> error if asked to compare values with incompatible specifiers. An index >>>> built on a column of all the same collation would work fine. A query >>>> that tried to compare against a constant of a different collation would >>>> throw an error. >> >>> I can't take that example seriously. First of all, tacking a collation >>> specifier to text values would be an awful hack. >> >> Really? I thought that was under serious discussion. But whether it >> applies to text or not is insignificant; I believe there are cases just >> like this in existence today for some datatypes (think postgis). >> >> The real point is that the comparison constant is under the control of >> the attacker, and it's not part of the index. Therefore "it didn't >> throw an error during index construction" proves nothing whatever. >> >>> ... Secondly, it would be a >>> bad idea to define the b-tree comparison operators to throw an error; >> >> You're still being far too trusting, by imagining that only *designed* >> error conditions matter here. Think about overflows, out-of-memory, >> (perhaps intentionally) corrupted data, etc etc. > > btree comparison operators should handle overflow and corrupted data > without blowing up. Maybe out-of-memory is worth worrying about, but > I think that is a mighty thin excuse for abandoning this feature > altogether. You'd have to contrive a situation where the system was > just about out of memory and something about the value being compared > against resulted in the comparison blowing up or not. I think that's > likely to be rather hard in practice, and in any case it's a covert > channel attack, which I think everyone already agrees is beyond the > scope of what we can protect against. You can probably learn more > information more quickly about the unseen data by fidding with > EXPLAIN, analyzing query execution times, etc. As long as we are > preventing the actual contents of the unseen tuples from being > revealed, I feel reasonably good about it. > It seems to me a good point. In general, any software have possibility to leak information via cover-channels, and it is nearly impossible to fix all the channels. However, from a security perspective, covert channels with low bandwidths represent a lower threat than those with high bandwidths. So, evaluation criteria stands on the viewpoint that it does not necessary to eliminate all the covert channels more than necessity. Even if we can estimate the contents of invisible tuples from error messages or EXPLAIN output, its bandwidths are quite limited. But, lowrite() might write out the given argument somewhere, if it is invoked prior to security policy functions. In this case, the contents of invisible tuples will be moved to another large object unexpectedly with unignorable speed. Such a direct data flow channel should be fixed at first, because of its large bandwidth. >> I think the only real fix would be something like what Marc suggested: >> if there's a security view involved in the query, we simply don't give >> the client the real error message. Of course, now our "security >> feature" is utterly disastrous on usability as well as performance >> counts ... > > Not pushing anything into the view is an equally real fix, although > I'll be pretty depressed if that's where we end up. > I could not find out any certified commercial RDBMS with functionality to tackle covert channel. It includes Oracle's row-level security stuff. So, I don't think it is our goal to prevent anything into views. An idea is that we focus on the direct data flow which allows to move information to be invisible into another tables, files and so on. In this stage, I don't think the priority of error messages are high. 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: KaiGai Kohei on 7 Jun 2010 01:29 (2010/06/07 12:06), Stephen Frost wrote: > * Robert Haas (robertmhaas(a)gmail.com) wrote: >> Another idea I had was... would it be safe to trust functions defined >> by the same user who owns the view? If he's granted access to the >> view and the function to some other user, presumably he doesn't mind >> them being used together? Or is that too optimistic? > > This was more-or-less what I'd been kind of kicking around in my head. > Forget about functions that are defined in the view itself. Any other > functions, etc, which are attached to the view by the calling user would > be suspect, etc. Perhaps with the exception of some built-ins that > we've marked as "safe" in some way. > > My first thought was to track the "run this as X" information on every > RTE (more-or-less, relations, function calls, etc) and then at least be > able to, hopefully, *detect* situations that might be a problem- eg: > running a function which has "run as Q" against a relation that was > accessed as "run as R" when a filter "run as R" happens later. This is > all far too hand-wavey, I'm sure, but at least if we could detect it > then we might be able to find a way to deal with it. > It is a similar idea to what I tried to implement at the conceptual patch. It checks privileges of calling user on the underlaying tables to be referenced using views. If violated, it prevents to push down the user given FuncExpr into join loops of views. Otherwise, it does not prevent anything, because the user originally has privileges to reference them. Are you suggesting the idea (with adjustments such as "safe" functions)? > Also, perhaps I'm not being paranoid enough, but all this concern over > error cases really doesn't really worry me that much. The amount of > data one could acquire that way is pretty limited. It'd be great if we > could deal with that case too, but maybe we could worry about the bigger > issue (at least, as I see it) first. > As I also mentioned at previous message. It seems to me a good point to focus on bandwidth of the covert channel. The error message indeed can deliver information to be invisible, but I don't think its priority is higher than functions that can be abused to direct data flow channel, such as lowrite(). 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: Heikki Linnakangas on 7 Jun 2010 02:48 On 07/06/10 06:06, Stephen Frost wrote: > Also, perhaps I'm not being paranoid enough, but all this concern over > error cases really doesn't really worry me that much. The amount of > data one could acquire that way is pretty limited. It's not limited. It allows you to read all contents of the underlying table or tables. I don't see much point doing anything at all if we don't plug that. There's many side channels like exposing row counts in EXPLAIN and statistics and timing attacks, that are not as critical, because they don't let expose all data, and the attacker can't accurately choose what data is exposed. Those are not as important. -- 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: KaiGai Kohei on 7 Jun 2010 03:30 (2010/06/07 15:48), Heikki Linnakangas wrote: > On 07/06/10 06:06, Stephen Frost wrote: >> Also, perhaps I'm not being paranoid enough, but all this concern over >> error cases really doesn't really worry me that much. The amount of >> data one could acquire that way is pretty limited. > > It's not limited. It allows you to read all contents of the underlying > table or tables. I don't see much point doing anything at all if we > don't plug that. > IIRC, Oracle pays attention not to expose function's arguments via error messages due to the security reasons, although it focuses on that does not provide a hint to attacker who tries SQL injection. It seems to me it is a matter of degree. If we allows to execute lowrite() inside of the join loop, it can be abused to move massive invisible information into visible large objects within a little time. So, its priority is relatively higher than error messages. However, we cannot move massive information via error messages in a little time, although it may expose whole of the arguments. So, its threat is relatively smaller. > There's many side channels like exposing row counts in EXPLAIN and > statistics and timing attacks, that are not as critical, because they > don't let expose all data, and the attacker can't accurately choose what > data is exposed. Those are not as important. > It also means; because they can provide much smaller bandwidth to leak invisible information than error messages, these are not as important. Is it right? 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: Heikki Linnakangas on 7 Jun 2010 05:07
On 07/06/10 10:30, KaiGai Kohei wrote: > (2010/06/07 15:48), Heikki Linnakangas wrote: >> There's many side channels like exposing row counts in EXPLAIN and >> statistics and timing attacks, that are not as critical, because they >> don't let expose all data, and the attacker can't accurately choose what >> data is exposed. Those are not as important. >> > It also means; because they can provide much smaller bandwidth to leak > invisible information than error messages, these are not as important. > Is it right? The big difference is what information can be obtained, not how fast it can be obtained. Imagine a table that holds username/passwords for users. Each user is allowed to see his own row, including password, but not anyone else's. EXPLAIN side-channel might give pretty accurate information of how many rows there is in the table, and via clever EXPLAIN+statistics probing you might be able to find out what the top-10 passwords are, for example. But if you wanted to know what your neighbor's password is, the side-channels would not help you much, but an error message would reveal it easily. -- 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 |