El modelo de seguridad de SELinux describe todas las reglas de control de acceso como relaciones entre una entidad sujeto (normalmente, un cliente de la base de datos) y una entidad objeto (como un objeto de la base de datos), cada una de las cuales se identifica mediante una etiqueta de seguridad. Si se intenta acceder a un objeto no etiquetado, el objeto se trata como si tuviera asignada la etiqueta unlabeled_t.

Actualmente, sepgsql permite asignar etiquetas de seguridad a esquemas, tablas, columnas, secuencias, vistas y funciones. Cuando sepgsql está en uso, las etiquetas de seguridad se asignan automáticamente a los objetos de base de datos admitidos en el momento de su creación. Esta etiqueta se denomina etiqueta de seguridad predeterminada y se decide de acuerdo con la política de seguridad del sistema, la cual toma como entrada la etiqueta del creador, la etiqueta asignada al objeto padre del nuevo objeto y, opcionalmente, el nombre del objeto construido.

Un nuevo objeto de base de datos básicamente hereda la etiqueta de seguridad del objeto padre, excepto cuando la política de seguridad tiene reglas especiales conocidas como reglas de transición de tipo (type-transition), en cuyo caso se puede aplicar una etiqueta diferente. Para los esquemas, el objeto padre es la base de datos actual; para las tablas, secuencias, vistas y funciones, es el esquema contenedor; para las columnas, es la tabla contenedora.

Para las tablas, se comprueba db_table:select, db_table:insert, db_table:update o db_table:delete para todas las tablas de destino referenciadas, según el tipo de sentencia; además, también se comprueba db_table:select para todas las tablas que contienen columnas referenciadas en la cláusula WHERE o RETURNING, como origen de datos para UPDATE, etc.

También se comprobarán los permisos a nivel de columna para cada columna referenciada. db_column:select se comprueba no solo en las columnas que se están leyendo mediante SELECT, sino en aquellas que se referencian en otras sentencias DML; también se comprobará db_column:update o db_column:insert para las columnas que están siendo modificadas por UPDATE o INSERT.

Por ejemplo, considera:

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

Aquí, se comprobará db_column:update para t1.x porque se está actualizando, se comprobará db_column:{select update} para t1.y porque se actualiza y se referencia a la vez, y se comprobará db_column:select para t1.z porque solo se referencia. También se comprobará db_table:{select update} a nivel de tabla.

Para las secuencias, se comprueba db_sequence:get_value cuando hacemos referencia a un objeto de secuencia mediante SELECT; sin embargo, ten en cuenta que actualmente no comprobamos los permisos en la ejecución de las funciones correspondientes como lastval().

Para las vistas, se comprobará db_view:expand, y luego se comprobarán otros permisos necesarios en los objetos que se expanden a partir de la vista, individualmente.

Para las funciones, se comprobará db_procedure:{execute} cuando el usuario intente ejecutar una función como parte de una consulta o mediante una invocación de acceso rápido (fast-path). Si esta función es un procedimiento de confianza, también se comprueba el permiso db_procedure:{entrypoint} para verificar si puede actuar como punto de entrada del procedimiento de confianza.

Para acceder a cualquier objeto de esquema, se requiere el permiso db_schema:search en el esquema contenedor. Cuando se hace referencia a un objeto sin calificación de esquema, no se buscará en los esquemas en los que este permiso no esté presente (al igual que si el usuario no tuviera el privilegio USAGE en el esquema). Si hay una calificación de esquema explícita, se producirá un error si el usuario no tiene el permiso necesario en el esquema especificado.

El cliente debe tener permiso para acceder a todas las tablas y columnas referenciadas, incluso si proceden de vistas que luego se expandieron, de modo que apliquemos reglas de control de acceso coherentes independientemente de la forma en que se haga referencia a los contenidos de la tabla.

El sistema de privilegios de base de datos predeterminado permite a los superusuarios de la base de datos modificar los catálogos del sistema mediante comandos DML y referenciar o modificar tablas toast. Estas operaciones están prohibidas cuando sepgsql está habilitado.

SELinux define varios permisos para controlar las operaciones comunes de cada tipo de objeto, como la creación, alteración, eliminación y reetiquetado de la etiqueta de seguridad. Además, varios tipos de objetos tienen permisos especiales para controlar sus operaciones características, como la adición o eliminación de entradas de nombre dentro de un esquema particular.

