F.32. sepgsql

Le modèle de sécurité SELinux™ décrit toutes les règles de contrôle d'accès comme des relations entre une entité sujet (habituellement le client d'une base) et une entité objet (tel que l'objet base de données). Les deux sont identifiés par un label de sécurité. Si un accès à un objet sans label est tenté, l'objet est traité comme si le label unlabeled_t lui est affecté.

Actuellement, sepgsql autorise l'affectation de label de sécurité aux schémas, tables, colonnes, séquences, vues et fonctions. Quand sepgsql est en cours d'utilisation, des labels de sécurité sont automatiquement affectés aux objets de la base au moment de leur création. Ce label est appelé un label de sécurité par défaut et est configuré par la politique de sécurité du système, qui prend en entrée le label du créateur et le label affecté à l'objet parent du nouvel objet.

Un nouvel objet base de données hérite en gros du label de sécurité de l'objet parent, sauf quand la politique de sécurité a des règles spéciales, connues sous le nom de règles de transition, auquel cas un label différent est affecté. Pour les schémas, l'objet parent est la base de données ; pour les tables, séquences, vues et fonctions, il s'agit du schéma ; pour les colonnes, il s'agit de la table.

Pour les tables, db_table:select, db_table:insert, db_table:update ou db_table:delete sont vérifiés pour toutes les tables cibles référencées, suivant l'ordre de l'instruction. De plus, db_table:select est aussi vérifié pour toutes les tables qui contiennent des colonnes référencées dans la clause WHERE ou RETURNING, comme source de données d'un UPDATE, et ainsi de suite.

Les droits au niveau colonne seront aussi vérifiés pour chaque colonne référencée. column_db:select est vérifié sur les colonnes lues en utilisant SELECT, mais aussi celles référencées dans d'autres instructions DML ; column_db:update ou column_db:insert sear aussi vérifié pour les colonnes modifiées par UPDATE ou INSERT.

Bien sûr, il vérifie aussi db_column:update ou db_column:insert sur la colonne en cours de modification par UPDATE ou INSERT.

Par exemple :

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

Ici, column_db:update sera vérifié pour t1.x car elle est mise à jour, column_db:{select update} sera vérifié pour t1.y car elle est à la fois mise à jour et référencée, et column_db:select sera vérifié pour t1.z car elle est référencée. db_table:{select update} vérifiera aussi la table.

Pour les séquences, db_sequence:get_value est vérifié quand nous référençons un objet séquence en utilisant SELECT ; néanmoins, notez que nous ne vérifions pas les droits d'exécution sur les fonctions correspondantes, par exemple lastval().

Pour les vues, db_view:expand devrait être vérifié, et ensuite tous les autres droits des objets dus à l'aplatissement de la vue, individuellement.

Pour les fonctions, db_procedure:{execute} est défini mais n'est pas vérifié dans cettet version.

Le client doit être autorisé à accéder à toutes les tables et colonnes référencées, même si elles proviennent de vues qui ont été aplaties, pour pouvoir appliquer des règles de contrôles d'accès cohérentes indépendamment de la manère dont le contenu des tables est référencé.

Le système des droits de la base, par défaut, autorise les superutilisateurs de la base à modifier les catalogues systèmes en utilisant des commandes DML, et de référencer ou modifier les tables TOAST. Ces opérations sont interdites quand sepgsql est activé.

SELinux™ définit plusieurs droits pour contrôler les opérations standards pour chaque type d'objet : création, modification, suppression et changement du label de sécurité. De plus, certains types d'objet ont des droits spéciaux pour contrôler leur opérations caractéristiques : ajout ou suppression d'entrées dans un schéma particulier.

Lorsqu'une commande CREATE est exécutée, create sera vérifié sur l'objet en cours de construction pour chaque type d'objet. Un label de sécurité par défaut sera affecté au nouvel objet base de données, et le droit create sera vérifié sur la partie de labels de sécurité du client et de l'objet lui-même. Nous prenons en compte CREATE TABLE(7) pour construire une table et les colonnes sous-jacentes dans le même temps, donc les utilisateurs doivent avoir les droits de créer la table et ses colonnes.

Quelques vérifications supplémentaires sont appliquées suivant le type des objets. Sur CREATE DATABASE(7), le droit getattr sera vérifié sur la base de donnée source ou sur la base de données modèle de la nouvelle base de données, pas seulement le droit create sur une nouvelle base. À la création d'objets dans un schéma particulier (table, vue, séquence et procédure), add_name sera aussi vérifié sur le schéma, et pas seulement create sur le nouvel objet.

Quand la commande DROP est exécutée, drop sera vérifié sur l'objet qui doit être supprimé, quelque soit le type de l'objet. Les droits seront aussi véifiés pour les objets supprimés indirectement via CASCADE. La suppression des objets contenus dans un schéma particulier (tables, vues, séquences et procédures) nécessite en plus le droit remove_name dans le schéma.

Quand la commande SECURITY LABEL(7) est exécutée, setattr et relabelfrom devraient être vérifiés sur l'objet en cours de labelisation avec un ancien label de sécurité, puis relabelto sur le nouveau label de sécurité fourni.

Dans le cas où plusieurs fournisseurs de labels sont installés et que l'utilisateur essaie de configurer un label de sécurité qui n'est pas géré par SELinux™, seul setattr devrait être vérifié ii. Ceci n'est pas fait dû à des restrictions de l'implémentation.

Les procédures de confiance sont similaires aux fonctions dont la sécurité est définie à la création ou aux commandes set-uid. SELinux™ propose une fonctionnalité qui permet d'autoriser un code de confiance à s'exécuter en utilisant un label de sécurité différent de celui du client, généralement pour donner un accès hautement contrôlé à des données sensibles (par exemple, des lignes peuvent être omises ou la précision des valeurs stockées peut être réduite). Que la fonction agisse ou pas comme une procédure de confiance est contrôlé par son label de sécurité et la politique de sécurité du système d'exploitation. Par exemple :

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

Les opérations ci-dessus doivent être réalisées par un utilisateur administrateur.

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)

