Cours MIT "Sécurité des systèmes informatiques". Conférence 6: Opportunités, partie 2

Institut de technologie du Massachusetts. Cours magistral # 6.858. "Sécurité des systèmes informatiques." Nikolai Zeldovich, James Mickens. 2014 année

Computer Systems Security est un cours sur le développement et la mise en œuvre de systèmes informatiques sécurisés. Les conférences couvrent les modèles de menace, les attaques qui compromettent la sécurité et les techniques de sécurité basées sur des travaux scientifiques récents. Les sujets incluent la sécurité du système d'exploitation (OS), les fonctionnalités, la gestion du flux d'informations, la sécurité des langues, les protocoles réseau, la sécurité matérielle et la sécurité des applications Web.

Cours 1: «Introduction: modèles de menace» Partie 1 / Partie 2 / Partie 3
Conférence 2: «Contrôle des attaques de pirates» Partie 1 / Partie 2 / Partie 3
Conférence 3: «Débordements de tampon: exploits et protection» Partie 1 / Partie 2 / Partie 3
Conférence 4: «Séparation des privilèges» Partie 1 / Partie 2 / Partie 3
Conférence 5: «D'où viennent les systèmes de sécurité?» Partie 1 / Partie 2
Conférence 6: «Opportunités» Partie 1 / Partie 2 / Partie 3

Public: peut-on conclure que chaque opportunité a un processus?

Professeur: J'en doute. Vous pouvez avoir autant de processus que vous le souhaitez, pour une possibilité, plusieurs processus peuvent exister. Autrement dit, vous n'avez pas nécessairement besoin d'un processus distinct pour chaque opportunité. Parce qu'il existe un processus fort1 qui peut ouvrir de nombreux fichiers et transmettre de nombreuses fonctionnalités au composant privilégié de fort .



La raison pour laquelle vous pensez avoir besoin d'un processus distinct pour chaque opportunité que nous traitons concerne cette étrange interaction entre les capacités et les privilèges externes.

Parce que fort1 a un privilège externe. Et ce que nous faisons, c'est essentiellement transformer ce privilège externe en capacité dans ce processus fort1 . Donc, si vous disposez de plusieurs types de privilèges externes ou de plusieurs privilèges différents que vous souhaitez utiliser avec prudence, vous souhaiterez probablement un processus distinct doté de ce privilège. Et chaque fois que vous souhaitez utiliser un ensemble spécifique de privilèges, vous demanderez au processus approprié d'effectuer la séparation, et si cela réussit, vous demanderez au processus de vous renvoyer la capacité .

En fait, il y avait une telle conception du système d'exploitation qui était complètement basée sur les capacités et n'avait aucun privilège externe. Et c'est cool, mais pas très pratique pour une utilisation dans un vrai système. Il s'avère qu'en réalité vous ne voulez pas tant de privilèges externes que d'opportunités pour nommer un objet et parler de cet objet à quelqu'un sans transférer les droits sur cet objet sans faute.

Je ne sais peut-être pas quels privilèges vous pouvez avoir à l'égard d'un document général, mais je tiens à vous informer que nous avons ce document général. Si vous pouvez le lire, lisez-le. Si vous l'écrivez, bien, écrivez. Mais je ne veux pas lui céder de droits. Je veux juste vous dire: "Hé, cette chose, va l'essayer!" C'est donc un inconvénient dans le monde des opportunités, car cela vous oblige vraiment à ne jamais parler d'objets sans transférer les droits sur cet objet.

Par conséquent, il est important de le savoir et d'utiliser cette fonctionnalité dans certaines parties du système, mais de ne pas se fier à cela pour être la solution à la sécurité du système.



Public: supposons que le processus possède les capacités que lui confère un autre processus, mais il s'avère qu'il possède déjà de grandes capacités par rapport à un objet. Un processus peut-il les comparer pour s'assurer qu'ils touchent le même objet? Ou utilisera-t-il les grandes opportunités?

