Re: [RFC] Security label support - Mailing list pgsql-hackers

(2010/05/28 5:11), Robert Haas wrote:
> On Thu, May 27, 2010 at 4:01 PM, Tom Lane<tgl@sss.pgh.pa.us>  wrote:
>> Stephen Frost<sfrost@snowman.net>  writes:
>>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>>>> I'm not real sure that you want a dependency for a security label anyway
>>>> --- wouldn't that mean each label could only be used for one object?
>>
>>> Err, your question comes across to me like "if you added comments to
>>> pg_depend, you'd only be able to use a given comment X for one object?".
>>> Doesn't make alot of sense. :)
>>
>> Well, one of us is confused.  I thought the idea was that the same
>> security label would apply to many different objects.  If each object
>> has its own label, you're going to need an awfully large label cache
>> for performance to be sane.
> 
> I think this only makes sense when and if we implement row-level
> security.  The labels for SELinux are, say, 64 byte strings.  That's
> really not that big, if these are only being applied to objects like
> tables, and even columns.

Yes, as I noted on the idea [3], RLS with label requires a facility to
share a limited number of security labels, instead of flat text for
each user tuples. But it will need more code than the idea [2].

>  More to the point, ISTM a cache would be
> fairly useless anyway, because you have to pass the labels themselves
> to the OS to get an access control decision, which is also based on
> the type of object that you're doing something to and the operation
> you're doing to it.  It probably make sense to cache the results of
> the access-control lookup within a query - for example, if all the
> labels of a table you're accessing have the same label, just ask once
> for all of them, instead of individually for each one - but I can't
> see how you could usefully do much more than that.
> 
Right, as long as security policy is identical, it returns an identical
access control decision for the given pair of security label.
I plan to support access control decision cache, but it should be
implemented within ESP module, because it is SELinux specific.

BTW, SELinux also provide an interface to inform userspace applications
an invalidation message when security policy is reloaded, using netlink
socket. We entirely need a background worker process to monitor the socket,
but it should be in the future development.

> Now, if we were talking about row-level security, well, that's a whole
> different situation.  Now the space to store the individual labels
> might become burdensome.  But that's a problem for another day,
> hopefully a day when I'm out of town.
> 
Yes, let's tackle it in another day.

>>> The structure for pg_seclabel we were talking about would be very
>>> similar to pg_description, eg:
>>
>>> CREATE TABLE pg_seclabel (
>>>    objoid oid not null,
>>>    classoid oid not null,
>>>    objsubid integer not null,
>>>    label text
>>> );
>>
>>> We could move label into another table (eg: pg_labels) and then give an
>>> OID to each label and then store the label's OID in pg_seclabel.
>>
>> OK, but the notion that you would try to remove "orphan" pg_labels
>> entries seems entirely wrongheaded to me.  The labels would be
>> long-lived objects.
> 
> Now I'm confused.  Previously you complained about not having a
> garbage collection mechanism for labels - now you seem to be saying
> that we should never garbage collect.
> 
I'm also confused. What is the orphan label in the current pg_description
like design?
It has 1:1 map with a certain database object, so whenever we drop
the database object, its label entry shall be also dropped.
As long as database is not corrupt, no orphan labels will appear.

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