From: KaiGai Kohei <kaigai@kaigai.gr.jp>
To: Robert Haas <robertmhaas@gmail.com>
Cc: KaiGai Kohei <kaigai@ak.jp.nec.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Row-Level Security
Date: Mon, 14 Dec 2009 20:52:13 +0900
Message-ID: <4B2626ED.7030104@kaigai.gr.jp> (raw)
In-Reply-To: <603c8f070912140318i6bbc1d63o9e81d409d0b342b6@mail.gmail.com>
References: <20091212203003.GL17756@tamriel.snowman.net>
<4B24381F.7050407@agliodbs.com>
<603c8f070912121918i59f807e3n5ed4d4699227e43@mail.gmail.com>
<4B24AAED.2080706@kaigai.gr.jp>
<603c8f070912130411q765c7e9aw371b468229b8e32@mail.gmail.com>
<4B25C5B2.9010108@ak.jp.nec.com>
<603c8f070912132135l43bdf060sa5207b5a4d2c918c@mail.gmail.com>
<4B25DE99.2050801@ak.jp.nec.com>
<603c8f070912140318i6bbc1d63o9e81d409d0b342b6@mail.gmail.com>
(2009/12/14 20:18), Robert Haas wrote:
>>>>>> * Foreign Key constraint(2)
>>>>>>
>>>>>> FK is implemented as a trigger which internally uses SELECT/UPDATE/DELETE.
>>>>>> If associated tuples are filtered out, it breaks reference integrity.
>>>>>> So, we have to apply special care. In SE-PgSQL case, it raises an error
>>>>>> instead of filtering during FK checks. And, row-level security hook is
>>>>>> called at the last for each tuples, unlike normal cases.
>>>>> Perfecting referential integrity here seems like a pretty tough
>>>>> problem, but it's likely not necessary to solve it in order to get an
>>>>> implementation of row-level security that is useful for some purposes.
>>>> Is the approach in SE-PgSQL suitable for the issue?
>>>> It can prevent to update/delete tuple referenced by invisible tuples.
>>>>
>>>> We have two modes in row-level security.
>>>> The first is filtering-mode. It applies security policy function prior
>>>> to any other user given conditions, and filters out violated tuples from
>>>> the result set.
>>>> The second is aborting-mode. It is only used by internal stuff which does
>>>> not provide any malicious function in the condition. It applies security
>>>> policy function next to all the WHERE clause, and raises an error if the
>>>> query tries to refer violated tuples.
>>>
>>> Hmm... the idea of having two modes doesn't sound right off the top of
>>> my head. But I think we have a long time before we need worry about
>>> this. We have neither SE-PostgreSQL nor RLS in core, nor are either
>>> one anywhere close to being merged. So worrying about how the two
>>> will interact when we have both is putting the cart before the horse.
>>> A lot can change between now and then.
>>
>> IIRC, I've not gotten any opposition about this two-modes design.
>> Most of arguments about RLS were information leaks via covert-channels
>> which allows us to estimate an existence of invisible PK/FK.
>> But we don't define it as a problem to be resolved.
>
> I know that was one of Tom's concerns. Personally, my concerns are:
>
> 1. I want to implement row-level security in a way that is useful for
> people who don't care about SE-PostgreSQL. I think there are lots of
> people who would be interested in that. In fact, as Josh said, there
> are probably MORE people who are interested in the constraint-based
> approach than there are who want label-based security a la
> SE-PostgreSQL.
I also agree it is a right direction. SELinux shall be "one of them" to
make access control decision in row-level.
In my current standpoint, we add general row-level security first, then
SELinux support provides its access control decision function. OK?
> 2. I want to implement row-level security in a way that is very
> flexible and allows for a wide range of access control policies. The
> core row-level security mechanism should not care about or prejudge a
> particular policy - it should just be a mechanism for enforcing
> row-filtering.
Ditto,
> 3. I want to implement row-level security in a way that allows the
> planner maximum flexibility in implementing the row filtering that is
> needed in a particular case. SE-PostgreSQL RLS presumes what is
> essentially an additional join against the security table ID for every
> table in the query - doing this in a way that allows joins to be
> reordered or implemented in multiple ways (straight nestloop, nestloop
> with inner indexscan, hash join) will drastically improve performance.
> The original implementation didn't actually implement it as a join,
> but rather with special-case code that performed the security ID
> lookups as part of the heap scan. That's not going to work for any
> kind of row-level security other than SE-PostgreSQL (so, see points 1
> and 2) and it's also going to make the performance much worse than it
> needs to be. Granted, the performance is never going to be GOOD, but
> we should try to at least make it not ATROCIOUS.
The reason why I put on the security hook in ExecScan() is to avoid the
problem that row-cost user defined function can be evaluated earlier
than row-level security policy. (I believed it was a well-known problem
at that time yet.) So, I didn't want to append it before optimization.
I also believe this matter should be resolved when we provide row-level
security stuff, because it is a security feature.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
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: kaigai@kaigai.gr.jp, robertmhaas@gmail.com, kaigai@ak.jp.nec.com, josh@agliodbs.com, sfrost@snowman.net
Subject: Re: Row-Level Security
In-Reply-To: <4B2626ED.7030104@kaigai.gr.jp>
* 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