Dans ce cas, un utilisateur standard ne peut pas faire référence à customer.credit directement mais une procédure de confiance comme show_credit lui permet d'afficher le numéro de carte de crédit des clients, avec quelques chiffres masqués.

Il est possible d'utiliser la fonctionnalité de transition de domaine dynamique de SELinux pour basculer le label de sécurité du processus client, le domaine client, vers un nouveau contexte, s'il s'avère que c'est autorisé par la politique de sécurité. Le domaine client a besoin du droit setcurrent ainsi que du droit dyntransition de l'ancien domaine vers le nouveau domaine.

Les transitions de domaine dynamique doivent être considérées avec attention car elles permettent aux utilisateurs de basculer leur label, et du coup leur droits, quand ils le souhaitent, plutôt que (dans le cas d'une procédure de confiance) lorsque c'est demandé par le système. Du coup, le droit dyntransition est seulement considéré sûr quand il est utilisé pour basculer vers un domaine avec un plus petit ensemble de droits que le domaine original. Par exemple :

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

Dans l'exemple ci-dessus, nous sommes autorisés à basculer du gros intervalle MCS c1.c1023 vers l'intervalle c1.c4 beaucoup plus petit. Par contre, la bascule inverse est interdite.

Une combinaison de transition de domaine dynamique et de procédure de confiance permet un cas d'utilisation intéressant qui correspond au cycle de vie typique d'un processus pour un logiciel de pooling de connexions. Même si votre pooler de connexions n'est pas autorisé à exécuter la plupart des commandes SQL, vous pouvez l'autoriser à basculer le label de sécurité du client en utilisant la fonction sepgsql_setcon() à l'intérieur d'une procédure de confiance. Après cela, cette session aura les droits de l'utilisateur cible plutôt que ceux du pooler de connexions. Le pooler de connexions peut ensuite annuler le changement du label de sécurité en utilisant de nouveau sepgsql_setcon() avec l'argument NULL, encore une fois en l'appelant à partir d'une procédure de confiance avec les droits appropriés. Le point ici est que seule la procédure de confiance a réellement le droit de modifier le label de sécurité en cours et ne le fait que si autorisé. Bien sûr, pour un traitement sécurisé, le stockage des autorisations (table, définition de procédure, ou autres) doit être protégé des accès non autorisés.

Nous rejetons la commande LOAD(7) car tout module chargé pourrait facilement court-circuiter la politique de sécurité.