Re: [v9.2] SECURITY LABEL on shared database object

2011/6/13 Robert Haas <robertmhaas@gmail.com>:
> On Mon, Jun 13, 2011 at 1:40 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>> 2011/6/13 Robert Haas <robertmhaas@gmail.com>:
>>> On Mon, Jun 13, 2011 at 12:24 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>>>> The attached patch is an update revision of security label support
>>>> for shared database objects.
>>>
>>> I'm kind of unexcited about this whole idea.  Adding a shared catalog
>>> for a feature that's only of interest to a small percentage of our
>>> user population seems unfortunate.
>>>
>>> Are there any other possible approaches to this problem?
>>>
>> If unexcited about the new shared catalog, one possible idea
>> is to add a new field to pg_database, pg_tablespace and
>> pg_authid to store security labels?
>>
>> The reason why we had pg_seclabel is to avoid massive amount
>> of modifications to system catalog. But only 3 catalogs to be
>> modified to support security label on shared object.
>
> I guess maybe my real question here is - what do you plan to do with
> those security labels, from a security perspective?  For example:
> roles.  The user's security contect AIUI is passed over from the
> remote side; his DAC role doesn't even enter into it from a MAC
> perspective.  Or does it?
>
The current primary target of security label of shared object is
to acquire control on databases.
It performs as a basis to compute default security label of
underlying objects, and I also plan to control when we open
the connection like ACL_CONNECT.
Right now, we assume any database has "system_u:object_r:sepgsql_db_t:s0",
then the default security label of schema objects are computed.
(See sepgsql_schema_post_create in contrib/sepgsql/schema.c)

Regarding to the pg_tablespace and pg_authid, I have a plan to
control DDL statements on these objects, However, its priority
is not higher than databases or other non-shared objects such
as tables or procedures.

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