D'une part sont objectif initial n'est en aucun cas de faire des politiques d' Access Control, à la différence de SELinux (qui est plus pensé sur le modèle des controles d'accès aux systèmes de fichiers/ gestion par uid/gid au sens étendu... - il fait bien plus de choses évidement, je parle de modèle conceptuel).
Theo de Raadt s'est toujours oposé à l'ajout de solution MAC dans Open, car il considère que ce ne sont pas vraiment des outils de sécurité mais plutot de politique / gestion des users / ... qui complexifient le code et la tache des admins de façon malsaine.
Systrace est une sorte de "firewall" pour les appels systèmes : on peut autoriser, pour telle appli, tel syscall à être éxecuté, avec tels arguments seulement (on peut utiliser des wilcards) et par tel utilisateur seulement...
Il y a aussi des "meta" syscalls, qui regroupent des ensembles d'appels systèmes similiaires, comme "native-fsread" pour fopen/fdreopen/lstat/... ex de rules :
native-bind: sockaddr match "inet-*:6667" then permit, if user != root
native-fsread: filenamenative-fsread: filename eq "/var/run/*" then permit
native-setegid: gid eq "70" then permit
Mais systrace n'ajoute rien à posix en termes de controle d'accès au fs par exemple.
Son avantage (à mon avis) c'est qu'il est très clair et simple à utiliser (du coup on arrive à faire des polices super précises). Jettez un oeil à un exemple de police systrace, vous verrez comme c'est évident au premier coup d'oeil.
Son gros désavantage c'est qu'il est moins puissant, moins fin, et encore plus lent que SElinux. Et je ne suis pas sur que la version Linux soit maintenue (la version BSD l'est).
Pour revenir à SELinux, récement Red Hat a annoncé qu'ils préparent une certification pour être autorisés à fournir du soft à l'armée/au NSA, et qu'à cette fin ils integreront SELinux dans la prochaine RHEL (comme actuellement dans Fedora). Je ne sait pas si c'est lié, mais maintenant SC a un beau moyen de pression.
Btw je me demande à chaque fois si le fait que RH ai embauché la majorité des developpeurs noyau qui décident n'est pas ce qui a permis à la très tarabiscoté solution LSM/SELinux de s'imposer dans le noyau officiel (devant les solutions alternatives, type grsecurity ou rbac, plus simples et parfois plus complétes, mais moins "corporates" ; plus orientées sécurité et moins orientées "certifications")...
[^] # Re: la base: droits supplémentaires sur les appels systemes
Posté par herodiade . En réponse à la dépêche SELinux en danger ?. Évalué à 9.
D'une part sont objectif initial n'est en aucun cas de faire des politiques d' Access Control, à la différence de SELinux (qui est plus pensé sur le modèle des controles d'accès aux systèmes de fichiers/ gestion par uid/gid au sens étendu... - il fait bien plus de choses évidement, je parle de modèle conceptuel).
Theo de Raadt s'est toujours oposé à l'ajout de solution MAC dans Open, car il considère que ce ne sont pas vraiment des outils de sécurité mais plutot de politique / gestion des users / ... qui complexifient le code et la tache des admins de façon malsaine.
Systrace est une sorte de "firewall" pour les appels systèmes : on peut autoriser, pour telle appli, tel syscall à être éxecuté, avec tels arguments seulement (on peut utiliser des wilcards) et par tel utilisateur seulement...
Il y a aussi des "meta" syscalls, qui regroupent des ensembles d'appels systèmes similiaires, comme "native-fsread" pour fopen/fdreopen/lstat/... ex de rules :
native-bind: sockaddr match "inet-*:6667" then permit, if user != root
native-fsread: filenamenative-fsread: filename eq "/var/run/*" then permit
native-setegid: gid eq "70" then permit
Mais systrace n'ajoute rien à posix en termes de controle d'accès au fs par exemple.
Son avantage (à mon avis) c'est qu'il est très clair et simple à utiliser (du coup on arrive à faire des polices super précises). Jettez un oeil à un exemple de police systrace, vous verrez comme c'est évident au premier coup d'oeil.
Son gros désavantage c'est qu'il est moins puissant, moins fin, et encore plus lent que SElinux. Et je ne suis pas sur que la version Linux soit maintenue (la version BSD l'est).
Pour revenir à SELinux, récement Red Hat a annoncé qu'ils préparent une certification pour être autorisés à fournir du soft à l'armée/au NSA, et qu'à cette fin ils integreront SELinux dans la prochaine RHEL (comme actuellement dans Fedora). Je ne sait pas si c'est lié, mais maintenant SC a un beau moyen de pression.
Btw je me demande à chaque fois si le fait que RH ai embauché la majorité des developpeurs noyau qui décident n'est pas ce qui a permis à la très tarabiscoté solution LSM/SELinux de s'imposer dans le noyau officiel (devant les solutions alternatives, type grsecurity ou rbac, plus simples et parfois plus complétes, mais moins "corporates" ; plus orientées sécurité et moins orientées "certifications")...