pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Craig Ringer <craig@2ndquadrant.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Kohei KaiGai <kaigai@kaigai.gr.jp>
Cc: Oleg Bartunov <obartunov@gmail.com>
Cc: Greg Smith <greg@2ndquadrant.com>
Cc: PgHacker <pgsql-hackers@postgresql.org>
Subject: Re: [v9.4] row level security
Date: Sun, 01 Sep 2013 20:41:22 +0800
Message-ID: <522335F2.4040106@2ndquadrant.com> (raw)
In-Reply-To: <CAPpHfdsgMrBnzu9um48O6kwY=_pRFuRrBrHqnA03fCAo8x3-Gg@mail.gmail.com>
References: <CADyhKSUq+BHPAEdrNQXy_bFSzz2SG29vzJmDUh4p20iWje8QSg@mail.gmail.com>
	<CADyhKSVNMMvmPCQkpaVb96T4F3Eu+uREnak4_5_5RLOuSeJLQg@mail.gmail.com>
	<CADyhKSXFzQBXQoNwiKdN9xxoVw7Zqz9gmF64Sry57QKduSFwSQ@mail.gmail.com>
	<CANPAkgtgZbOE5-iU17Gy+_YWODe5UBsfZg6+rk2v=bNQRo0wgA@mail.gmail.com>
	<CADyhKSVoCHMnnGX0Z2b8dgfCUoE1XGdtbAz2HXE4+Q3ajgoxrQ@mail.gmail.com>
	<CANPAkgvcL+w2scZqEcXwX5-TMe9EEORLcHDesJeTn8yoZsc0=g@mail.gmail.com>
	<51E880CF.3000902@gmail.com>
	<51E8A8C1.2050700@2ndQuadrant.com>
	<20130719030347.GV15510@tamriel.snowman.net>
	<51E8ADD9.5020600@2ndQuadrant.com>
	<CAEZATCXdj4E8uPHxq7jiE=1gGVB0xyeHtE8wUjHoX385sHhx4Q@mail.gmail.com>
	<CADyhKSWw1RY01tyuhRzu2HAa_+B9Z5qS6Jv+HEA1w0C9Ua2QLQ@mail.gmail.com>
	<521D1C2B.8090503@2ndQuadrant.com>
	<CAF4Au4xDXzACfC_KrXXpu=4et3XhUe5NtK=6y6yq39Cs2U0XKg@mail.gmail.com>
	<CADyhKSWkHrPqbRsFK0LjPMOOTsbKGWOuN75GqYJrxCDO3CKWtA@mail.gmail.com>
	<CAPpHfdsgMrBnzu9um48O6kwY=_pRFuRrBrHqnA03fCAo8x3-Gg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>


> I think there is another "covert channel" much more serious than
> constrains. You can gather information about hidden data by reading
> query plans.

I think a lot of people would be quite happy to simply disallow EXPLAIN.
Define a permission for it, grant it to public and newly created
users/groups by default (for BC), and allow it to be revoked.

To define what is/isn't reasonable in terms of covert channel leakage, I
(reluctantly) suggest checking out the Common Criteria stuff. Yes, it's
verbose and questionably useful, but it's something that already exists
and that has lots of weight in government / large orgs.  I've started
reading into it but don't have enough info to comment on RLS
specifically yet.

Regarding unique keys and other constraints as leakage channels, I'm
inclined to think that this is partly a documentation issue. The docs
can explain what is/isn't protected against. Suggest creating keys
incorporating security domain identifiers so that users in different
security domains can't create conflicting values.

Possibly provide a mechanism to enforce that so that users can't attempt
to insert/update rows with a different security identifier. Or even make
it transparently part of the system's operations, an implicit extra
column in PRIMARY and FOREIGN keys on RLS-enabled tables.

What I'm more worried about re the covert uniqueness issue is that any
solution might run the risk of creating situations where changes in
access rights can make previously valid data in tables invalid. If two
users A and B can't see each other's data and create the same values for
a key, then B is given the rights to see A's data ... those unique
values now have duplicates.



So: I do think we need to step back a little when it comes to covert
channel attacks and define what we do/don't defend against.

What about timing attacks - do we need to make sure we don't leak
information about the number of RLS rows via scan durations? Make
everything constant-time? Yick. Crypto systems have a hard enough time
getting this stuff right, and I just think we say we don't defend
against timing attacks. If someone wants to mess around with adding
random sleeps in an executor hook, well, that's their pain to deal with.

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (165+ messages)  latest in thread

Message-ID: <522335F2.4040106@2ndquadrant.com>
Permalink:  ../522335F2.4040106@2ndquadrant.com/
Also on:    postgresql.org/message-id/522335F2.4040106@2ndquadrant.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: craig@2ndquadrant.com, aekorotkov@gmail.com, kaigai@kaigai.gr.jp, obartunov@gmail.com, greg@2ndquadrant.com
  Subject: Re: [v9.4] row level security
  In-Reply-To: <522335F2.4040106@2ndquadrant.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox