2014-07-06 14:19 GMT+09:00 Stephen Frost <sfr...@snowman.net>:
> Kaigai,
>
> * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
>> > Can you clarify where this is coming from..? It sounds like you're
>> > referring to an existing implementation and, if so, it'd be good to get
>> > more information on how that works exactly.
>>
>> Oracle VPD - Multiple Policies for Each Table, View, or Synonym
>> http://docs.oracle.com/cd/B19306_01/network.102/b14266/apdvpoli.htm#i1008351
>>
>> It says - Note that all policies applied to a table are enforced with AND
>> syntax.
>
> While I'm not against using this as an example to consider, it's much
> more complex than what we're talking about here- and it supports
> application contexts which allow groups of RLS rights to be applied or
> not applied; essentially it allows both "AND" and "OR" for sets of RLS
> policies, along with "default" policies which are applied no matter
> what.
>
>> Not only Oracle VPD, it fits attitude of defense in depth.
>> Please assume a system that installs network firewall, unix permissions
>> and selinux. If somebody wants to reference an information asset within
>> a file, he has to connect the server from the network address being allowed
>> by the firewall configuration AND both of DAC and MAC has to allow his
>> access.
>
> These are not independent systems and your argument would apply to our
> GRANT system also, which I hope it's agreed would make it far less
> useful. Note also that SELinux brings in another complexity- it needs
> to make system calls out to check the access.
>
>> Usually, we have to pass all the access control to reference the target
>> information, not one of the access control stuffs being installed.
>
> This is true in some cases, and not in others. Only one role you are a
> member of needs to have access to a relation, not all of them. There
> are other examples of 'OR'-style security policies, this is merely one.
> I'm simply not convinced that it applies in the specific case we're
> talking about.
>
> In the end, I expect that either way people will be upset because they
> won't be able to specify fully which should be AND vs. which should be
> OR with the kind of flexibility other systems provide. What I'm trying
> to get to is an initial implementation which is generally useful and is
> able to add such support later.
>
>> > This is similar to how roles work- your overall access includes all access
>> > granted to any roles you are a member of. You don't need SELECT rights
>> > granted
>> > to every role you are a member of to select from the table. Additionally,
>> > if an admin wants to AND the quals together then they can simply create
>> > a policy which does that rather than have 2 policies.
>> >
>> It seems to me a pain on database administration, if we have to pay attention
>> not to conflict each RLS-policy.
>
> This notion of 'conflict' doesn't make much sense to me. What is
> 'conflicting' here? Each policy would simply need to stand on its own
> for the role which it's being applied to. That's very simple and
> straight-forward.
>
>> I expect 90% of RLS-policy will be configured
>> to PUBLIC user, to apply everybody same rules on access. In this case, DBA
>> has to ensure the target table has no policy or existing policy does not
>> conflict with the new policy to be set.
>> I don't think it is a good idea to enforce DBA these checks.
>
> If the DBA only uses PUBLIC then they have to ensure that each policy
> they set up for PUBLIC can stand on its own- though, really, I expect if
> they go that route they'd end up with just one policy that calls a
> stored procedure...
>
>> > You are suggesting instead that if application 2 sets up policies on the
>> > table and then application 1 adds another policy that it should reduce what
>> > application 2's users can see? That doesn't make any sense to me. I'd
>> > actually expect these applications to at least use different roles anyway,
>> > which means they could each have a single role specific policy which only
>> > returns what that application is allowed to see.
>> >
>> I don't think this assumption is reasonable.
>> Please expect two applications: app-X that is a database security product
>> to apply access control based on remote ip-address of the client for any
>> table accesses by any database roles. app-Y that is a usual enterprise
>> package for daily business data, with RLS-policy.
>> What is the expected behavior in this case?
>
> That the DBA manage the rights on the tables. I expect that will be
> required for quite a while with PG. It's nice to think of these
> application products that will manage all access for users by setting up
> their own policies, but we have yet to even discuss how they would have
> appropriate rights on the table to be able to do so (and to not
> interfere with each other..).
>
> Let's at least get something which is generally useful in. I'm all for
> trying to plan out how to get there and would welcome suggestions you
> have which are specific to PG on what we could do here (I'm not keen on
> just trying to mimic another product completely...), but at the level
> we're talking about (either AND them all or OR them all), I don't think
> we'd actually solve the use-cases you're describing with either answer.
>
> Without getting to the full level of having the flexibility to choose
> which policies should be AND'd and which should be OR'd, do you see an
> issue with adding initial support where each policy has to stand on its
> own and then working to address the more complex cases later?
>
Let me sort out. Probably, the reason of opinion differences come from
the point where I and you focus on.
It seems to me you try to position the upcoming RLS feature in the context
of existing database role and acl mechanism. I think it is a straightforward
approach and never argue. On the other hand, I'm worrying about whether
we can utilize the RLS feature as a basis to implement different security
model that performs independently from database roles and acl.
As long as RLS-policy quals are connected with OR, it is a design choice
to fit behavior of database acl and grant / revoke.
Things I'd like you to pay attention is, how much flexible to use this RLS
feature as a basis of other security model. One candidate is selinux; that
does not pay attention on database roles, so row-level security policy
attached by selinux should not be over-written by database roles.
As you mentioned above, RLS-policy is connected with user-given quals
by AND'd manner, like:
SELECT * FROM t1 WHERE x like '%abc%';
being replaced to
SELECT * FROM t1 WHERE (x like '%abc%') AND (quals by built-in RLS);
What I'd like to implement is adjustment of query like:
SELECT * FROM t1 WHERE (x like '%abc%') AND (quals by built-in RLS)
AND (quals by extension-1) AND ... AND (quals by extension-N);
I never mind even if qualifiers in the second block are connected with OR'd
manner, however, I want RLS infrastructure to accept additional security
models provided by extensions.
Thanks,
--
KaiGai Kohei <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
