Re: [v9.4] row level security

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [v9.4] row level security
Дата
Msg-id 20130901190142.GS2706@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [v9.4] row level security  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
Josh,

* Josh Berkus (josh@agliodbs.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kohei KaiGai
Дата:
Сообщение: Re: [v9.4] row level security
Следующее
От: Kohei KaiGai
Дата:
Сообщение: Re: [v9.4] row level security