Re: Row-Level Security

(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(at)kaigai(dot)gr(dot)jp>