Professeur: le fait est que le processus n'utilise pas les capacités de manière implicite, c'est donc une propriété très utile des capacités. Vous devez absolument indiquer laquelle des options vous utilisez. Alors pensez-y en termes de descripteur de fichier. Supposons que je vous donne un descripteur de fichier ouvert pour un fichier et qu'il soit en lecture seule. Ensuite, quelqu'un d'autre vous donne une autre opportunité pour d'autres fichiers, qui peuvent inclure ce fichier. Et une nouvelle fonctionnalité vous permet de lire et d'écrire dans des fichiers.

Dans ce cas, si vous essayez d'écrire dans le premier fichier, vous réussirez sans aucun doute, car un descripteur de fichier supplémentaire lui sera ouvert, ce qui permet non seulement la lecture mais aussi l'écriture. C'est donc une sorte de truc cool quand vous n'avez pas besoin de privilèges externes supplémentaires. Vous avez simplement toutes ces possibilités, car les gens ont en fait construit de telles bibliothèques et, en principe, ils gèrent vos capacités pour vous. Ils les récupèrent en quelque sorte. Et lorsqu'ils tentent d'effectuer une opération, ils recherchent des opportunités et trouvent celles qui la font fonctionner.

Cela vous ramène au contrôle externe de l' autorité ambiante que vous tentiez d'éviter. Une caractéristique positive des possibilités est qu'il s'agit d'une conception logicielle qui vous simplifie la vie. Ceci est rare dans les solutions de sécurité. Cette propriété vous permet d'écrire plus facilement du code qui pointe vers les privilèges que vous souhaitez utiliser du point de vue de la sécurité. Et c'est assez facile d'écrire du code.
Cependant, la capacité peut résoudre d'autres problèmes. Ainsi, des problèmes de gestion des privilèges surviennent souvent lorsque vous devez exécuter du code non approuvé. Parce que vous voulez vraiment contrôler les privilèges que vous accordez, sinon il y a un risque d'utilisation abusive des privilèges que vous accordez. Et c'est un point de vue légèrement différent à partir duquel les auteurs de l'article sur Capsicum abordent les opportunités. Ils sont bien sûr conscients du problème de l'autorité extérieure, mais c'est un problème légèrement différent que vous pouvez ou ne pouvez pas résoudre. Mais fondamentalement, ils se soucient d'avoir une très grande application privilégiée, et ils craignent qu'il y ait des erreurs dans différentes parties du code source de cette application. Par conséquent, ils souhaitent réduire les privilèges des différents composants de cette application.

En ce sens, l'histoire est très similaire à OKWS . Donc, vous avez une grande application, vous la divisez en composants et restreignez les privilèges pour chaque composant. Cela a certainement du sens dans OKWS . Y a-t-il d'autres situations où vous pourriez être préoccupé par le partage des privilèges? Je pense que dans leur article, ils décrivent des exemples que je devrais essayer d'exécuter, par exemple, tcpdump et d'autres applications qui analysent les données du réseau. Pourquoi sont-ils si préoccupés par les applications qui analysent les entrées réseau? Que se passe-t-il dans tcpdump ? Quelle est la raison de leur paranoïa?

Public: un attaquant peut contrôler ce qui est envoyé et ce qui est appelé à exécuter, par exemple, des paquets.

Professeur: oui, ils se soucient vraiment des attaques de ce type et de savoir si l'attaquant peut vraiment contrôler les données d'entrée? Parce que c'est assez problématique si vous écrivez du code C qui devrait gérer les structures de données. De toute évidence, vous ferez beaucoup de manipulations de pointeurs en copiant des octets dans des tableaux qui allouent de la mémoire. En même temps, il est facile de faire une erreur avec la gestion de la mémoire, ce qui entraînera des conséquences plutôt désastreuses.

C'est donc la raison pour laquelle ils ont décidé de distinguer le travail de leur protocole réseau et d'autres choses dans le bac à sable.



Votre navigateur est un autre exemple du monde réel où le partage de privilèges est nécessaire. Vous voudrez probablement isoler votre plugin Flash, ou votre extension Java , ou autre chose. Parce qu'ils représentent un large champ d'attaques qui sont utilisées de manière assez agressive.

