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.
An example of label: "system_u:object_r:sepgsql_ro_table_t:s0".
The format/contains/meanings of the security label shall be parsed
and validated by ESP module, so all we need to do is associate such a
short text on a certain database. It is quite similar to COMMENT ON.
I don't want to support multiple labels of an object in this stage,
because it makes ESP interfaces more complex and it is unclear whether
it is actually wanted. For example, OS does not support multiple MAC
features concurrently.
Here are a few idea to support security labels.
In this stage, I think the idea of [2] is most reasonable for us.
(Perhaps, I guess Stephen has same opinion, because the idea was
originally came from him.)
[1] Inject a text label field to every system catalog
-----------------------------------------------------
This idea tries to add a new field to the schema of existing system
catalog.
Its implementation will be simple at first, however, it will be
entirely painful to modify every system catalog definitions and
(typically) CreateXXXX() functions under the src/backend/commands/.
I doubt it is a correct way, even if short-term development.
It will be reasonabel just only conceptual development.
[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,
It adds two new system catalogs; pg_seclabel (local) and pg_shseclabel (shared).
The catalogs shall be declared as follows:
CATALOG(pg_seclabel, 3037) BKI_WITHOUT_OIDS
{
Oid relid; /* OID of the catalog containing the object */
Oid objid; /* OID of the object itself */
int4 subid; /* column number, or 0 if unused */
text label; /* text form of security label */
} FormData_pg_seclabel;
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.
The related code will be stored in src/backend/catalog/pg_seclabel.c.
It provides an internal interface to assign a security label on
a certain database object when creation or relabeling.
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.
[3] Using security-Id as a key of text representation in separated catalog
--------------------------------------------------------------------------
This idea is a derivation from the idea of [2].
It also stores text form of labels into pg_seclabel/pg_shseclabel, but it
shall be identified with a pair of relation-Id and security-Id which is
newly supported.
The security-Id shall be stored within padding area of HeapTupleHeader like
object-Id. But, unlike object-Id, it does not need to be unique for each tuples.
It allows multiple tuples has same security-Id that is related to a certain
text form of security label. It means we can reduce waste of storage due to
the duplicated labels in text (Note, massive number of objects tend to share
a limited number of labels in general).
So, this approach has advantage toward the idea of [2], however, it needs more
code to be implemented/reviewed than [2], such as management of security-Id,
reclaim of orphan labels and so on.
Therefore, it is not feasible at the statring-up stage, as long as row-level
security with ESP is not available.
* 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';
(For columns)
ALTER TABLE <name> ALTER <column> SECURITY LABEL TO 'label';
The 'xxx' part is replaced by an object class, such as TABLE, SCHEMA and so on.
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.
Example)
ALTER TABLE t1 SECURITY LABEL TO 'system_u:object_r:sepgsql_ro_table_t:s0';
ALTER SCHEMA kaigai SECURITY LABEL TO 'user_u:object_r:sepgsql_schema_t:s0';
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.
* Pg_dump/Pg_restore support
----------------------------
We can learn from the representation of object comments.
It uses "COMMENT" section to represent a description of a certain database
object, and the section depends on the object owning the comment.
In similar way, we newly add "LABEL" section to represent a security label
of a certain database object, and it depends on the object to be labeled.
Then, the object will be labeled using the ALTER xxx SECURITY LABEL TO
statement.
It also allow to turn on/off restoring a dumpfile with security label using
command line argument, like --no-privileges.
But the label of tuples within user tables is an issue in the future.
Thanks,
--
KaiGai Kohei <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
