Re: security label support, part.2

(2010/08/15 9:55), Robert Haas wrote:
> 2010/8/14 KaiGai Kohei<kaigai@kaigai.gr.jp>:
>> (2010/08/15 9:16), Stephen Frost wrote:
>>> * KaiGai Kohei (kaigai@kaigai.gr.jp) wrote:
>>>> Yep, rte->requiredPerms of inherited relations are cleared on the
>>>> expand_inherited_rtentry() since the v9.0, so we cannot know what
>>>> kind of accesses are required on the individual child relations.
>>>
>>> This is really a PG issue and decision, in my view.  We're moving more
>>> and more towards a decision that inherited relations are really just the
>>> same relation but broken up per tables (ala "true" partitioning).  As
>>> such, PG has chosen to view them as the same wrt permissions checking.
>>> I don't think we should make a different decision for security labels.
>>> If you don't want people who have access to the parent to have access to
>>> the children, then you shouldn't be making them children.
>>>
>> No, what I want to do is people have identical access rights on both of
>> the parent and children. If they have always same label, SE-PgSQL always
>> makes same access control decision. This behavior is suitable to the
>> standpoint that inherited relations are really just the same relation
>> of the parent. For this purpose, I want to enforce a unique label on
>> a certain inheritance tree.
> 
> This seems like a bad idea to me, too.  I think it's arguable whether
> access to the children should be controlled by the parent's label or
> the child's label, but enforcing that the entire inheritance hierarchy
> is identically labeled seems like a pointless restriction.  As Stephen
> points out, it's also wildly inconsistent with the way we currently
> handle it.
> 
> There's also the problem that the hooks we're talking about here are
> inadequate to support such a restriction anyway.  You'd need some kind
> of a hook in ALTER TABLE ... [NO] INHERIT, at a minimum.  As has been
> mentioned many times before in reviewing many generations of
> SE-PostgreSQL patches, we're not going to get into the business of
> re-engineering our security architecture just because you would have
> designed it differently.  Inventing something that's randomly
> different will not only make the code ugly and hard to maintain; it
> will also be confusing and difficult to manage for end-users.
> 
Indeed, our existing mechanism allows to assign individual privileges
on child tables, even if it is in a certain inheritance hierarchy.

The purpose of this restriction is to ensure an access control decision
using parent's label being also consistent on child tables.
If we control accesses on child tables using child's label, no need to
restrict an identical label within an entire inheritance hierarchy.
But it needs to provide the original rte->requiredPerms of child tables.
Now it is cleared at expand_inherited_rtentry(), so we have no way to
control accesses on child tables using child's label. :(

From viewpoint of MAC, both of the following SQLs should be denied,
when accesses on parent_tbl is allowed, but child_tbl is denied.
1) SELECT * FROM parent_tbl;
2) SELECT * FROM child_tbl;

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