Quand a systrace, cela ne permet, a ma connaissance (et d'après les messages de l'auteur), uniquement de contrôller les appels systeme (syscalls), sans aucun modèle de sécurité sous-jacent
En fait les policies de systrace permettent de spécifier ce que tel programme de tel utilisateur a le droit de faire en matière de syscall. C'est deja pas mal, car cela peut concerner par exemple le login-shell et donc toute une session de cet utilisateur, ou bien encore spécifiquement ses programmes ayant accès à internet et donc exploitables à distance.
De plus la génération interactive des policies de systrace est plutot sympa.
Mais RSBAC déja cité donne accès à un grand nombre de modèles peu éloignés de type/domain: Several well-known and new security models, e.g. MAC, ACL and RC http://rsbac.org/why(...)
Le controversé LinuxSecurityModule permet à chacun d'implémenter facilement un nouveau modèle sans avoir à faire de patch du noyau. Il permet d'installer ses propres callbacks dans chaque syscall.
[^] # Re: la base: droits supplémentaires sur les appels systemes
Posté par free2.org . En réponse à la dépêche SELinux en danger ?. Évalué à 5.
En fait les policies de systrace permettent de spécifier ce que tel programme de tel utilisateur a le droit de faire en matière de syscall. C'est deja pas mal, car cela peut concerner par exemple le login-shell et donc toute une session de cet utilisateur, ou bien encore spécifiquement ses programmes ayant accès à internet et donc exploitables à distance.
De plus la génération interactive des policies de systrace est plutot sympa.
Mais RSBAC déja cité donne accès à un grand nombre de modèles peu éloignés de type/domain:
Several well-known and new security models, e.g. MAC, ACL and RC
http://rsbac.org/why(...)
Le controversé LinuxSecurityModule permet à chacun d'implémenter facilement un nouveau modèle sans avoir à faire de patch du noyau. Il permet d'installer ses propres callbacks dans chaque syscall.