Cela semble donc être un plan intelligent. Par exemple, si vous écrivez un logiciel, vous voulez vérifier le comportement de ses composants dans le bac à sable. Plus généralement, cela fait référence à ce que vous avez téléchargé sur Internet et que vous avez l'intention d'exécuter avec moins de privilèges. Le style d'isolement offert par Capsicum convient-il à cela ? Je pourrais télécharger un économiseur d'écran aléatoire ou un jeu sur Internet. Et je veux les exécuter sur mon ordinateur, mais assurez-vous d'abord qu'ils ne ruinent pas tout ce que j'ai. Pourriez-vous utiliser Capsicum pour cela?

Public: vous pouvez écrire un programme sandbox dans lequel vous utiliserez Capsicum .

Professeur: à droite. Comment l'utiliseriez-vous? Eh bien, vous devez simplement entrer en mode sandbox avec la commande cap_enter , puis exécuter le programme. Pensez-vous que cela fonctionnera? Je pense qu'il y aura un problème. Il sera lié au fait que si le programme ne s'attend pas à ce qu'il soit isolé par Capsicum , alors il peut essayer d'ouvrir la bibliothèque partagée, mais il ne pourra pas le faire, car il ne pourra pas ouvrir quelque chose comme / lib / ... , car il ne le fait pas autorisé en mode Capacité .

Par conséquent, ces méthodes sandbox doivent être utilisées pour les choses pour lesquelles le développeur a prévu qu'elles peuvent être exécutées dans ce mode. Il existe probablement d'autres méthodes sandbox qui peuvent être utilisées pour du code non modifié, mais les exigences peuvent alors légèrement changer. Par conséquent, les créateurs de Capsicum ne sont pas très préoccupés par la compatibilité descendante. Si nous devons ouvrir les fichiers différemment, nous les ouvrirons différemment. Mais si vous souhaitez laisser le code existant, vous avez besoin de quelque chose de plus, par exemple, une machine virtuelle à part entière pour pouvoir y exécuter le code. Cela soulève la question - devrions-nous utiliser des machines virtuelles pour le sandbox Capsicum ?

Public: dans ce cas, un dépassement de mémoire est possible.

Professeur: oui, ça l'est. Mais que faire si nous ne nous soucions pas de la mémoire? Les machines virtuelles sont donc probablement très bonnes et n'utilisent pas beaucoup de mémoire. Alors, pour quelle autre raison ne devrions-nous pas utiliser VM dans Capsicum ?

Public: Il est difficile de contrôler l'activité du réseau.

Professeur: C'est vrai! Il est difficile de contrôler ce qui se passe sur le réseau car soit vous ne donnez pas accès à la machine virtuelle au réseau, soit vous vous connectez au réseau via le mode NAT , soit en utilisant Aperçu ou VMWare . Mais alors, votre bac à sable peut accéder à tout Internet. Par conséquent, vous devrez gérer le réseau plus en détail, peut-être en définissant des règles de pare-feu pour la machine virtuelle, etc. Ce n'est pas trop bon.

Mais que faire si vous ne vous souciez pas du réseau? Supposons que vous ayez juste une sorte de vidéo. Que faire si vous traitez une vidéo simple ou analysez tcpdump . Dans ce cas, vous démarrez simplement la machine virtuelle, elle commence à analyser vos paquets tcpdump et vous renvoie après la présentation que tcpdump veut écrire à l'utilisateur, car il n'y a pas d'E / S réseau réelles. Alors, y a-t-il une autre raison?



Public: car le surcoût de l'initialisation est toujours élevé.

Professeur: oui, cela peut être la surcharge initiale du démarrage d'une machine virtuelle, ce qui réduit les performances. C'est donc vrai.

Public: Eh bien, vous voudrez peut-être toujours avoir des droits sur une base de données, etc.

Professeur: oui. Mais plus généralement, cela signifie que vous disposez de données réelles avec lesquelles vous travaillez et qu'il est vraiment difficile de les séparer. Ainsi, les machines virtuelles sont en effet un mécanisme de partage beaucoup plus important, à cause duquel vous ne pouvez pas facilement partager des choses. C'est donc bon pour les situations où vous avez un programme complètement isolé que vous souhaitez exécuter, et en même temps vous ne voulez pas partager de fichiers, répertoires, processus et les laisser fonctionner séparément.

