sepgsql est un module chargeable ajoutant le support des contrôles d'accès par label basé sur la politique de sécurité de SELinux™.
![[Avertissement]](images/warning.png)
L'implémentation actuelle a des limitations importantes et ne force pas le contrôle d'accès pour toutes les actions. Voir Section F.38.6, « Limitations ».
Ce module s'intègre avec SELinux™ pour fournir une couche de vérification de sécurité supplémentaire qui va au-delà de ce qui est déjà fournit par PostgreSQL™. De la perspective de SELinux™, ce module permet à PostgreSQL™ de fonctionner comme un gestionnaire d'objet en espace utilisateur. Chaque accès à une table ou à une fonction initié par une requête DML sera vérifié par rapport à la politique de sécurité du système. Cette vérification est en plus des vérifications de droits SQL habituels effectuées par PostgreSQL™.
Les décisions de contrôle d'accès de SELinux™ sont faites en utilisant les labels de sécurité qui sont représentés par des chaînes comme system_u:object_r:sepgsql_table_t:s0. Chaque décision de contrôle d'accès implique deux labels : celui de l'utilisateur tentant de réaliser l'action et celui de l'objet sur lequel l'action est réalisée. Comme ces labels peuvent être appliqués sur tout type d'objet, les décisions de contrôle d'accès pour les objets stockés dans la base peuvent être (et avec ce module, sont) sujets au même critère général utilisé pour les objets de tout type (par exemple les fichiers). Ce concept a pour but de permettre la mise en place d'une politique centralisée pour protéger l'information quelque soit la façon dont l'information est stockée.
L'instruction SECURITY LABEL(7) permet d'affecter un label de sécurité à un objet de la base de données.
sepgsql peut seulement être utilisé sur Linux™ 2.6.28 ou ultérieur, avec SELinux™ activé. Il n'est pas disponible sur les autres plateformes. Vous aurez aussi besoin de libselinux™ ou ultérieur et de selinux-policy™ 3.9.13 ou ultérieur (même si certaines distributions peuvent proposer les règles nécessaires dans des versions antérieures de politique).
La commande sestatus vous permet de vérifier le statut de SELinux™. Voici un affichage standard :
$ sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 24 Policy from config file: targeted
Si SELinux™ est désactivé ou non installé, vous devez tout d'abord configurer ce produit avant d'utiliser ce module.
Pour construire ce module, ajoutez l'option --with-selinux dans votre commande configure lors de la compilation de PostgreSQL. Assurez-vous que le RPM libselinux-devel est installé au moment de la construction.
Pour utiliser ce module, vous devez ajouter sepgsql dans le paramètre shared_preload_libraries du fichier postgresql.conf. Le module ne fonctionnera pas correctement s'il est chargé d'une autre façon. Une fois que le module est chargé, vous devez exécuter sepgsql.sql dans chaque base de données. Cela installera les fonctions nécessaires à la gestion des labels de sécurité et affectera des labels initiaux de sécurité.
Voici un exemple montrant comment initialiser un répertoire de données avec les fonctions sepgsql et les labels de sécurité installés. Ajustez les chemins de façon approprié pour que cela corresponde à votre installation :
$ export PGDATA=/path/to/data/directory
$ initdb
$ vi $PGDATA/postgresql.conf
modifiez
#shared_preload_libraries = '' # (change requires restart)
en
shared_preload_libraries = 'sepgsql' # (change requires restart)
$ for DBNAME in template0 template1 postgres; do
postgres --single -F -c exit_on_error=true $DBNAME \
</usr/local/pgsql/share/contrib/sepgsql.sql >/dev/null
done
Notez que vous pourriez voir les notifications suivantes, suivant la combinaison de versions particulières de libselinux™ et de selinux-policy™.
/etc/selinux/targeted/contexts/sepgsql_contexts: line 33 has invalid object type db_blobs /etc/selinux/targeted/contexts/sepgsql_contexts: line 36 has invalid object type db_language /etc/selinux/targeted/contexts/sepgsql_contexts: line 37 has invalid object type db_language /etc/selinux/targeted/contexts/sepgsql_contexts: line 38 has invalid object type db_language /etc/selinux/targeted/contexts/sepgsql_contexts: line 39 has invalid object type db_language /etc/selinux/targeted/contexts/sepgsql_contexts: line 40 has invalid object type db_language
Ces messages ne sont graves et peuvent être ignorés sans conséquence.
Si le processus d'installation se termine sans erreur, vous pouvez commencer à lancer le serveur normalement.
Dû à la nature de SELinux™, exécuter les tests de régression pour sepgsql nécessite quelques étapes de configuration supplémentaires, certaines se faisant en tant qu'utilisateur root. Les tests de régression ne seront pas exécutés par une commande make check ou make installcheck ordinaire ; vous devez faire la configuration puis appeler le script de test manuellement. Les tests s'exécuteront dans le répertoire contrib/sepgsql du répertoire des sources de PostgreSQL, préalablement configuré. Bien que cela nécessite un arbre de construction, les tests sont conçus pour être exécutés par un serveur déjà installé, donc comparable à make installcheck, et non pas make check.
Tout d'abord, configurez sepgsql dans une base de données fonctionnelle d'après les instructions comprises dans Section F.38.2, « Installation ». Notez que l'utilisateur du système d'exploitation doit être capable de se connecter à la base de données en tant que superutilisateur sans authentification par mot de passe.
Ensuite, construisez et installez le paquet de politique pour les tests de régression. Le fichier sepgsql-regtest est un paquet de politique à but spécial. Il fournit un ensemble de règles à autoriser pendant les tests de régression. Il doit être construit à partir du fichier source de politique sepgsql-regtest.te, ce qui se fait en utilisant make avec un fichier Makefile fourni par SELinux. Vous aurez besoin de localiser le Makefile approprié sur votre système ; le chemin affiché ci-dessous est seulement un exemple. Une fois construit, installez ce paquet de politique en utilisant la commande semodule, qui charge les paquets de politique fournis dans le noyau. Si ce paquet est correctement installé, semodule -l doit lister sepgsql-regtest comme un paquet de politique disponible :
$ cd .../contrib/sepgsql $ make -f /usr/share/selinux/devel/Makefile $ sudo semodule -u sepgsql-regtest.pp $ sudo semodule -l | grep sepgsql
Puis, activez sepgsql_regression_test_mode. Nous n'activons pas toutes les règles du fichier sepgsql-regtest par défaut, pour la sécurité de votre système. Le paramètre sepgsql_regression_test_mode active les règles pour le lancement des tests de régression. Il peut être activé en utilisant la commande setsebool :
$ sudo setsebool sepgsql_regression_test_mode on $ getsebool sepgsql_regression_test_mode
Ensuite, vérifiez que votre shell est exécuté dans le domaine unconfined_t :
$ ./test_sepgsql
Ce script tentera de vérifier que vous avez fait correctement toutes les étapes de configuration, puis il lancera les tests de régression du module sepgsql.
Une fois les tests terminés, il est recommandé de désactiver le paramètre sepgsql_regression_test_mode :
$ sudo setsebool sepgsql_regression_test_mode off
Vous pouvez préférer supprimer complètement la politique sepgsql-regtest :
$ sudo semodule -r sepgsql-regtest
Ce paramètre active sepgsql™ pour qu'il fonctionne en mode permissif, quelque soit la configuration du système. La valeur par défaut est off. Ce paramètre es configurable dans le fichier postgresql.conf et sur la ligne de commande.
Quand ce paramètre est activé, sepgsql™ fonctionne en mode permissif, même si SELinux fonctionne en mode forcé. Ce paramètre est utile principalement pour des tests.
Ce paramètre active l'affichage de messages d'audit quelque soit la configuration de la politique. La valeur par défaut est off, autrement dit les messages seront affichés suivant la configuration du système.
La politique de sécurité de SELinux™ a aussi des règles pour contrôler la trace des accès. Par défaut, les violations d'accès sont tracées, contrairement aux accès autorisés.
Ce paramètre force l'activation de toutes les traces, quelque soit la politique du système.
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 est vérifié 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. Par exemple, avec :
UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
Dans ce cas, vous devez avoir db_table:select en plus de db_table:update car t1.a est référencée dans la clause WHERE. Les droits sur les colonnes seront aussi vérifiés pour chaque colonne référencée.
Pour les colonnes, db_column:select est vérifié, non seulement pour les colonnes lus en utilisant SELECT, mais aussi pour les colonnes référencées par d'autres instructions DML.
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.
UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
Dans ce cas, il vérifie db_column:update sur la colonne t1.x en cours de mise à jour, db_column:{select update} sur la colonne t1.y en cours de mise à jour et référencée, et db_column:select sur la colonne t1.z référencée uniquement dans la clause WHERE. 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é.
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.
Nous rejetons la commande LOAD(7) car tout module chargé pourrait facilement court-circuiter la politique de sécurité.
Dû aux restrictions d'implémentations, les droits DDL ne sont pas vérifiés.
Dû aux restrictions d'implémentations, les droits DCL ne sont pas vérifiés.
PostgreSQL™ ne supporte pas le contrôle d'accès au niveau ligne. Du coup, sepgsql ne le supporte pas non plus.
sepgsql n'essaie pas de cacher l'existence d'un objet particulier, même si l'utilisateur n'est pas autorisé à y accéder. Par exemple, nous pouvons inférer l'existence d'un objet invisible suite à un conflit de clé primaire, à des violations de clés étrangèes et ainsi de suite, même si nous ne pouvons pas accéder au contenu de ces objets. L'existence d'une table secrète ne peut pas être caché. Nous ne faisons que verrouiller l'accès à son contenu.
Cette page wiki fournit un bref aperçu, le concept de la sécurité, l'architecture, l'administration et les fonctionnalités futures.
Ce document fournit une connaissance large pour administrer SELinux™ sur vos systèmes. Il cible principalement Fedora mais n'y est pas limité.
Ce document répond aux questions fréquemment posées sur SELinux™. Il cible principalement Fedora mais n'y est pas limité.
KaiGai Kohei <kaigai@ak.jp.nec.com>
seg
