Dans NetBSD, secmodel fournit une couche dédiée à la politique de sécurité du noyau. Son fonctionnement repose sur une idée assez précise : ne pas mélanger dans chaque composant du noyau la question de l’autorisation avec les règles utilisées pour prendre cette décision.
Lorsqu’un processus tente une opération protégée, le noyau peut transmettre une demande au mécanisme kauth(9). Cette demande décrit l’action concernée et son contexte. Les composants du modèle de sécurité examinent ensuite la requête et peuvent répondre par une autorisation, un refus ou un report de décision.
Cette organisation rend le système plus modulaire que de simples contrôles de privilèges dispersés dans le code du noyau. Le modèle historique BSD peut être conservé, tandis que d’autres mécanismes de contrôle peuvent être ajoutés sous forme de composants spécialisés.
Kauth et secmodel : deux niveaux pour prendre une décision
Kauth reçoit les demandes d’autorisation
kauth, abréviation de Kernel Authorization, est le mécanisme du noyau chargé de traiter les demandes liées aux droits.
Lorsqu’un programme tente une opération protégée, le noyau ne demande pas simplement « root ou utilisateur standard ? ». La requête est associée à un scope et à une action. Le scope indique le domaine concerné par l’autorisation, tandis que l’action précise ce que le processus cherche à faire.
Cette distinction est importante dans une architecture de sécurité. Une opération concernant les processus n’a pas forcément les mêmes règles qu’une opération concernant le réseau ou le système de fichiers.
Le schéma général peut être résumé ainsi :
| Étape | Composant | Fonction |
| 1 | Processus | Demande une opération |
| 2 | Noyau | Identifie le contrôle nécessaire |
| 3 | Kauth | Transmet la demande d’autorisation |
| 4 | Secmodel / listeners | Évalue les règles |
| 5 | Noyau | Autorise ou refuse l’opération |
Secmodel applique la politique de sécurité
secmodel intervient au niveau de la politique. Il fournit les composants qui déterminent comment les demandes reçues par kauth doivent être traitées.
Cette séparation évite de placer toutes les règles dans kauth lui-même. Kauth fournit le mécanisme de notification et d’autorisation, tandis que les modèles définissent les règles utilisées pour répondre aux demandes.
Un même mécanisme peut donc servir à plusieurs politiques de sécurité.
A lire aussi: Devenir expert en cybersécurité : les langages de programmation qu’il faut maitriser
Que signifient Allow, Deny et Defer ?
Les listeners participant à une décision peuvent retourner différents résultats. Les trois réponses les plus importantes sont allow, deny et defer.
Allow signifie que le composant autorise l’opération. Le noyau peut poursuivre son traitement.
Deny signifie que l’accès est refusé. L’opération protégée ne peut alors pas continuer.
Defer indique que le composant ne tranche pas immédiatement. La décision peut être examinée par d’autres listeners ou mécanismes concernés par la même requête.
Ce système est intéressant lorsqu’une politique de sécurité comporte plusieurs niveaux de contrôle. Tous les composants n’ont pas besoin de connaître l’ensemble des règles du système.
Un exemple avec les privilèges
Prenons un processus qui tente d’effectuer une opération normalement réservée à un utilisateur privilégié.
La requête arrive dans kauth. Le modèle de sécurité peut examiner l’identité du processus, ses privilèges et les restrictions actuellement actives. Si les conditions sont réunies, la réponse peut être allow. Dans le cas contraire, elle peut être deny.
Avec defer, le premier composant indique qu’il ne souhaite pas prendre la décision finale. Un autre listener peut alors examiner la même demande.
Une architecture modulaire au niveau du noyau
Des modèles chargés statiquement ou dynamiquement
L’une des caractéristiques intéressantes de secmodel est son architecture modulaire. Un modèle de sécurité peut être intégré directement au noyau lors de sa compilation ou être chargé comme module lorsque le système fonctionne.
Le second cas évite de reconstruire systématiquement un noyau complet lorsqu’un composant doit être ajouté.
Cette organisation concerne toutefois des composants du noyau. Il ne s’agit pas d’une simple extension utilisateur comparable à un paquet logiciel classique.
Des décisions pouvant utiliser différentes sources
Un modèle peut prendre sa décision à partir d’informations disponibles dans le noyau. Selon la conception du module, une politique peut également faire intervenir un mécanisme extérieur au noyau.
Cette possibilité ouvre des scénarios plus avancés : politique particulière pour une machine dédiée, contrôle des droits selon un rôle ou mécanisme d’autorisation utilisant des informations provenant d’un service externe.
Il faut néanmoins distinguer la possibilité technique de l’architecture réelle d’un système. Une politique de sécurité qui dépend d’un service externe ajoute nécessairement des questions de disponibilité, de latence et de gestion des erreurs.
Secmodel_bsd44 : le modèle traditionnel de NetBSD
Le modèle historique de type BSD
secmodel_bsd44 correspond au modèle destiné à reproduire le comportement de sécurité traditionnel associé à 4.4BSD.
Il regroupe plusieurs composants qui traitent chacun une partie des règles de sécurité. Cette organisation évite d’avoir un unique bloc responsable de toutes les décisions.
Parmi les composants importants figurent :
| Composant | Fonction |
| secmodel_bsd44 | Modèle de sécurité BSD traditionnel |
| secmodel_suser | Gestion des privilèges du super-utilisateur |
| secmodel_securelevel | Restrictions liées au niveau de sécurité |
| secmodel_extensions | Extensions de la politique BSD |
Secmodel_suser et le compte root
secmodel_suser traite les autorisations associées au super-utilisateur.
Dans le modèle UNIX traditionnel, l’utilisateur root dispose de privilèges très larges. Cette logique reste au cœur du modèle BSD44, mais elle ne signifie pas nécessairement que root peut tout faire dans toutes les circonstances.
C’est notamment ici que securelevel devient intéressant.
Securelevel : des restrictions qui peuvent toucher root
Le composant secmodel_securelevel ajoute des restrictions qui deviennent particulièrement importantes lorsque le système fonctionne avec un niveau de sécurité élevé.
Le principe historique est simple : certaines opérations sensibles doivent rester interdites même à un processus disposant des privilèges root.
Cette séparation répond à une problématique classique des systèmes UNIX : réduire les possibilités d’une compromission complète du compte administrateur en verrouillant certaines opérations sensibles.
Securelevel : pourquoi cette notion existe-t-elle ?
Un mécanisme destiné aux systèmes nécessitant davantage de verrouillage
Le niveau de sécurité peut être configuré afin de rendre certaines opérations plus difficiles à effectuer une fois le système démarré.
L’idée n’est donc pas de remplacer les permissions classiques des fichiers. securelevel intervient sur des opérations de niveau système qui dépassent les simples droits de lecture et d’écriture.
Dans certaines configurations, l’augmentation du niveau de sécurité peut rendre certaines modifications du système plus difficiles, notamment lorsqu’elles touchent des composants sensibles du noyau ou du stockage.
Root n’est donc pas synonyme de liberté absolue
C’est l’un des points les plus intéressants du modèle.
Dans un UNIX traditionnel :
UID 0 → privilèges très élevés
Mais avec les restrictions de sécurité appropriées :
UID 0 + securelevel → certaines opérations restent interdites
Le système dispose ainsi de deux notions distinctes : les privilèges associés à l’identité et les restrictions imposées par la politique de sécurité du noyau.
Secmodel_extensions : ajouter des comportements particuliers
Le module secmodel_extensions regroupe des extensions qui ne correspondent pas directement au comportement historique de base.
L’un des exemples connus concerne usermount, qui peut autoriser certains utilisateurs non privilégiés à monter des systèmes de fichiers lorsque les conditions prévues par la configuration sont réunies.
Cette séparation est intéressante pour l’administration d’un système : les extensions peuvent être traitées indépendamment des mécanismes fondamentaux associés à root et au securelevel.
Secmodel_sandbox et les politiques de sécurité personnalisées
Une architecture adaptée aux modèles expérimentaux
L’intérêt de secmodel apparaît encore davantage lorsqu’on quitte le modèle BSD44 traditionnel.
Le framework a notamment servi de base à des travaux autour de modèles de sandboxing. Le principe consiste à appliquer des restrictions particulières à certains processus afin de limiter les opérations qu’ils peuvent effectuer.
Un sandbox peut par exemple chercher à limiter :
- l’accès à certaines ressources ;
- certaines opérations système ;
- les interactions avec d’autres processus ;
- certaines actions réseau ;
- l’accès à des ressources protégées.
La logique de contrôle peut alors être différente de celle appliquée au reste du système.
Vers des modèles RBAC ou MAC
L’architecture de secmodel peut également servir à expérimenter des modèles qui s’éloignent du schéma traditionnel basé sur root.
Deux concepts sont particulièrement intéressants :
RBAC — Role-Based Access Control : les autorisations sont associées à des rôles. Un utilisateur reçoit un ou plusieurs rôles, lesquels déterminent les opérations autorisées.
MAC — Mandatory Access Control : les règles d’accès sont définies par une politique globale que l’utilisateur ne peut pas simplement contourner avec ses permissions classiques.
Ces modèles ne sont pas équivalents au modèle BSD44. Ils répondent à des besoins différents et demandent une conception beaucoup plus fine des politiques appliquées aux processus et aux ressources.
A voir également: Formation en cybersécurité : compétences, cursus, salaire et évolution de carrière
Pourquoi séparer le mécanisme d’autorisation et la politique ?
La principale force de cette architecture apparaît lorsqu’un système doit évoluer sans réécrire toutes les fonctions de sécurité du noyau.
Avec une séparation entre kauth et secmodel, le mécanisme chargé de transmettre les demandes peut rester relativement indépendant des règles utilisées pour prendre les décisions.
Cela donne une architecture comparable à :
Opération demandée → kauth → listeners → politique de sécurité → résultat
Cette séparation présente plusieurs intérêts techniques :
| Caractéristique | Intérêt |
| Modularité | Les politiques peuvent être séparées en composants |
| Extensibilité | De nouveaux modèles peuvent être développés |
| Isolation logique | Les règles ne sont pas dispersées dans toutes les fonctions |
| Chargement dynamique | Certains composants peuvent être chargés au fonctionnement |
| Compatibilité | Le modèle BSD traditionnel peut être conservé |
| Expérimentation | Des politiques différentes peuvent être testées |
Secmodel face au modèle classique des permissions UNIX
Il serait réducteur de considérer secmodel comme un simple remplacement des permissions UNIX.
Les permissions classiques concernent principalement les relations entre utilisateur, groupe et fichier. Elles permettent par exemple de déterminer si un utilisateur peut lire, écrire ou exécuter un fichier.
secmodel intervient à un niveau différent. Il peut traiter des demandes concernant des ressources et opérations du noyau qui ne se résument pas aux bits rwx.
| Mécanisme | Exemple de contrôle |
| Permissions UNIX | Lecture ou écriture d’un fichier |
| UID/GID | Identité du processus |
| Kauth | Demande d’autorisation du noyau |
| Secmodel | Politique appliquée à cette demande |
| Securelevel | Restrictions système supplémentaires |
Les mécanismes peuvent donc fonctionner ensemble plutôt que se remplacer.
Ce que secmodel change pour l’administration d’un système NetBSD
Pour un administrateur, secmodel devient surtout intéressant lorsque les permissions UNIX classiques ne suffisent plus à décrire la politique recherchée.
Une machine serveur peut conserver le modèle BSD44 traditionnel tout en utilisant les mécanismes de sécurité disponibles autour de securelevel. Un système destiné à une tâche particulière peut également recevoir une politique plus restrictive.
La distinction entre les différents composants facilite aussi l’analyse d’un problème d’autorisation. Lorsqu’une opération échoue, il faut regarder quelle demande kauth a été générée, quel scope est concerné, quels listeners interviennent et quelle règle a conduit au refus.
Cette méthode est beaucoup plus précise que de simplement vérifier si l’utilisateur est root.