C'est donc super. C'est probablement, en quelque sorte, un isolement plus fort que celui que Capsicum fournit, car il y a moins d'options pour que les choses tournent mal. Cependant, cet isolement n'est pas applicable dans de nombreuses situations lorsque vous souhaitez utiliser Capsicum . Parce que dans Capsicum, vous pouvez échanger des fichiers avec une grande précision, en utilisant les capacités du sandbox.

Prenons donc tcpdump et voyons pourquoi il est difficile de l'isoler à l'aide du mécanisme Unix . Si vous vous souvenez, dans Capsicum, le fonctionnement de tcpdump est qu'il ouvre des sockets spéciaux, puis exécute la logique d'analyse sur les paquets réseau, après quoi il est imprimé sur les terminaux des utilisateurs. Alors, que faut-il pour un bac à sable tcpdump basé sur Unix ? Vos privilèges sont-ils limités? Le problème avec Unix est que la seule façon de vraiment changer les privilèges est de changer l'entrée dans la fonction de décision, qui décide si vous pouvez vraiment accéder à un objet ou non. Et la seule chose que vous pouvez vraiment changer, ce sont les privilèges du processus. Cela signifie que le processus pourra envoyer l' UID à quelqu'un d'autre.

Ou vous pouvez modifier les autorisations pour divers objets qui se trouvent sur votre système. En fait, vous pouvez utiliser ces deux solutions.

Si vous souhaitez isoler tcpdump dans le bac à sable, vous devrez probablement sélectionner un ID utilisateur supplémentaire et y basculer pendant que vous travaillez. Mais ce n'est pas un plan idéal, car vous n'allez pas exécuter plusieurs instances de tcpdump sous le même ID utilisateur. Par conséquent, si je compromets une instance de tcpdump , cela ne signifie pas que je souhaite autoriser un attaquant à utiliser ce facteur pour contrôler d'autres instances de tcpdump s'exécutant sur ma machine. C'est donc potentiellement une mauvaise décision d'utiliser uid dans ce cas.

Un autre problème est que sous Unix, vous devez avoir des privilèges root pour changer l'ID utilisateur, les privilèges, le processus ou autre chose, ou les changer pour autre chose. C'est aussi mauvais.

Et un autre problème est que, quel que soit votre ID , des fichiers en libre accès peuvent exister. Votre système peut donc avoir tout un groupe de fichiers lisibles ou inscriptibles, par exemple, un fichier de mot de passe. En effet, quel que soit votre identifiant , le processus pourra toujours lire ce mot de passe. Ce n'est donc pas très agréable non plus.

Ainsi, afin d'organiser un sandbox sur Unix , vous devriez probablement faire les deux: modifier l' UID et examiner attentivement les autorisations pour tous les objets pour vous assurer que vous n'avez pas de fichiers ouverts non isolés sensibles à l'écrasement ou à la lecture par un pirate. Je pense que ce faisant, vous obtenez un autre mécanisme que vous pouvez utiliser. Si vous le soumettez à la fin, vous pouvez rencontrer des difficultés à partager des fichiers ou des répertoires de partage.

Voyons maintenant comment Capsicum essaie de résoudre ce problème. Ici, dès que nous entrons dans le mode "bac à sable", tout ne sera disponible qu'à travers les opportunités. Par conséquent, si vous n'avez pas de capacité , vous ne pouvez tout simplement pas accéder à aucun objet.

Ces gars dans l'article font un énorme pari sur l'espace de noms mondial. Alors, quel est cet espace de noms mondial, et pourquoi sont-ils si inquiets à ce sujet?

Leur système de fichiers lui-même est une sorte d'exemple brillant d'un espace de noms global. Vous pouvez écrire une barre oblique et répertorier tous les fichiers que vous souhaitez derrière. Par exemple, allez à quelqu'un dans le répertoire personnel, par exemple, / home / nickolai / ... Pourquoi est-ce mauvais? Pourquoi sont-ils contre l'espace de noms mondial dans Capsicum ? Qu'en penses-tu?



Public: si vous n'avez pas les bonnes autorisations, alors lorsque vous utilisez l'autorité, vous pouvez avoir des ennuis.

Professeur: oui. Le problème est que c'est toujours Unix . Ainsi, il existe toujours des autorisations de fichiers régulières. Par conséquent, peut-être, si vous voulez vraiment isoler un processus dans le bac à sable, vous ne pourrez rien lire ni écrire dans le système. Mais si vous parvenez à trouver un fichier inscriptible dans le répertoire personnel d'un utilisateur stupide, ce sera plutôt désagréable pour le client sandbox.

