Re: security label support, part.2

2010/8/17 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> I dunno.  None of the above makes me feel very comfortable from a
>> security perspective because I'm concerned any of the above could too
>> easily be overlooked by someone upgrading.  It also doesn't really
>> address the concern that, at some point, a child table could have
>> different permissions than a parent table.  If we forcibly set the
>> permissions on the child, or ERROR'd if the permissions weren't either
>> the same or empty on the child, and then ERROR'd if someone tried to
>> change the child's permissions later, I'd be happier.
>>
> I also think ERROR should be raised when user tries to assign different
> security properties on child tables from its parent. At least, I think
> it should be configurable using a guc variable.

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? 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.

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company