From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [v9.4] row level security |
Date: | 2013-09-01 19:01:42 |
Message-ID: | 20130901190142.GS2706@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh,
* Josh Berkus (josh(at)agliodbs(dot)com) wrote:
> That's an astonishingly weak argument, because the bandwidth you're
> talking about is still very high, as in *hundreds* or *thousands* of
> values per minute.
I agree that, in this specific case, we should do something about it.
> It's one thing to make the bandwidth argument for
> things like monitoring power draw, where the leakage is one character
> per hour, but the covert channels we're talking about are several orders
> of magnitude faster than that.
That's actually not an accurate representation of the bandwidth
associated with power draw measurements, but even if I convinced you it
was in the hundreds or thousands of values per minute, I doubt you'd
change your mind regarding the Filtered Rows issue or claim that we
should fix the power draw measurement issue. :)
> So, I repeat: if you continue to pursue the argument that the covert
> channels identified aren't significant because of bandwidth, you will
> doom this patch. The valid arguments are only two:
There is actually another argument, which I mentioned up-thread.. There
are cases where you can't guarantee all the promises which can be asked
for. In the unique-value case, we can't guarantee both that the values
are unique and that existing values can't be detected by an individual
with insert access. We should make the user aware that allowing insert
access (or perhaps 'explain') opens up these cases.
> a) clearly identified use case X doesn't care about covert channels for
> reason Y, and will find RLS extremely useful.
These certainly exist and I'd argue that's part of why Veil exists..
Users of Veil (which I admit, I'm not) would likely be much happier
with an in-core solution because it will be much easier to use and
much more performant.
> b) we can't fix these covert channels now, but plan to work on them in
> the future, and have ideas for how to approach them.
I expect we will find more covert chanels which need to be fixed.
> To be completely blunt, the security community does not understand
> databases. At all. I'd think if anything had become clear through the
> course of work on SEPosgres, it would be that.
That's just false and it's poor of you to claim it. The security
community is not one individual nor even some small group. They're not
very obviously involved with PostgreSQL but that's no reason to claim
that they do not understand databases.
> I don't think I understood this answer. What I'm asking is: will
> government agencies be sigificantly more likely to adopt PostgreSQL if
> we have RLS, in this form? Or do we need "military-grade" before it
> makes a difference?
From my experience, the answer would be 'yes' to your first question.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2013-09-01 19:31:27 | Re: [v9.4] row level security |
Previous Message | Kohei KaiGai | 2013-09-01 18:44:14 | Re: [v9.4] row level security |