Plus généralement, leur idée était de lister avec précision tous les objets du processus. Parce que vous pouvez simplement répertorier toutes les fonctionnalités dans un tableau de descripteurs de fichiers ou n'importe où ailleurs où les fonctionnalités sont stockées pour vous. Et c'est la seule chose que le processus peut toucher.

Mais si vous avez accès à l'espace de noms global, cela est potentiellement impossible. Parce que même si vous disposez d'un ensemble limité de fonctionnalités, vous pouvez toujours commencer la ligne avec une barre oblique et écrire un nouveau fichier, et vous ne connaîtrez jamais l'ensemble des opérations ou des objets auxquels ce processus peut accéder.

C'est pourquoi ils s'inquiètent tellement de l'espace de noms global, car cela contredit leur objectif de contrôler précisément tout ce à quoi le processus sandbox devrait avoir accès. De cette façon, ils ont essayé d'éliminer les espaces de noms globaux avec de nombreuses modifications du noyau dans FreeBSD . Dans leur cas, le noyau devait s'assurer que toutes les opérations passent par certaines fonctionnalités, à savoir par le descripteur de fichier.

Vérifions si nous avons vraiment besoin de modifications du noyau. Et si on le faisait juste à la bibliothèque? Après tout, nous implémentons Capsicum , qui possède déjà une bibliothèque. Et tout ce que nous faisons est de modifier toutes ces fonctionnalités, telles que «ouvrir, lire, écrire» pour utiliser exclusivement les fonctionnalités de capacité . Ensuite, toutes les opérations passeront par certaines fonctionnalités, les rechercher dans la table de fichiers, etc. Est-ce que cela fonctionnera?



Public: Vous pouvez toujours effectuer l' appel système syscall .

Professeur: oui. Le problème est qu'il y avait un ensemble d'appels système que le noyau accepte, et même si vous implémentez une bonne bibliothèque, cela n'empêchera pas la possibilité qu'un processus mauvais ou compromis fasse un appel système directement. Par conséquent, vous devez en quelque sorte renforcer le noyau.

Dans le compilateur, le modèle de menace n'est pas dans le processus de compilateur compromis et non dans du code arbitraire, mais dans la négligence du programmeur. Donc, si le développeur du programme ne se trompe pas et fait la bonne chose, alors la bibliothèque sera probablement assez.

, , , . - , .

? — , cap_enter . , cap_enter ? , ?

, , . , , , . cap_enter , open () , openat .

Unix- , , open , openat , , , — : openat (dirfd,“name) . openat «name» , .



, Capability open , , , . . - ? -, ? , – . , ?

: , .

: . , , . , , . , . , , . -, .

, , , , , . , , .. , , , . ?

. ? , Unix PID . , kill (25) PID = 25 . , . Capsicum ? ?

: .

: . -, . , Unix , . , PID , , fork , pdfork , « ». , - .

. , . , - : « «» , , , , ». . , , - .

, , , . , . , , .



. , «-» . , openat , «-». , «-», .

? , «-» ?

: , , . , Capability .

: , .

: , , - …

: .

: - .

: , . «-» ? , openat - b/c/../.. ?

, , ? - , . , , , openat (d, “b/c/../..) «c» , - .



. , , , . «-», . , , . , , . , UID - ?

: , .

: , . , , «» UID ? : cap_enter UID . , . ? ?

: , UID , , , , , - .

: , . «» UID . , , UID . , , , . UID .

54:14

:

Cours MIT "Sécurité des systèmes informatiques". 6: «», 3


.

Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en le recommandant à vos amis, une réduction de 30% pour les utilisateurs Habr sur un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbps à partir de 20 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

Dell R730xd 2 fois moins cher? Nous avons seulement 2 x Intel Dodeca-Core Xeon E5-2650v4 128 Go DDR4 6x480 Go SSD 1 Gbps 100 TV à partir de 249 $ aux Pays-Bas et aux États-Unis! Pour en savoir plus sur la création d'un bâtiment d'infrastructure. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?