Re: [v9.4] row level security

Поиск
Список
Период
Сортировка
От Kohei KaiGai
Тема Re: [v9.4] row level security
Дата
Msg-id CADyhKSWjf=242wZs3DW0-A-0tU3T92gkW1mVLYg2cPsC-HSp8g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [v9.4] row level security  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
2013/8/29 Tom Lane <tgl@sss.pgh.pa.us>:
> Josh Berkus <josh@agliodbs.com> writes:
>>> That would close only one covert channel.  Others were already pointed out
>>> upthread, and I'll bet there are more ...
>
>> Mind you, fundamentally this is no different from allowing INSERT
>> permission on a table but denying SELECT, or denying SELECT on certain
>> columns.  In either case, covert channels for some data are available.
>
> Certainly.  But INSERT's purpose in life is not to prevent people from
> inferring what data is in the table.  What we have to ask here is whether
> a "row level security" feature that doesn't deal with these real-world
> attack techniques is worth having.
>
I think, we should clearly note that row-level security feature does not
have capability to control information leakage via covert channel but
very limited bandwidth, even though it control information leakage and
manipulation via main channel.
It depends on user's environment and expectation. If they need rdbms
with security feature for military grade, it is not recommendable.
However, it is a recommended solution for regular enterprise grade
environment. Anything depends on user's environment, threats and
worth of values to be protected.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>



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

Предыдущее
От: Kohei KaiGai
Дата:
Сообщение: Re: [v9.4] row level security
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])