La creación de un nuevo objeto de base de datos requiere el permiso create. SELinux concederá o denegará este permiso basándose en la etiqueta de seguridad del cliente y en la etiqueta de seguridad propuesta para el nuevo objeto. En algunos casos, se requieren privilegios adicionales:

Cuando se ejecuta el comando DROP, se comprobará drop en el objeto que se está eliminando. También se comprobarán los permisos para los objetos eliminados indirectamente a través de CASCADE. La eliminación de objetos contenidos dentro de un esquema particular (tablas, vistas, secuencias y procedimientos) requiere adicionalmente el permiso remove_name en el esquema.

Cuando se ejecuta el comando ALTER, se comprobará setattr en el objeto que se está modificando para cada tipo de objeto, excepto para los objetos subsidiarios como los índices o disparadores (triggers) de una tabla, donde los permisos se comprueban en su lugar en el objeto padre. En algunos casos, se requieren permisos adicionales:

Los procedimientos de confianza son similares a las funciones definidoras de seguridad (security definer) o a los comandos setuid. SELinux proporciona una característica que permite que el código de confianza se ejecute utilizando una etiqueta de seguridad diferente a la del cliente, generalmente con el fin de proporcionar un acceso altamente controlado a datos sensibles (por ejemplo, se pueden omitir filas o se puede reducir la precisión de los valores almacenados). El hecho de que una función actúe o no como un procedimiento de confianza está controlado por su etiqueta de seguridad y por la política de seguridad del sistema operativo. Por ejemplo:

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

Las operaciones anteriores deben ser realizadas por un usuario administrador.

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)

En este caso, un usuario normal no puede hacer referencia a customer.credit directamente, pero un procedimiento de confianza show_credit le permite imprimir los números de tarjeta de crédito de los clientes con algunos de los dígitos enmascarados.

Es posible utilizar la característica de transición dinámica de dominio de SELinux para cambiar la etiqueta de seguridad del proceso del cliente (el dominio del cliente) a un nuevo contexto, si la política de seguridad lo permite. El dominio del cliente necesita el permiso setcurrent y también dyntransition del dominio antiguo al nuevo.

Las transiciones dinámicas de dominio deben considerarse con cuidado, porque permiten a los usuarios cambiar su etiqueta, y por tanto sus privilegios, a su elección, en lugar de hacerlo según lo dispuesto por el sistema (como en el caso de un procedimiento de confianza). Por lo tanto, el permiso dyntransition solo se considera seguro cuando se utiliza para cambiar a un dominio con un conjunto de privilegios menor que el original. Por ejemplo:

regression=# select sepgsql_getcon();
                    sepgsql_getcon
-------------------------------------------------------
 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
(1 row)

regression=# SELECT sepgsql_setcon('unconfined_u:unconfined_r:unconfined_t:s0-s0:c1.c4');
 sepgsql_setcon
----------------
 t
(1 row)

regression=# SELECT sepgsql_setcon('unconfined_u:unconfined_r:unconfined_t:s0-s0:c1.c1023');
ERROR:  SELinux: security policy violation

En este ejemplo anterior, se nos permitió cambiar del rango MCS más grande c1.c1023 al rango más pequeño c1.c4, pero se denegó el cambio de regreso.

Una combinación de transición dinámica de dominio y procedimiento de confianza permite un caso de uso interesante que se adapta al ciclo de vida típico de los procesos del software de pool de conexiones (connection pooling). Aunque su software de pool de conexiones no tenga permiso para ejecutar la mayoría de los comandos SQL, puede permitirle cambiar la etiqueta de seguridad del cliente mediante la función sepgsql_setcon() desde dentro de un procedimiento de confianza; eso debería requerir alguna credencial para autorizar la solicitud de cambio de la etiqueta del cliente. Después de eso, esta sesión tendrá los privilegios del usuario de destino, en lugar del gestor del pool de conexiones. El gestor del pool de conexiones puede revertir más tarde el cambio de etiqueta de seguridad utilizando de nuevo sepgsql_setcon() con un argumento NULL, invocado de nuevo desde un procedimiento de confianza con las comprobaciones de permisos adecuadas. El punto clave aquí es que solo el procedimiento de confianza tiene realmente permiso para cambiar la etiqueta de seguridad efectiva, y solo lo hace cuando se le proporcionan las credenciales adecuadas. Por supuesto, para un funcionamiento seguro, el almacén de credenciales (tabla, definición de procedimiento, o lo que sea) debe protegerse contra accesos no autorizados.

Rechazamos el comando LOAD en todos los casos, porque cualquier módulo cargado podría eludir fácilmente la aplicación de la política de seguridad.