Vous n'êtes pas identifié(e).
Pages : 1
Sauf que ces commandes ont tous les pouvoirs, une fois qu'elles tournent en root, alors que ce n'est pas, toujours, nécessaire.
On a, donc, décidé de fractionner les privilèges root en une trentaines de privilèges partiels que l'on appelle capacités.
Comme pour le bit setuid, on peut appliquer ces capacités sur les fichiers (dans les attributs étendus) grâce à la commande "setcap". Par contre, les processus ont, aussi, des capacités.
Il existe une page de manuel en français concernant les capacités: http://manpages.ubuntu.com/manpages/bio … ies.7.html
Les capacités sont utilisées par les containers comme LXC.
La commande ping n'a plus de bit suid et utilise, maintenant, la capacité cap_net_raw. Vous pouvez le vérifier en lançant la commande "getcap /bin/ping".
On peut imaginer à l'avenir que beaucoup des commandes, listées au dessus, y passent.
Est-ce que vous connaissiez cette fonctionnalité ? Qu'en pensez vous ?
Dernière modification par Beta-Pictoris (02-08-2018 14:24:30)
Hors ligne
.. et ce n'est pas une mauvaise idée/fonctionnalité c'est d'ailleurs pour ça que c'est possible .. Dernière modification par naguam (02-08-2018 10:03:28)
Unixien?
Compiler son kernel!
Hors ligne
Je vérifie, ensuite, ses capacités:
Il n'y en a pas. S'il y en avait, elles auraient été perdues à la copie.
Je vais ajouter la capacité 'CAP_DAC_OVERRIDE' à la commande 'cat'.
Dans la page de manuel de 'capabilities', je peux lire:
Sur un fichier (ou un processus), une capacité est définie par 3 bits:
Le bit de capacité permise. C'est lui qui donne les droits maximum. Il va être transmis au processus correspondant au fichier.
Le bit de capacité effective. Il va être transmis au processus correspondant au fichier. Le noyau linux regarde celui-là pour donner les accès. Le processus peut modifier son bit de capacité effective pour brider ou libérer sa capacité (à condition que le bit de capacité permise soit activé).
Le bit de capacité héritable. Active le bit de capacité permise du processus lancé par un execve sous certaines conditions . On y reviendra plus tard
On va activer le bit de capacité permise (p) et le bit de capacité effective (e) sur le fichier cat.
La plupart des applications n'ont pas été réécrites pour tenir compte des capacités. Elles n'ajusteront, donc, pas leurs bits de capacité effective.
C'est pour cela que l'on force l'activation du bit de capacité effective.
Résultat:
On peut, maintenant, essayer, d'afficher le contenu du fichier '/etc/shadow' sur lequel le commun des mortels n'a pas de droit:
Je confirme, je vois bien le contenu du fichier.
Est-ce que tout ceci est clair pour vous ?
Dernière modification par Beta-Pictoris (02-08-2018 14:26:05)
Hors ligne
Voici un sujet qui fâche
Surtout si on écrit des approximations.
Certaines commandes linux triviales doivent avoir un bit setuid/suid pour pouvoir travailler en espace noyau
1) Une commande ne travaille pas en espace noyau. Son code s'exécute exclusivement en espace utilisateur. Lorsqu'elle a besoin d'effectuer une opération qui doit être réalisée en espace noyau, elle lance un appel système qui transfère l'exécution au code du noyau.
2) Ne pas confondre le bit SUID et les privilèges root. Le bit SUID fait exécuter le programme avec les droits du propriétaire de l'exécutable. Il ne donne les droits root que si le propriétaire est root.
3) Les commandes qui sont SUID root ne sont pas triviales. C'est pourquoi elles doivent être codées avec soin pour éviter les failles d'élévation de privilège.
Comme pour le bit setuid, on peut appliquer ces capacités sur les fichiers (dans les attributs étendus) grâce à la commande "setcap".
A condition que le système de fichiers supporte les attributs POSIX étendus. Ça va être le cas des principaux systèmes de fichiers utilisés avec GNU/Linux comme ext*, mais pas forcément de systèmes de fichiers moins courants. Je n'ai pas d'exemple à donner, mais c'est un point à prendre en compte.
on peut faire beaucoup de dégât avec mount
Un exemple concret ?
Que je sache, un utilisateur ne peut monter un système de fichiers que si cela a été déclaré explicement dans /etc/fstab avec l'option "user" ou "users".
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par naguam (02-08-2018 19:26:22)
Unixien?
Compiler son kernel!
Hors ligne
1) Une commande ne travaille pas en espace noyau. Son code s'exécute exclusivement en espace utilisateur. Lorsqu'elle a besoin d'effectuer une opération qui doit être réalisée en espace noyau, elle lance un appel système qui transfère l'exécution au code du noyau.
Oui, c'est exact, c'est une erreur de ma part. J'ai voulu simplifier mon explication au maximum. Si on parle de processus évoluant en mode utilisateur ou en mode noyau, est-ce que ça te va ?
2) Ne pas confondre le bit SUID et les privilèges root. Le bit SUID fait exécuter le programme avec les droits du propriétaire de l'exécutable. Il ne donne les droits root que si le propriétaire est root.
Oui, c'est aussi exact, mais comme quasiment toutes les commandes système ont "root" comme propriétaire, j'ai omis ce détail.
Par contre, cela montre une différence importante avec les capacités. Ces dernières ne sont pas limitées au propriétaire du fichier.
3) Les commandes qui sont SUID root ne sont pas triviales. C'est pourquoi elles doivent être codées avec soin pour éviter les failles d'élévation de privilège.
Je dis "trivial" parce que ce sont des commandes que l'on utilise couramment pour certaines d'entre elles.
Dernière modification par Beta-Pictoris (03-08-2018 17:02:29)
Hors ligne
Par rapport à la capacité 'CAP_DAC_OVERRIDE', celle-ci ne contourne pas les permissions en écriture.
Je lance 'bash' et je vérifie les capacités du processus 'bash' courant grâce à la comande 'getpcaps <pid>'
Maintenant, la complétion automatique des chemins n'est plus limitée aux répertoires sur lesquels on possède des permissions.
Je peux, par exemple, saisir '/boot/efi/EFI/BOOT...' par complétion alors que je n'ai, normalement, pas de permission pour accéder au répertoire '/boot/efi/EFI'.
Par contre, la capacité n'est pas transmise aux commande externes:
Selon vous, y a t'il un moyen d'accéder au contenu d'un fichier rien qu'avec des commandes internes au 'bash' ?
Dernière modification par Beta-Pictoris (03-08-2018 00:13:13)
Hors ligne
Dernière modification par Beta-Pictoris (06-08-2018 22:31:34)
Hors ligne
…moyen d'accéder au contenu d'un fichier rien qu'avec des commandes internes au 'bash' …
Pour faire afficher le contenu du fichier ~/.bashrc
par bash et ses commandes internes :
Dernière modification par MicP (07-08-2018 15:26:51)
Hors ligne
Dernière modification par Beta-Pictoris (07-08-2018 16:28:04)
Hors ligne
Les parenthèses, c'est juste pour que tout ça s'exécute dans un sous-shell
de façon à ce que la variable IFS ne soit modifiée que dans ce sous-shell et pas dans le shell courant.
[/Hors Sujet]
Dernière modification par MicP (07-08-2018 20:15:48)
Hors ligne
Que des bits de capacités héritables soient activés sur les commandes que l'on veut exécuter.
Que les utilisateurs aient le droit d'utiliser certaines capacités.
Pour autoriser les utilisateurs à utiliser des capacités, il faut installer le paquet "libpam-cap" et ajouter les lignes suivantes à la fin du fichier "/etc/pam.d/common-auth" :
L'activation des capacités pour les utilisateurs étant, donc, prise en charge par "pam", il faut, ensuite éditer le fichier "/etc/security/capability.conf".
Si on veut, par exemple, donner à l'utilisateur toto le droit d'utiliser les capacités "cap_net_admin" et "cap_net_raw", on peut ajouter les lignes suivantes dans le fichier:
A partir de maintenant, quand l'utilisateur toto se loguera, ses processus auront leurs bits de capacité héritable "cap_net_admin" et "cap_net_raw" activés.
Ce n'est pas suffisant. Il faut, maintenant, définir les commandes qui vont bénéficier des mêmes capacités pour cet utilisateur:
Comment ça marche ? :
Le processus appelant (bash) et le fichier exécutable ayant leurs bits de capacité héritable activés, le processus résultant aura ses bits de capacité permise activés.
Dernière modification par Beta-Pictoris (08-08-2018 01:05:38)
Hors ligne
Pages : 1
