Les fonctionnalités permettent d'évaluer certains privilèges système importants dans une chaîne distincte du processus en cours. De cette façon, vous n'aurez pas besoin d'exécuter une application en tant que root pour accéder à certaines parties du système.
En tant que solution découlant des besoins, la section 25 de POSIX.1e se rapporte à ce problème. Le développement des privilèges définis dans cette section et plus a été achevé avec l'arrivée de la version 2.6.26 du noyau Linux. Voici tout ce que vous devez savoir sur les fonctionnalités du noyau Linux.
Comprendre la logique de l'API des capacités
Le contrôle des privilèges dans les systèmes basés sur Unix comprend deux étapes :
- Si le propriétaire actuel (identifiant utilisateur effectif, EUID) de l'application en cours d'exécution est zéro, le système ne vérifiera pas l'autorisation.
- Si la valeur EUID est différente de zéro, le système effectuera le processus de contrôle conformément aux autorisations de l'utilisateur actif et du groupe d'applications concerné.
Certaines applications nécessitent des privilèges plus larges (SUID, SGIT) lors de leur exécution. Comme exemple typique, vous pouvez considérer passwd. Avec lui, les utilisateurs du système peuvent changer leurs mots de passe. Cependant, pour écrire dans le fichier etc/shadow, où les mots de passe chiffrés sont conservés, il est nécessaire de travailler avec les droits d'utilisateur root (c'est-à-dire userid = 0).
Pour résoudre ce problème, l'implémentation passwd contient le bit SUID. Quel que soit l'utilisateur qui exécute cette application, le propriétaire actif (EUID) sera toujours Root :
ls -l /usr/bin/passwd # Output -rwsr-xr-x. 1 root root 32552 Jul 23 2021 /usr/bin/passwd
La possibilité d'exécuter des applications SUID dans le modèle d'authentification Unix traditionnel semble avoir résolu le problème. Cependant, de graves bogues dans les applications contenant des bits SUID ouvrent la porte à l'exécution de code indésirable pour les utilisateurs qui ont un contrôle total sur le système. L'application idéale doit pouvoir s'exécuter sans avoir besoin de droits d'utilisateur root si possible.
Le problème ne se termine pas uniquement avec le bit SUID. Vous devez également disposer des droits root lorsque vous souhaitez écouter sur un port TCP ou UDP avec des privilèges inférieurs à 1024 sur les systèmes basés sur Unix. Par exemple, pour pouvoir écouter sur le port TCP 80 d'un serveur Web, vous devez exécuter l'application en tant qu'utilisateur root.
Au fil des ans, on a compris à quel point il était perturbateur d'exécuter des applications qui fournissent un service à un environnement réseau avec un compte utilisateur sous licence complète. Comme solution de contournement, il a été adopté que seule une partie spécifique et plus petite de l'application écoute sur le port privilégié en tant que racine, puis change l'ID de l'utilisateur actif en un autre utilisateur pour les processus suivants (par exemple, un utilisateur sans privilèges restreints ).
Ce système, utilisé depuis des années, fonctionne bien avec sa simplicité et est toujours utilisé efficacement. Cependant, à l'heure actuelle, il est possible d'obtenir certaines fonctionnalités supplémentaires, spécifiques à l'application, via l'API de fonctionnalités Linux, sans avoir besoin de droits root, quel que soit le système mentionné ci-dessus. Vérifier Quelques utilisations pratiques et réalistes de Linux.
Modèle de capacités Linux expliqué !
Vous pouvez trouver l'implémentation la plus complète de l'API de fonctionnalités dans le noyau Linux. Les distributions Linux modernes essaient également d'utiliser autant que possible ce nouveau paradigme au niveau du système.
Par exemple, pour qu'une application fonctionne Ping , il devrait être capable d'ouvrir les sockets RAW, qui sont généralement réservés aux utilisateurs root uniquement. Sur les anciennes distributions Linux, le problème est que le bit SUID est donné à l'application afin que les utilisateurs normaux puissent l'utiliser. Dans ces versions, lorsque vous supprimez le bit SUID de l'application et essayez d'exécuter l'application en tant qu'utilisateur normal, vous obtenez l'erreur suivante :
ping 8.8.8.8 # Output ping: icmp open socket: Operation not permitted
Alors que sur les distributions Linux modernes, ping n'a probablement pas de bit SUID :
ls -l /bin/ping # Output -rwxr-xr-x. 1 root root 95232 Jul 25 2021 /bin/ping
Cependant, vous pouvez exécuter l'application avec succès en tant qu'utilisateur normal. Le mécanisme qui rend cela possible est que Ping a la capacité spéciale CAP_NET_RAW.
Vous pouvez découvrir les fonctionnalités supplémentaires de l'application à l'aide de la commande getcap comme suit :
sudo getcap /bin/ping # Output /bin/ping cap_net_raw=ep
Si la commande getcap renvoie une réponse vide, vous pouvez définir cette valeur manuellement avec :
sudo setcap cap_net_raw+ep /bin/ping
modèle de capacités de processus
Dans une application Linux, les capacités de chaque processus sont regroupées sous trois en-têtes :
- Autorisé: Dans ce groupe, il y a une liste de capacités supplémentaires qui sont autorisées pour le processus associé. L'octroi de l'autorisation ne signifie pas qu'il peut être activement utilisé à ce moment-là. Il est possible d'inclure ici les licences dans la capacité effective définie par une action complémentaire.
- efficace: affiche la liste des fonctionnalités actuellement actives pour le processus associé. Grâce à des fonctions auxiliaires qui organisent le système de compétences, il est possible d'abandonner ou de restaurer une compétence. Cependant, dans tous les cas, cela ne peut se faire qu'entre des personnes autorisées déjà dans le groupe autorisé.
- héréditaire: Lorsqu'une application démarre un nouveau processus, le processus nouvellement démarré affiche la liste des fonctionnalités dont il héritera de la liste autorisée.
La liste des capacités autorisées, effectives et pouvant être héritées pour exécuter des processus à tout moment est affichée sous forme de masque binaire sur les lignes CapPrm, CapEff et CapInh dans le fichier /proc/ /statut. De plus, la ligne CapBnd contient le masque de bits utilisé dans le processus de contrôle des limites de capacité.
Par exemple, essayez de lire les valeurs d'une application shell en cours d'exécution à partir du fichier /proc/self/status :
cat /proc/self/status | grep Cap # Output CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 000001ffffffffff CapAmb: 0000000000000000
Modèle de capacité de fichier Linux
Le fonctionnement du système de capacités pour les fichiers dépend des prérequis pour lesquels ces propriétés peuvent être stockées dans la couche du système de fichiers virtuel (VFS). Semblable au modèle de processus, les capacités de fichier se répartissent en trois rubriques :
1. Autorisé :
Le système définit les capacités qui sont autorisées pour un processus lorsque l'exécutable correspondant dans ce groupe est exécuté.
2. Efficace
Contrairement au modèle de capacité de traitement, cet en-tête ne stocke qu'un seul bit : actif ou inactif. Si le bit est actif, les capacités spécifiées dans la liste autorisée du fichier sont automatiquement déplacées vers la liste des capacités actives du processus concerné lorsque ce fichier est exécuté et qu'un processus est créé. Si le bit n'est pas actif, le transfert automatique des capacités autorisées dans le fichier vers le processus en cours d'exécution n'est pas effectué.
Cependant, si le code d'application pertinent est combiné avec le système de possibilité, il peut activer les autorisations dans le groupe autorisé du fichier à l'aide d'appels système. L'objectif principal de ce comportement est de garantir que les applications héritées qui n'incluent pas le code du système de capacité, le développement au niveau du code d'application peut fonctionner avec le système de capacité sans nécessiter de modifications du code source.
Vous pourriez penser que les meilleures applications écrites n'utiliseront les fonctionnalités qu'en cas de besoin. Si le bit est actif, toutes les fonctionnalités de la liste autorisée deviennent actives au démarrage de l'application.
3. Il est héréditaire
Comme dans le modèle de processus, le fichier pertinent est exécuté et le processus se produit. Si une autre application est lancée depuis le processus après cela, elle sera incluse dans la liste autorisée du nouveau processus. En somme, il se réfère à une liste de possibilités héritées. Vérifier Les applications les plus importantes et indispensables pour les utilisateurs de Linux.
Le rôle des capacités dans Linux
Lorsque vous exécutez un processus particulier en tant qu'utilisateur normal, vous n'avez aucun privilège. Par conséquent, vous ne pouvez accéder qu'aux sections que le système autorise pour les utilisateurs normaux. La principale raison derrière cela est de renforcer la sécurité du système et de mettre en œuvre des mesures de protection comme celles-ci.
Autoriser tous les utilisateurs à accéder à toutes les ressources peut entraîner une grave faille de sécurité. Il serait très facile pour les personnes utilisant le système à des fins malveillantes d'exploiter les faiblesses du système. Les capacités de Linux sont utiles dans ces domaines. Améliorez facilement la sécurité de vos applications grâce aux fonctionnalités API prises en charge par le noyau.
Les capacités de Linux ne sont qu'un des problèmes à prendre en compte pour appliquer des méthodes très efficaces telles que le fractionnement des autorisations de l'utilisateur racine, l'attribution de différentes autorisations ME aux utilisateurs non privilégiés et la prise de différentes précautions concernant les ports ouverts dans les services Internet avec des serveurs Linux. Vous pouvez désormais visualiser Comment créer un serveur Web sous Linux à l'aide d'un ancien ordinateur.
