Модель безопасности SELinux описывает все правила контроля доступа как отношения между субъектным сущностями (обычно клиентом базы данных) и объектными сущностями (такими как объект базы данных), каждая из которых идентифицируется меткой безопасности. Если производится попытка доступа к объекту без метки, объект рассматривается так, как если бы ему была назначена метка unlabeled_t.

В настоящее время sepgsql позволяет назначать метки безопасности схемам, таблицам, столбцам, последовательностям, представлениям и функциям. Когда sepgsql используется, метки безопасности автоматически назначаются поддерживаемым объектам базы данных при их создании. Эта метка называется меткой безопасности по умолчанию и определяется в соответствии с политикой безопасности системы, которая принимает в качестве входных данных метку создателя, метку, назначенную родительскому объекту нового объекта, и, при необходимости, имя созданного объекта.

Новый объект базы данных в основном наследует метку безопасности родительского объекта, за исключением случаев, когда для политики безопасности установлены специальные правила, известные как правила типового перехода, в таком случае может быть применена другая метка. Для схем родительским объектом является текущая база данных; для таблиц, последовательностей, представлений и функций - это содержащая схема; для столбцов - это содержащая таблица.

Для таблиц, db_table:select, db_table:insert, db_table:update или db_table:delete проверяются для всех целевых целевых таблиц в зависимости от типа оператора; кроме того, db_table:select также проверяется для всех таблиц, содержащих столбцы, на которые ссылаются в предложении WHERE или RETURNING, как источник данных для UPDATE и т. д.

Права на уровне столбцов также будут проверяться для каждого целевого столбца. db_column:select проверяется не только для столбцов, которые считываются с помощью SELECT, но и для тех, которые используются в других операторах DML; db_column:update или db_column:insert также будут проверяться для столбцов, изменяемых с помощью UPDATE или INSERT.

Например, рассмотрим:

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

Здесь будет проверяться db_column:update для t1.x, так как он обновляется, будет проверяться db_column:{select update} для t1.y, так как он обновляется и ссылается на него, и будет проверяться db_column:select для t1.z, так как он только ссылается на него. db_table:{select update} также будет проверяться на уровне таблицы.

Для последовательностей, db_sequence:get_value проверяется, когда мы ссылаемся на объект последовательности с помощью SELECT; однако, обратите внимание, что в настоящее время мы не проверяем разрешения на выполнение соответствующих функций, таких как lastval().

Для представлений будет проверяться db_view:expand, а затем любые другие необходимые разрешения будут проверяться на объектах, расширяемых из представления, индивидуально.

Для функций, при выполнении функции в рамках запроса или с использованием быстрого вызова, будет проверяться db_procedure:{execute}. Если эта функция является доверенной процедурой, также будет проверяться разрешение db_procedure:{entrypoint} для определения возможности использования в качестве точки входа доверенной процедуры.

Для доступа к любому объекту схемы требуется разрешение db_schema:search на содержащую схему. Если объект ссылается без указания схемы, то схемы, на которых отсутствует это разрешение, не будут искаться (как если бы у пользователя не было привилегии USAGE на схему). Если явно указано квалификация схемы, то возникнет ошибка, если у пользователя нет необходимого разрешения на указанную схему.

Клиенту должно быть разрешено получить доступ ко всем целевым таблицам и столбцам, даже если они происходят из представлений, которые затем были развернуты, чтобы мы могли применять последовательные правила контроля доступа, независимо от способа ссылки на содержимое таблицы.

Система привилегий базы данных по умолчанию позволяет суперпользователям базы данных изменять системные каталоги с помощью команд DML и ссылаться или изменять таблицы toast. Эти операции запрещены, когда включен sepgsql.

SELinux определяет несколько разрешений для управления общими операциями для каждого типа объекта, такими как создание, изменение, удаление и изменение метки безопасности. Кроме того, у нескольких типов объектов есть специальные разрешения для управления их характерными операциями, такими как добавление или удаление записей имен в определенной схеме.

Создание нового объекта базы данных требует разрешения create. SELinux будет предоставлять или отклонять это разрешение на основе метки безопасности клиента и предлагаемой метки безопасности для нового объекта. В некоторых случаях требуются дополнительные привилегии:

Когда выполняется команда DROP, будет проверено наличие drop на удаляемом объекте. Также будут проверены разрешения для объектов, удаляемых косвенно с помощью CASCADE. Удаление объектов, содержащихся в определенной схеме (таблицы, представления, последовательности и процедуры), также требует наличия remove_name на схеме.

Когда выполняется команда ALTER, для каждого типа объекта, кроме дополнительных объектов, таких как индексы или триггеры таблицы, разрешение setattr будет проверяться на изменяемом объекте, в то время как разрешения проверяются на родительском объекте. В некоторых случаях требуются дополнительные разрешения.

Доверенные процедуры похожи на функции с определенными правами безопасности или команды setuid. SELinux предоставляет возможность запускать доверенный код с использованием метки безопасности, отличной от метки клиента, обычно с целью обеспечения высококонтролируемого доступа к конфиденциальным данным (например, строки могут быть не указаны или точность хранящихся значений может быть снижена). Вопрос о том, является ли функция доверенной процедурой, контролируется ее меткой безопасности и политикой безопасности операционной системы. Например:

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

Все вышеуказанные операции должен выполнять административный пользователь.

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)

В этом случае обычный пользователь не может ссылаться напрямую на customer.credit, но доверенная процедура show_credit позволяет пользователю печатать номера кредитных карт клиентов с некоторыми скрытыми цифрами.

Возможно использовать функцию динамического перехода между доменами SELinux для изменения метки безопасности процесса клиента, домена клиента, на новый контекст, если это разрешено политикой безопасности. Для этого домен клиента должен иметь разрешение setcurrent и также dyntransition от старого к новому домену.

Следует тщательно продумать все динамические переходы между доменами, поскольку они позволяют пользователям переключаться между метками и, следовательно, привилегиями по своему усмотрению, а не (как в случае с доверенной процедурой) по требованию системы. Таким образом, разрешение dyntransition считается безопасным только при использовании для перехода к домену с меньшим набором привилегий, чем у исходного. Например:

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

В этом примере нам было разрешено переключиться с более широкого диапазона MCS c1.c1023 на более узкий диапазон c1.c4, но обратное переключение было запрещено.

Сочетание динамического перехода домена и доверенной процедуры позволяет интересное использование, которое соответствует типичному жизненному циклу программного обеспечения для пула подключений. Даже если ваше программное обеспечение для пула подключений не может выполнять большинство SQL-команд, вы можете разрешить ему переключать метку безопасности клиента с помощью функции sepgsql_setcon() изнутри доверенной процедуры; для этого должны быть предоставлены некоторые учетные данные для авторизации запроса на переключение метки клиента. После этого сессия будет иметь привилегии целевого пользователя, а не пула подключений. Пул подключений позже может отменить изменение метки безопасности, снова используя sepgsql_setcon() с аргументом NULL, снова вызванной изнутри доверенной процедуры с соответствующей проверкой разрешений. Суть в том, что только доверенная процедура имеет разрешение на изменение эффективной метки безопасности и делает это только при наличии правильных учетных данных. Конечно, для безопасной работы хранилище учетных данных (таблица, определение процедуры или что-либо еще) должно быть защищено от несанкционированного доступа.

Мы отклоняем команду LOAD в общем порядке, потому что любой загруженный модуль может легко обойти механизм обеспечения безопасности.