Les ACL en sécurité interne (linux)

ACL : Access Control List
Analyse monocritère (le plus souvent), il peut être multicritère par le biais de script pour accéder à un service ou en complément des droits d’accès (rwx).
Exemple : le serveur crond
Les ACL pour ce service sont dans :
/etc/cron.allow
Ainsi, en général on la syntaxe suivante :
/…/servic.allow
+ Algorithme d’ACL
/…/servic.deny
Fonctionnement de l’algorithme d’ACL
L’algorithme d’ACL va d’abord vérifier la présence du fichier « service ».allow
Si .allow existe :
Si le fichier « .allow » est vide = personne n’est autorisé
« root » et/ou compte avec uid = 0 ont-il quand même accès ?
Si le fichier « .allow » n’est pas vide = les logins dedans sont autorisés
Cependant doit-on y ajouter « root » et les compte d’uid 0 ?
Si « .allow » n’existe pas, l’algorithme vérifie si « service ».deny existe :
Si .deny existe :
Si le fichier « .deny » est vide = tout le monde est autorisé
Si le fichier « .deny » n’est pas vide = liste des logins refusés
Que se passe-t-il s’il n’y a ni .allow ni .deny ?
Il faudra créer nous même un fichier .allow vide.
Les limites des ACL sont :
Lorsqu’il n’y a ni « allow » ni « deny » que fait-on ?
On impose un des deux fichiers (généralement le « allow » car il y a moins d’autorisés que de personnes refusées) que l’on va créer vide.
Si on ne met pas « root » (uid 0) dans « allow » a-t-il quand même les droits