Forum Linux.noyau Capabilités

Posté par . Licence CC by-sa
2
7
juil.
2016

Bonjour,

je viens de lire un article très intéressant sur les "Capabilités" du Kernel.

http://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-164/Les-capabilities-sous-Linux

(je pense que c'est toujours d'actualité malgrès la date)

N'ayant ni le niveau d'instruction suffisant en informatique ni la qualité journalistique à laquelle DLFP m'habitue depuis toutes ces années je voulais partager cette trouvaille et surtout demander des précisions.

Les mécanisme de capabilités permettent la gestion granulaire des permissions d'exécutions des processus que l'on exécute sur un système.
Ils permettent de définir un contexte pour le bon déroulement d'un programme et donc d'en sécuriser les interractions en interne.

Est ce en quelque sorte un peu comme moi qui m'isole dans ma chambre (jaune) et qui à un moment vais me brancher sur un réseau sur la paire cuivrée pour initialiser une connection avec des gens et virtualiser leur présence ? Ce mécanisme définit il en quelque sorte les échanges possibles avec un tel programme ou un autre comme moi je vais lors de ma connection définir une interface et ses permissions relatives entre moi et un groupe ou des individus et fermer cette connection à la fin de la transmission ?

Je vois dans cette idée une forme de liberté apporté par un processus de sécurisation qui n'existe pas dans la réalité.

Au delà de ces considération philanthropique utilisez-vous ces mécanismes (ou d'autres) et si oui que vous apportent-ils ?

  • # Bonne idée mais...

    Posté par (page perso) . Évalué à 2.

    Je me suis amusé à faire la commande ack '\bCAP_' | perl -p -e 's/.*\b(CAP_[A-Z_]+).*$/$1/;' | sort | uniq -c | sort -n sur les sources de mon noyau. Cela ne donne pas des stats précises au centième mais un bon indicateur.

         10 CAP_SYSLOG
         11 CAP_MAC_OVERRIDE
         11 CAP_MKNOD
         12 CAP_SETGID
         12 CAP_SETUID
         12 CAP_UNICODE
         16 CAP_FOWNER
         16 CAP_FSETID
         16 CAP_IPC_LOCK
         16 CAP_SYS_NICE
         16 CAP_SYS_TTY_CONFIG
         19 CAP_LINUX_IMMUTABLE
         19 CAP_NET_BIND_SERVICE
         20 CAP_SYS_TIME
         21 CAP_SYS_PTRACE
         26 CAP_NET_RAW
         26 CAP_PRIVACY_ON
         40 CAP_MAC_ADMIN
         46 CAP_SYS_RESOURCE
         91 CAP_SYS_RAWIO
        419 CAP_NET_ADMIN
        523 CAP_SYS_ADMIN
    

    Je n'ai pas mis toutes les CAP qui sortent moins de 10 fois et qui sont en nombre très importantes… (Il y en a même pas mal qui ne sorte qu'une fois).

    Bilan : la bonne idée s'est transformée en quelques CAP_SYSADMIN, 4 ou 5 tout au plus. Bref, c'est un bel outil mais qui ne me semble pas du tout pouvoir être vraiment utilisé en profondeur pour de la sécurité à grande échelle. Les nouvelles voies comme secomp sont peut être plus prometteuse du point de vu d'un utilisateur.

    • [^] # Re: Bonne idée mais...

      Posté par . Évalué à 5. Dernière modification le 08/07/16 à 05:35.

      Comment arrives-tu à la conclusion que CAP_SYSADMIN ou 4-5 autres CAP_ réduisent cette bonne idée (je suppose que tu le justifie par le fait qu'elles sont sur-représentées par rapport aux autres et donc qu'elles seraient des capabilities "fourre-tout", c'est bien cela que tu voulais dire ?) alors qu'en même temps tu dis avoir ignoré un nombre important (combien?) qui ne le sont pas ? Par exemple, si mon programme n'aurait besoin que comme seul privilège la possibilité de binder un port <1024, ne serait pas CAP_NET_BIND_SERVICE un substitut efficace à un suid root ? Idem pour tout autre privilège accordé par un "capability" autre que CAP_SYS_ADMIN… Donc bref, j'ai l'impression que tu contredis, ou alors sois plus explicite stp :)

      • [^] # Re: Bonne idée mais...

        Posté par (page perso) . Évalué à 2.

        Je n'ai pas l'impression de me contredir. Certes CAP_NET_BIND_SERVICE permet d'avoir un serveur qui regarde sous les ports < 1024… Certes il y a plein de CAP intéressante. Mais en pratique et je l'avais lu quelques parts (LWN ?), les développeurs du noyau ne posent dans le code que quelques CAP_ du coup, le principe des CAP_ fait qu'il est peu utilisé…

        La ligne de commande que j'ai donné n'est pas parfaite mais j'ai regardé avant sur pas mal de ligne et globalement, l'erreur final n'est pas si grande. Fait un "grep CAP_" dans les sources et tu verras par toi même… Les chiffres sont là et il y a malheureusement/effectivement quelques CAP fourre-tout qui ne doivent pas être loin du bit suid en pratique…

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.