Re: security label support, part.2

(2010/08/18 12:02), Robert Haas wrote:
> 2010/8/17 KaiGai Kohei<kaigai@ak.jp.nec.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.
> 
Hmm. If C1, C2 and C3 are defined to store information for different
categories, but shares common data structure, indeed, it is useful.

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

Right. If access privileges on P implicitly allow accesses on children,
the P must have a label that only allows people who can access both of
the children. However, in SELinux at least, here is no guarantee that
we can always find out such a label in the security policy installed. :(

> 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 will be helpful. If we can check each children's label, no need
to restrict an identical security label within a certain inheritance
hierarchy. Of course, other security module may check permissions
in different basic, but it seems to me characteristics.

> 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.
> 
If rte->requiredPerms would not be cleared, the user of the hook will
be able to check access rights on the child tables, as they like.
How about an idea to add a new flag in RangeTblEntry which shows where
the RangeTblEntry came from, instead of clearing requiredPerms?
If the flag is true, I think ExecCheckRTEPerms() can simply skip checks
on the child tables.

Thanks,
-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>