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

On Mon, Jun 13, 2011 at 2:33 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> 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.

Hmm, OK.  I guess what I'm not sure about is - how much should we
worry about the fact that this creates several more shared (and
therefore nailed?) system catalogs?  Anyone have an opinion on that?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company