Re: security label support, part.2 - Mailing list pgsql-hackers

(2010/08/10 8:39), Robert Haas wrote:
> 2010/8/9<kaigai@kaigai.gr.jp>:
>>> 2. Some of this code refers to "local" security labels.  I'm not sure
>>> what's "local" about them - aren't they just security labels?  On a
>>> related note, I don't like the trivial wrappers you have here, with
>>> DeleteSecurityLabel around DeleteLocalSecLabel, SetSecurityLabel
>>> around SetLocalSecLabel, etc.  Just collapse these into a single set
>>> of functions.
>>>
>> In the feature, I plan to assign security labels on the shared database
>> objects such as pg_database. The "local" is a contradistinction
>> towards these "shared" objects.
>
> Oh, I see.  I don't think that's entirely clear: and in any event it
> seems a bit premature, since we're not at that point yet.  Let's just
> get rid of this stuff for now as I suggested.
>
OK. We can add this supportanytime we need it.

>>> 5. Why do we think that the relabel hook needs to be passed the number
>>> of expected parents?
>>>
>> We need to prevent relabeling on inherited relations/columns from
>> the multiple origin, like ALTER RENAME TO.
>> It requires to pass the expected parents into the provider, or
>> to check it in the caller.
>
> Please explain further.  I don't understand.
>
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.
It needs the inherited relations/columns being labeled with same
security label of their parent, because SE-PgSQL always makes same
access control decision on same security labels.

Thus, we want to check whether the relabeling operation breaks the
uniqueness of security label within a certain inheritance tree, or not.

Here is the logic to check relabeling on relation/column.
http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/hooks.c#254
It checks two things.
1) The given relation/column must be the origin of inheritance tree   when expected_parents = 0.
2) The given relation/column must not belong to multiple inheritance   tree.

So, the hook need to provide the expected_parents for each relations/columns.

>>> 6. What are we doing about the assignment of initial security labels?
>>> I had initially thought that perhaps new objects would just start out
>>> unlabeled, and the user would be responsible for labeling them as
>>> needed.  But maybe we can do better.  Perhaps we should extend the
>>> security provider hook API with a function that gets called when a
>>> labellable object gets created, and let each loaded security provider
>>> return any label it would like attached.  Even if we don't do that
>>> now, esp_relabel_hook_entry needs to be renamed to something more
>>> generic; we will certainly want to add more fields to that structure
>>> later.
>>>
>> Starting with "unlabeled" is wrong, because it does not distinguish
>> an object created by security sensitive users and insensitive users,
>> for example. It is similar to relation's relowner is InvalidOid.
>>
>> I plan the security provider hook on the creation time works two things.
>> 1. It checks user's privilege to create this object.
>> 2. It returns security labels to be assigned.
>>
>> Then, the caller assigns these returned labels on the new object,
>> if one or more valid labels are returned.
>
> OK, let's give that a try and see how it looks.  I don't think that's
> in this version of the patch, right?
>
Yes, this version of the patch didn't support labeling on creation time
of database objects. It shall be added in separated patch.

>>> 7. I think we need to write and include in the fine documentation some
>>> "big picture" documentation about enhanced security providers.  Of
>>> course, we have to decide what we want to say.  But the SECURITY LABEL
>>> documentation is just kind of hanging out there in space right now; it
>>> needs to connect to a broad introduction to the subject.
>>>
>> OK, I'll try to describe with appropriate granularity.
>> Do we need an independent section in addition to the introduction of
>> SECURITY LABEL syntax?
>
> I think so.  I suggest a new chapter called "Enhanced Security
> Providers" just after "Database Roles and Privileges".
>
OK,

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>