Re: security label support, part.2

Robert,

* Robert Haas (robertmhaas@gmail.com) wrote:
> If C1, C2, and C3 inherit from P, it's perfectly reasonable to grant
> permissions to X on C1 and C2, Y on C3, and Z on C1, C2, C3, and P.  I
> don't think we should disallow that.  Sure, it's possible to do things
> that are less sane, but if we put ourselves in the business of
> removing useful functionality because it might be misused, we'll put
> ourselves out of business.
>
> Having said that, I'm not sure that the same arguments really hold
> water in the world of label based security.  Suppose we have
> compartmentalized security: P is a table of threats, with C1
> containing data on nukes, C2 containing data on terrorists, and C3
> containing data on foreign militaries.  If we create a label for each
> of these threat types, we can apply that label to the corresponding
> table; but what label shall we assign P?  Logically, the label for P
> should be set up in such a fashion that the only people who can read P
> are those who can read C1, C2, and C3 anyway, but who is to say that
> such a label exists? Even if KaiGai's intended implementation of
> SE-PostgreSQL supports construction of such a label, who is to say
> that EVERY conceivable labeling system will also do so?

I don't see why using labels in the second case changes anything.
Consider roles.  If you only had a role that could see threats, a role
that could see nukes, and a role that could see terrorists, but no role
that could see all of them, it's the same problem.  Additionally, this
kind of problem *isn't* typically addressed with the semantics or the
structure of inheiritance- it's done with row-level security and is
completely orthogonal to the inheiritance issue.

Imagine a new table, C4, is added to P and the admin configures it such
that only the 'view_c4' role has access to that child table directly.
Now, Z can see what's in C4 through P, even though Z doesn't have access
to C4.  In the old system, if Z's query happened to hit C4, the whole
query would fail but at least Z wouldn't see any C4 data.  Other queries
on P done by Z would be fine, so long as they didn't hit C4.

> In fact, it
> seems to me that it might be far more reasonable, in a case like this,
> to ignore the *parent* label and look only at each *child* label,
> which to me is an argument that we should set this up so as to allow
> individual users of this hook to do as they like.

I think it'd be more reasonable to do this for inheiritance in general,
but the problem is that people use it for partitioning, and there is a
claim out there that it's against what the SQL spec says.  The folks
using inheiritance for partitioning would probably prefer to not have to
deal with setting up the permissions on the child tables.  I think
that's less of an issue now, but I didn't like the previous behavior
where certain queries would work and certain queries wouldn't work
against the parent table, either.

> It's also worth pointing out that the hook in ExecCheckRTPerms() does
> not presuppose label-based security.  It could be used to implement
> some other policy altogether, which only strengthens the argument that
> we can't know how the user of the hook wants to handle these cases.

This comes back around, in my view, to the distinction between really
using inheiritance for inheiritance, vs using it for partitioning.  If
it's used for partitioning (which certainly seems to be the vast
majority of the cases I've seen it used) then I think it should really
be considered and viewed as a single object to the authentication
system.  I don't suppose we're going to get rid of inheiritance for
inheiritance any time soon though.

In the end, I'm thinking that if the external security module wants to
enforce a check against all the children of a parent, they could quite
possibly handle that already and do it in such a way that it won't break
depending on the specific query.  To wit, it could query the catalog to
determine if the current table is a parent of any children, and if so,
go check the labels/permissions/etc on those children.  I'd much rather
have something where the permissions check either succeeds or fails
against the parent, depending on the permissions of the parent and its
children, than on what the query is itself and what conditionals are
applied to it.
Thanks,
    Stephen