F.40. sepgsql

F.40.5.1. Controlled Object Classes

The security model of SELinux describes all the access control rules as a relationship between a subject entity (typically, it is a client of database) and an object entity, each of which is identified by a security label. If access to an unlabelled object is attempted, the object is treated as if it were assigned the label unlabeled_t.

Currently, sepgsql allows security labels to be assigned to schemas, tables, columns, sequences, views, and functions. When sepgsql is in use, security labels are automatically assigned to supported database objects at creation time. This label is called as a default security label, being decided according to the system security policy, which takes as input the creator's label and the label assigned to the new object's parent object.

A new database object basically inherits the security label of the parent object, except when the security policy has special rules known as type-transition rules, in which case a different label may be applied. For schemas, the parent object is the current database; for columns, it is the corresponding table; for tables, sequences, views, and functions, it is the containing schema.

F.40.5.2. DML Permissions

For tables, db_table:select, db_table:insert, db_table:update or db_table:delete is checked for all the referenced target tables depending on the sort of statement; in addition, db_table:select is also checked for all the tables that contain the columns referenced in the WHERE or RETURNING clause, as a data source of UPDATE, and so on.

UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;

In this case, we must have db_table:select in addition to db_table:update, because t1.a is referenced within the WHERE clause. Column-level permissions will also be checked for each referenced column.

The client must be allowed to access all referenced tables and columns, even if they originated from views which were then expanded, so that we apply consistent access control rules independent of the manner in which the table contents are referenced.

For columns, db_column:select is checked on not only the columns being read using SELECT, but being referenced in other DML statements.

Of course, it also checks db_column:update or db_column:insert on the column being modified by UPDATE or INSERT.

UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;

In this case, it checks db_column:update on the t1.x being updated, db_column:{select update} on the t1.y being updated and referenced, and db_column:select on the t1.z being only referenced in the WHERE clause. db_table:{select update} will also be checked at the table level.

For sequences, db_sequence:get_value is checked when we reference a sequence object using SELECT; however, note that we do not currently check permissions on execution of corresponding functions such as lastval().

For views, db_view:expand shall be checked, then any other corresponding permissions shall be also checked on the objects being expanded from the view, individually.

For functions, db_procedure:{execute} is defined, but not checked in this version.

The default database privilege system allows database superusers to modify system catalogs using DML commands, and reference or modify toast tables. These operations are prohibited when sepgsql is enabled.

F.40.5.3. DDL Permissions

On SECURITY LABEL command, setattr and relabelfrom shall be checked on the object being relabeled with an old security label, then relabelto on the supplied new security label.

In the case where multiple label providers are installed and the user tries to set a security label, but is not managed by SELinux, only setattr should be checked here. This is currently not checked due to implementation restrictions.

F.40.5.4. Trusted Procedure

Trusted procedures are similar to security definer functions or set-uid commands. SELinux provides a feature to allow trusted code to run using a security label different from that of the client, generally for the purpose of providing highly controlled access to sensitive data (e.g. rows might be omitted, or the precision of stored values might be reduced). Whether or not a function acts as a trusted procedure is controlled by its security label and the operating system security policy. For example:

postgres=# CREATE TABLE customer (
               cid     int primary key,
               cname   text,
               credit  text
           );
CREATE TABLE
postgres=# SECURITY LABEL ON COLUMN customer.credit
               IS 'system_u:object_r:sepgsql_secret_table_t:s0';
SECURITY LABEL
postgres=# CREATE FUNCTION show_credit(int) RETURNS text
             AS 'SELECT regexp_replace(credit, ''-[0-9]+$'', ''-xxxx'', ''g'')
                        FROM customer WHERE cid = $1'
           LANGUAGE sql;
CREATE FUNCTION
postgres=# SECURITY LABEL ON FUNCTION show_credit(int)
               IS 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0';
SECURITY LABEL

The above operations should be performed by an administrative user.

postgres=# SELECT * FROM customer;
ERROR:  SELinux: security policy violation
postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
 cid | cname  |     show_credit
-----+--------+---------------------
   1 | taro   | 1111-2222-3333-xxxx
   2 | hanako | 5555-6666-7777-xxxx
(2 rows)

In this case, a regular user cannot reference customer.credit directly, but a trusted procedure show_credit enables us to print the credit card number of customers with some of the digits masked out.

F.40.5.5. Miscellaneous

We reject the LOAD command across the board, because any module loaded could easily circumvent security policy enforcement.