Re: row security roadmap proposal

On 12/18/2013 11:14 PM, Robert Haas wrote:

> To be clear, I wasn't advocating for a declarative approach; I think
> predicates are fine.  There are usability issues to worry about either
> way, and my concern is that we address those.  A declarative approach
> would certainly be valuable in that, for those people for whom it is
> sufficiently flexible, it's probably quite a lot easier than writing
> predicates.  But I fear that some people will want a lot more
> generality than a label-based system can accommodate.

Having spent some time reading the HL7 spec, I now tend to agree that
labels alone are not going to be sufficient. There are security
decisions made based on:

- Security labels

- User/group/role memberships, both for accessor and target entity owner
(down to the row level)

- Black/white list ACLs, with inheritance and deny rules.

- One-off or narrow authorizations. "I permit my GP to examine my mental
health record details, but only over the last year, and the
authorization stands only for today."

- Authorization assertions. "I declare that the patient told me it is OK
to access these, let me see them."

- "Break glass" access. "This is an emergency. Give me access and I'll
deal with the consequences later."


So while security labels are an important part of the picture I'm forced
to agree that they are not sufficient, and that a generalized row
security mechanism actually is necessary. We don't have the time or
resources to build all these sorts of things individually, and if we did
it'd still be too inflexible for somebody.

In the end, sometimes I guess there's no replacement for "WHERE
call_some_procedure()"


In particular, labels are totally orthogonal to entity identity in the
data model, and being able to make row access decisions  based on
information already in the data model is important. FK relationships to
owning entities and relationships between entities must be usable for
security access policy decisions.

So: I'm withdrawing the proposal to go straight to label security; I
concede that it's insufficiently expressive to meet all possible needs,
and we don't have the time to build anything declarative and
user-friendly that would be.

I do want to make sure that whatever we include this time around does
not create problems for a future label security approach, but that's
kind of required by the desire to add SEPostgreSQL RLS down the track
anyway.

Given that: What are your specific usability concerns about the current
approach proposed in KaiGai's patch?

My main worry was that it requires the user to build everything
manually, and is potentially error prone as a result. To address that we
can build convenience features (label security, ACL types and operators,
etc) on top of the same infrastructure later - it doesn't have to go in
right away.

So putting that side, the concerns I have are:

- The current RLS design is restricted to one predicate per table with
no contextual control over when that predicate applies. That means we
can't implement anything like "policy groups" or overlapping sets of
predicates, anything like that has to be built by the user. We don't
need multiple predicates to start with but I want to make sure there's
room for them later, particularly so that different apps / extensions
that use row-security don't have to fight with each other.

- You can't declare a predicate then apply it to a bunch of tables with
consistent security columns. Updating/changing predicates will be a
pain. We might be able to get around that by recommending that people
use an inlineable SQL function to declare their predicates, but
"inlineable" can be hard to pin down sometimes. If not, we need
something akin to GRANT ... ALL TABLES IN SCHEMA ... for row security,
and ALTER DEFAULT PRIVILEGES ... too.

- It's too hard to see what tables have row-security and what impact it
has. Needs psql improvements.

- There's no way to control whether or not a client can see the
row-security policy definition.


The other one I want to deal with is secure session variables, but
that's mostly a performance optimisation we can add later.

What's your list?

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services