Re: [RFC] Security label support

KaiGai,

* KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
> As we talked at the developer meeting on Ottawa, it needs to provide
> a capability to assign a short text identifier on database objects
> to support label based ESP (such as SELinux).
> So, I'd like to propose a few approaches to support security label
> as a draft of discussion.
[...]
> [2] Using OID as a key of text representation in separated catalog
> ------------------------------------------------------------------
>
> This idea is similar to pg_description/pg_shdescription.
> A new system catalog pg_seclabel and pg_shseclabel stores text form
> of labels for pair of the relation-Id, object-Oid and object-Subid.
> It does not damage to the schema of existing system catalog,

Right, this is the approach that was agreed to during various
discussions and is, I believe, what Robert is currently working on.

> It adds two new system catalogs; pg_seclabel (local) and pg_shseclabel (shared).

Do we really need a shared catalog initially? Right now, we're just
talking about labels for tables and columns. Let's not overcomplicate
this. We can always add it later.

> We also add a dependency between the labeled object and the security
> label itself. It also enables to clean up orphan labels automatically,
> without any new invention.

I agree that we need to address this. I am kind of curious how this is
handled for comments? It appears to be, but I don't see an entry in
pg_depend when a comment is added to an object, yet the entry in
pg_description disappears when a table is dropped. <Shrug>

> However, it also has a limitation from the viewpoint of long-term.
> >From the definition, OID of database objects are unique. So, we cannot
> share text form of labels even if massive number of database objects
> have an identical security label; it can lead waste of storage consumption
> because of the duplicated security labels. So, this idea shall be switched
> to the [3] when we support row-level security with ESP.
> But I think the idea [2] is reasonable in short-term development.

Row level security might not even use this catalog directly but perhaps
another one. That's a discussion for a much later time though.

> * SQL Statement
> ---------------
>
> It also need to provide SQL statement to manage security label of the database
> object. I plan the following statement to change the security label.
>
> ALTER xxx <name> SECURITY LABEL TO 'label';

Rather than adding more cruft around ALTER, I believe the plan is to add
a new top-level command (eg: 'SECURITY LABEL ON'), just like the COMMENT
ON syntax.

> When the ALTER command is executed, ESP module validate the given label,
> in addition to permission checks to relabel it.

> If no ESP module is available, the ALTER always raises a feature-not-supported
> error.

Right. We do need to identify what the hook needs to look like. I
would think just passing a pg_seclabel (or whatever) structure which
would represent the new row in the table (possibly replacing an existing
row, if one exists, but the hook can figure that out). The hook can
then figure out the user and any other information it needs to know
based on that and either allow or not allow the change.

> In my original SE-PostgreSQL design, it provided an option to specify
> an explicit security label in CREATE xxx statement, but I discarded
> the idea, because the implementation of CREATE statement has much
> variations for each object class (so the patch will be invasive),
> and it is a fungible functionality using ALTER.

As with other things, this could be done in a transaction rather than
cluttering up CREATE, etc, statements. Supporting a default label for
objects might be something which could be added later.

> * Pg_dump/Pg_restore support
> ----------------------------

We do need to include some kind of pg_dump/pg_restore support for this,
of course.

Thanks,

Stephen