Bonjour à tous. Nous nous joignons activement aux travaux et en janvier, nous préparons de nombreux lancements puissants. Entre autres, un ensemble a été annoncé pour un nouveau flux du cours Administrateur Linux que tout le monde aime. En prévision du lancement, nous partageons traditionnellement la traduction de matériel utile.
Les autorisations de fichiers offrent une alternative sûre aux exécutables SUID, mais elles peuvent sembler un peu déroutantes au premier abord.
Nous savons tous que les binaires
SUID sont une
mauvaise solution de sécurité . Heureusement, si votre application nécessite des privilèges limités, il existe un moyen plus efficace appelé
autorisations de fichiers .
Je vous ferai gagner du temps si vous voulez éviter une lecture détaillée de l'article ci-dessus: en substance, les autorisations de fichiers autorisent les processus qui s'exécutent en tant que root et, par conséquent, ont le droit de faire quelque chose, pour enregistrer certaines fonctionnalités limitées par
cette liste quand elles réinitialiser les privilèges et exécuter en tant qu'utilisateur non privilégié. Cela signifie que si un attaquant parvient à compromettre un processus en débordant d'un tampon ou d'un autre exploit, il ne pourra pas profiter d'autre chose que de certains privilèges minimaux dont le processus a réellement besoin.
Les autorisations sont idéales pour les services qui s'exécutent généralement en tant que root, mais qu'en est-il des utilitaires de ligne de commande? Heureusement, cela est également pris en charge à condition que les utilitaires corrects soient installés. Si vous utilisez Ubuntu, par exemple, vous aurez besoin du
libcap2-bin . Vous devrez également exécuter un noyau non archaïque (à partir de la version
2.6.24 ).
Ces fonctions vous permettent d'associer des autorisations à des fichiers exécutables de la même manière que la définition du bit SUID, mais uniquement pour un ensemble spécifique d'autorisations. L'utilitaire
setcap utilisé pour ajouter et supprimer des autorisations d'un fichier.
La première étape consiste à sélectionner les autorisations dont vous avez besoin. Pour cet article, je suppose qu'il existe un outil de diagnostic réseau appelé
tracewalk qui devrait pouvoir utiliser
des sockets bruts . Cela nécessite généralement que l'application soit exécutée en tant que root, mais lors de l'affichage de la
liste, il s'avère que seule l'autorisation
CAP_NET_RAW est
CAP_NET_RAW .
En supposant que vous êtes dans le répertoire où se trouve le binaire
tracewalk , vous pouvez ajouter cette autorisation comme suit:
sudo setcap cap_net_raw=eip tracewalk
Pour l'instant, ignorez le suffixe
=eip pour la permission, je vais en parler dans quelques secondes. Veuillez noter que le nom de l'autorisation est en minuscules. Vous pouvez maintenant vérifier si vous avez correctement configuré les autorisations avec:
setcap -v cap_new_raw=eip tracewalk
Ou vous pouvez répertorier toutes les autorisations définies pour ce fichier exécutable:
getcap tracewalk
Pour référence, vous pouvez également supprimer toutes les autorisations de l'exécutable en utilisant:
setcap -r tracewalk
À ce stade, vous devriez être en mesure d'exécuter l'exécutable en tant qu'utilisateur non privilégié, et il devrait être en mesure de travailler avec des sockets bruts, mais ne pas avoir d'autres privilèges que l'utilisateur root.
Alors, que signifie ce suffixe étrange
=eip ? Cela nécessitera un peu de compréhension de la nature des autorisations. Chaque processus possède trois ensembles d'autorisations -
effectifs, héritables et autorisés (effectifs, héritables et autorisés) :
- Les autorisations effectives sont celles qui déterminent ce qu'un processus peut réellement faire. Par exemple, il ne peut pas traiter les sockets bruts si
CAP_NET_RAW pas dans un ensemble efficace. - Les autorisations autorisées sont celles qu'un processus est autorisé à avoir s'il les demande via un appel approprié. Ils ne permettent pas à un processus de faire quoi que ce soit, sauf s'il a été spécifiquement écrit pour demander l'autorisation spécifiée. Cela vous permet d'écrire des processus pour ajouter des autorisations critiques à l'ensemble effectif uniquement pour la période où ils sont vraiment nécessaires.
- Les autorisations héritables sont celles qui peuvent être héritées dans la collection disponible du processus enfant. Pendant l'opération
fork() ou clone() , le processus enfant reçoit toujours une copie des autorisations du processus parent, car à ce moment il exécute toujours le même fichier exécutable. Un ensemble hérité est utilisé lorsque exec() (ou un équivalent) est appelé pour remplacer l'exécutable par un autre. À ce stade, l'ensemble de processus disponible est masqué par l'ensemble hérité pour obtenir l'ensemble disponible qui sera utilisé pour le nouveau processus.
Ainsi, l'utilitaire
setcap nous permet d'ajouter des autorisations de ces trois ensembles indépendamment pour un fichier exécutable donné. Notez que la signification des groupes est interprétée un peu différemment pour les autorisations de fichier:
- Les autorisations de fichier disponibles sont celles qui sont toujours disponibles pour l'exécutable, même si le processus parent qui l'a appelé ne les avait pas. Auparavant, ils étaient appelés autorisations "forcées".
- Les autorisations de fichiers héritées définissent un masque supplémentaire qui peut également être utilisé pour supprimer les autorisations de l'ensemble du processus appelant. Ils sont utilisés en plus de l'ensemble hérité du processus appelant, donc l'autorisation n'est héritée que si elle existe dans les deux ensembles.
- Les autorisations de fichiers efficaces ne sont en fait qu'un seul bit, pas un ensemble, et s'il est installé, cela signifie que l'ensemble complet disponible est également copié dans l'ensemble effectif du nouveau processus. Cela peut être utilisé pour ajouter des autorisations à des processus qui n'ont pas été spécifiquement écrits pour les demander. Comme il s'agit d'un bit, si vous le définissez pour une autorisation, il doit être défini pour toutes les autorisations. Vous pouvez le considérer comme un bit hérité car il est utilisé pour autoriser les autorisations pour les applications qui ne les prennent pas en charge.
Lorsque vous spécifiez des autorisations via
setcap trois lettres
e ,
i et
p font respectivement référence à des ensembles
efficaces, hérités et accessibles . Donc, une spécification antérieure:
sudo setcap cap_net_raw=eip tracewalk
... indique que l'autorisation
CAP_NET_RAW doit être ajoutée aux ensembles disponibles et hérités et que le bit effectif doit également être défini. Cela remplacera toutes les autorisations précédemment définies dans le fichier. Pour définir plusieurs autorisations à la fois, utilisez une liste séparée par des virgules:
sudo setcap cap_net_admin,cap_net_raw=eip tracewalk
Le guide des autorisations discute de tout cela plus en détail, mais j'espère que ce post a un peu démystifié l'incident. Il ne reste à mentionner que quelques avertissements et astuces.
Tout d'abord, les capacités de fichier ne fonctionnent pas avec les liens symboliques - vous devez les appliquer au binaire lui-même (c'est-à-dire à la cible du lien symbolique).
Deuxièmement, ils ne fonctionnent pas avec des scripts interprétés. Par exemple, si vous disposez d'un script Python auquel vous souhaitez attribuer une autorisation, vous devez l'attribuer à l'interpréteur Python lui-même. Évidemment, c'est un problème de sécurité potentiel, car alors tous les scripts exécutés avec cet interprète auront l'autorisation spécifiée, bien que ce soit encore mieux que de faire le SUID. La solution de contournement la plus courante, apparemment, consiste à écrire un fichier exécutable séparé en C ou un analogue qui peut effectuer les opérations nécessaires et l'appeler à partir d'un script. Ceci est similaire à l'approche utilisée par Wireshark, qui utilise le fichier binaire
/usr/bin/dumpcap pour effectuer des opérations privilégiées:
$ getcap /usr/bin/dumpcap /usr/bin/dumpcap = cap_net_admin,cap_net_raw+eip
Troisièmement, les autorisations de fichiers sont désactivées si vous utilisez la
LD_LIBRARY_PATH environnement
LD_LIBRARY_PATH pour des raisons de sécurité évidentes
(1) . La même chose s'applique à
LD_PRELOAD , pour autant que je sache.
1. Étant donné que l'attaquant peut évidemment remplacer l'une des bibliothèques standard et utiliser LD_LIBRARY_PATH pour forcer sa bibliothèque à être appelée de préférence sur le système, et donc avoir son propre code arbitraire exécuté avec les mêmes privilèges que l'application appelante.
C’est tout. Les détails du programme du cours peuvent être consultés lors du webinaire, qui se tiendra le 24 janvier.