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

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

Ainsi, dans la continuité du sujet du partage des privilèges, nous parlerons aujourd'hui des opportunités. Si vous vous souvenez, la semaine dernière, nous avons expliqué comment Unix fournit certains mécanismes pour les applications que nous pouvons utiliser si nous devons séparer les privilèges de la structure interne de l'application.

Aujourd'hui, nous allons parler des possibilités qui nous feront penser très différemment aux privilèges que l'application peut avoir. Par conséquent, dans la conférence d'aujourd'hui, nous avons deux questions distinctes à discuter. Une question est de savoir comment éviter toute confusion dans la détermination de l'autorité et rendre vos privilèges lors de l'écriture d'un programme plus clairs et sans ambiguïté afin de ne pas utiliser accidentellement les mauvais privilèges.

La deuxième question concerne le «bac à sable» appelé Capsicum , c'est un système similaire à OKWS , qui vous permettra d'exécuter un fragment de code avec moins de privilèges. Par conséquent, si le système est compromis, cela ne menacera pas beaucoup de dégâts.



Cette approche vous permet de manipuler les privilèges différemment qu'Unix le permet. Pour commencer, regardons ce problème déroutant d'autorité auquel l'auteur de l'article dont nous discutons Norman Hardy a été confronté et découvrons pourquoi elle était si perplexe.

Cet article a été écrit il y a longtemps et l'auteur utilise une structure syntaxique pour les noms de fichiers, ce qui est un peu surprenant. Mais nous pouvons au moins transcrire son problème dans une syntaxe de nom de style Unix plus familière.

Pour autant que je sache , il a utilisé le compilateur Fortran , qui était situé dans / sysx / fort , et il voulait changer ce compilateur pour garder des statistiques sur ce qui était compilé, quelles parties du compilateur étaient les plus gourmandes en ressources et ainsi de suite. Par conséquent, il voulait s'assurer que ce compilateur Fortran fournirait en quelque sorte une entrée dans le fichier / sysx / stat et qu'il écrirait ici des informations sur les différents appels du compilateur.



Leur système d'exploitation avait quelque chose comme la fonction setuid dont nous avons parlé sur Unix . Ils l'ont appelé la licence de fichier personnel. Cela signifiait que si vous exécutiez / sysx / fort et que ce programme avait une soi-disant licence de fichiers personnels , ce processus que vous venez de lancer aura des autorisations d'écriture supplémentaires pour tout dans / sysx / . Autrement dit, vous pouvez écrire après la barre oblique tout ce qui est généralement marqué d'un astérisque, obtenant une expression de la forme / sysx / * . Cela donnait accès à tous les fichiers écrits dans le répertoire après / , et l'utilisateur pouvait les exécuter. Par conséquent, le problème spécifique auquel ils étaient confrontés était qu'une sorte d'utilisateur intelligent pouvait le faire en exécutant le compilateur pouvait prendre beaucoup d'arguments comme le fait GCC .

Un tel utilisateur pourrait, par exemple, collecter quelque chose comme foo.f , où f est le code source de Fortran , et ajouter ici - o / sysx / stat .



Ils avaient un autre fichier dans le système / sysx , qui était un fichier de facturation pour tous les clients du système. Ses dégâts feraient encore plus de dégâts. De la même manière, il était possible de «demander» au compilateur de compiler le fichier source / sysx / bill et de le placer dans un fichier spécial dans / sysx . Et dans leur cas, cela a fonctionné. Malgré le fait que l'utilisateur lui-même n'avait pas accès en écriture à ce fichier ou répertoire, il a utilisé le compilateur, qui avait ce privilège supplémentaire - une licence pour les fichiers personnels. Grâce aux privilèges du compilateur, il a pu remplacer des fichiers contrairement aux intentions du développeur.



Qui devraient-ils blâmer pour ce qui s'est passé? Que pensent-ils qui a mal tourné? Auriez-vous pu agir différemment pour ne pas rencontrer de tels problèmes? Ils pensaient que le compilateur Fortran serait très prudent lors de l'utilisation de ses privilèges. En fait, à un certain niveau, le compilateur Fortran dispose de deux types de privilèges qu'il utilise.

L'un, le principal, est basé sur le fait que si l'utilisateur a appelé le compilateur, il devrait pouvoir accéder au fichier source, tel que foo.f. Et si c'était un autre utilisateur qui ne s'activait pas ou n'appelait pas le compilateur, un tel utilisateur ne pourrait pas accéder au code source de l'utilisateur "correct".

Le deuxième type de privilège est fourni par cette même licence, qui vous permet d'écrire ces fichiers spéciaux. Au niveau interne du code source du compilateur, il aurait dû y avoir des instructions claires sur lequel de ces privilèges il veut utiliser lors de l'ouverture d'un fichier ou lors de l'exécution d'une opération privilégiée. Il pourrait simplement ouvrir, lire et écrire des fichiers comme n'importe quel autre programme. Il utilise implicitement tous les privilèges qu'il possède, c'est-à-dire que dans la conception de leur système, il s'agissait d'une sorte de combinaison de privilèges utilisateur et de licences pour l'utilisation des fichiers personnels.

Ces gars étaient donc vraiment intéressés à résoudre ce problème. Et ils ont en quelque sorte appelé ce compilateur un «aide stupide», car il devait faire la distinction entre les nombreux privilèges qu'il avait et les utiliser avec soin si nécessaire.

Donc, nous devrions considérer comment développer un compilateur similaire sur Unix . Dans leur système, tout était lié à cette licence de fichier. Il y a d'autres mécanismes qu'ils ont ensuite introduits dans leur programme pour identifier les opportunités, nous en parlerons dans un avenir proche. Mais pouvons-nous résoudre ce problème sur un système Unix ?

Supposons que vous deviez écrire ce compilateur Fortran sous Unix , écrire ce fichier spécial et éviter le problème. Que feriez-vous? Des idées? Je pense que vous pouvez simplement déclarer cela comme un mauvais plan et, par exemple, ne pas tenir de statistiques. Ou ne prennent pas en charge le type d'entrée de données - oh . D'un autre côté, vous pouvez spécifier le code source que vous souhaitez compiler afin de pouvoir lire le fichier / bill ou le fichier de statistiques, qui peut avoir besoin d'être secret.

Ou peut-être pourriez-vous prendre en charge le code source standard, mais il devrait alors contenir des parties d'un autre code source, ce qui est un peu absurde.

Public: on pourrait partager les privilèges du compilateur.

Professeur: oui, ce serait une autre conception potentiellement bonne partageant ses informations d'identification. Nous savons qu'en fait, le compilateur Fortran n'a pas besoin des deux privilèges en même temps. Donc, peut-être, en parlant sous Unix , nous pourrions créer un compilateur comme world / bin / fortcc , et ce ne serait qu'un programme normal sans privilèges supplémentaires. Et puis nous créerions / bin / fortlog , qui sera un programme spécial avec quelques privilèges supplémentaires, et il collectera des statistiques sur ce qui se passe dans le compilateur, et la fonction fortcc appellera fortlog . Alors, quels privilèges accorderions-nous à ce fortlog ?



Public: peut-être que si vous utilisez quelque chose comme setuid ou fortlog , tout autre utilisateur peut également enregistrer des données arbitraires via celui-ci.

Professeur: oui, donc ce n'est pas si bien. Parce que la seule façon sous Unix de donner des privilèges supplémentaires à fortlog est de devenir son propriétaire, je ne sais pas, peut-être de créer fort UID et setuid . Et chaque fois que vous exécutez fortlog , il passe à cet UID de fort . Et, peut-être, un fichier de statistiques spécial est encore nécessaire ici. Mais après tout, tout le monde peut appeler ce fortlog .



Et ce n'est pas bon, car n'importe qui peut écrire dans le fichier de statistiques. Dans ce cas, pour la sécurité, c'est un petit problème, mais que se passe-t-il si au lieu de stat il s'agit d'un fichier de paiement de facture ? Dans ce cas, les problèmes seront beaucoup plus graves.

Unix a un mécanisme assez compliqué, que nous avons omis lors de la dernière conférence de lundi. Ce mécanisme permet à l'application de basculer entre plusieurs UID . Ainsi, pour exécuter différentes applications, vous pouvez basculer entre les ID utilisateur. C'est un peu difficile à faire de la bonne manière, mais faisable. Ce mécanisme peut donc être une autre conception potentielle de notre système.

Je pense que vous pourriez faire une autre astuce: rendre l' exécutable «binaire» fortlog uniquement pour un certain groupe et créer le binaire fortcc setgid pour ce groupe. Cependant, ce n'est pas très bon, car cela efface toute liste de groupes que l'utilisateur avait à l'origine. Mais qui sait, c'est peut-être mieux que rien.

Dans tous les cas, c'est un problème assez compliqué, mais il peut être complètement résolu en utilisant les mécanismes Unix . Vous devriez peut-être repenser votre problème et ne pas vous inquiéter trop du fichier de statistiques stat , en mettant sa sécurité au premier plan. Qu'est-ce qui ne va pas dans notre projet?

Il y a deux choses à surveiller en cas de problème. La première est appelée autorité ambiante ou autorité externe. Quelqu'un comprend-il ce qu'il voulait dire? Ils n'ont jamais donné cette définition exacte.

Public: cela signifie que vous avez l'autorité qui vous est donnée par l'environnement. Comme si vous étiez un utilisateur agissant sans restrictions.

Professeur: oui, vous effectuez une opération, et vous pouvez indiquer quelle opération vous souhaitez effectuer, mais la décision quant à la réussite de cette opération vient de certains paramètres indirects supplémentaires dans votre processus.

Sous Unix, vous pouvez déterminer à quoi ressemblera la vérification des autorités environnementales. Par conséquent, si vous effectuez un appel système, vous avez probablement donné un nom à l'appel système. Et à l'intérieur du noyau, ce nom est mappé à un objet. Et cet objet contient soi-disant une sorte de liste de contrôle d'accès, par exemple, les autorisations pour ce fichier et ainsi de suite.



Par conséquent, vous pouvez obtenir certaines autorisations de cet objet et vous devez déterminer si l'opération portant ce nom qui a été accordée à l'application sera autorisée, c'est-à-dire que la chaîne Nom -> Objet -> Autorisation est créée . C'est ce que l'application obtient pour voir le processus.

À l'intérieur du noyau, il y a l'ID utilisateur actuel du processus UID de processus qui effectue des appels. Il participe également à la décision d'autoriser ou non l'exécution d'une opération particulière. Ainsi, cet ID utilisateur de processus actuel est un privilège externe. Le noyau essaiera de vérifier toute opération que vous souhaitez effectuer à l'aide de votre UID actuel, de votre GID actuel et de tout autre privilège supplémentaire que vous pourriez avoir. Et bien qu'il existe un certain ensemble de privilèges qui vous permettent de le faire, vous pouvez le faire. Cependant, il est possible que vous ne souhaitiez pas utiliser tous ces privilèges pour ouvrir un fichier spécifique ou effectuer toute autre opération.

Comprenez-vous ce que sont ces privilèges ambiants, privilèges externes? Dans le cas du système d'exploitation, cela signifie que le processus a une sorte d'ID utilisateur. Pouvez-vous donner des exemples de tels privilèges qui ne sont pas liés au système d'exploitation? Par exemple, lorsque vous effectuez une opération d'identification de processus pour savoir si elle a réussi ou non. Un pare-feu peut servir d'exemple - si vous êtes à l'intérieur du réseau ou avez une adresse IP interne, vous êtes autorisé à effectuer une sorte d'opération, et si vous êtes à l'extérieur du réseau, la même opération sera interdite pour vous.

Disons que vous visitez un site Web qui contient un lien vers un autre serveur et que vous ne souhaitez peut-être pas utiliser les privilèges dont vous disposez pour suivre ce lien. Parce que peut-être cela donnera à quelqu'un accès à votre imprimante réseau interne et que quelqu'un pourra l'utiliser. Mais en réalité, celui qui vous a fourni le lien ne doit pas accéder à votre imprimante, car elle est située en dehors du réseau. Ou le pare-feu de votre navigateur, en visitant ce lien, peut le faire de manière frauduleuse.



C'est une sorte d'équivalent moral de ce problème déroutant dans les modèles de réseau.

Public: les autorisations existantes affectent également cela.

Professeur: oui.

Public: parce que Capsicum utilise essentiellement DAC - contrôle d'accès discrétionnaire.

Professeur: oui, c'est en grande partie parce que les gars de Capsicum utilisent quelque chose comme le contrôle d'accès discrétionnaire. Cela signifie que l'utilisateur ou le propriétaire de l'objet décide à quoi ressemblera la politique de sécurité de cet objet. Pour Unix, c'est très naturel - ce sont mes fichiers, et je peux décider ce que je veux en faire, je peux vous les donner ou les garder. Ainsi, presque tous les systèmes DAC ressemblent à ceci car ils ont besoin d'une sorte d'autorisations que l'utilisateur peut modifier pour gérer la politique de sécurité de leurs fichiers.



Le revers du DAC est le contrôle d'accès obligatoire. Nous en parlerons plus tard, mais à un certain niveau, ces systèmes ont une vision très différente du monde. Ils pensent que vous n'êtes qu'un utilisateur d'ordinateur et que quelqu'un d'autre définit une politique de sécurité pour l'utilisation de cet ordinateur. Ce point de vue est venu des années 70 ou 80, lorsque les militaires voulaient vraiment avoir des systèmes informatiques secrets dans lesquels vous travaillez sur certaines choses qui sont marquées comme «secrètes». Et si vous travaillez sur des choses marquées comme «secrètes» et que je travaille sur des choses étiquetées «top secrètes», elles ne peuvent pas vous obtenir aussi facilement. Mais je n'ai pas besoin de définir les droits sur le fichier et ainsi de suite, il n'est tout simplement pas autorisé par une sorte de top guy.

Ainsi, le contrôle d'accès obligatoire essaie vraiment de mettre différents types de politiques d'accès en premier lieu où il y a un utilisateur et un développeur d'application, et à côté d'eux, il y a un autre gars qui définit cette politique. Cependant, comme vous pouvez le deviner, cela ne fonctionne pas toujours. Nous en reparlerons un peu plus tard. Mais c'est le sens essentiel du contrôle d'accès discrétionnaire.

Nous avons de nombreux autres exemples d'utilisation du contrôle d'accès externe. Ce n'est pas nécessairement mauvais, il suffit d'être très prudent lors de son utilisation. Si vous disposez d'un système de privilèges ambiants , vous devez être très prudent lors de l'exécution d'opérations privilégiées. Vous devez vous assurer que vous utilisez vraiment les bonnes autorisations et vous ne serez pas trompé accidentellement, comme avec ce compilateur Fortran il y a près de 25 ans.

C'est donc l'une des interprétations de ce qui se passe. Et ce n'est pas nécessairement la seule façon de penser à ce qui ne va pas, non? Une autre possibilité est que ce serait bien si l'application elle-même savait si elle devait accéder au fichier au nom d'un principe. Par conséquent, le problème numéro 2 est la complexité des vérifications de contrôle d'accès.



Dans un sens, lorsque le compilateur Fortran est en cours d'exécution, il ouvre le fichier au nom de l'utilisateur, et vous devez répéter la même logique que nous voyons ici dans le diagramme, sauf que le compilateur Fortran doit connecter autre chose pour l' UID du processus Sur . Au lieu d'utiliser les privilèges actuels, il devrait simplement répéter la vérification Nom -> Objet -> Autorisation et essayer de le faire avec un ensemble différent de privilèges pour l' UID du processus .

Sous Unix, cela est assez difficile à faire, car il existe de nombreux endroits où les contrôles de sécurité ont lieu. Si vous disposez de liens logiciels symboliques, le lien symbolique est analysé et le nom du chemin d'accès est également évalué avec certains privilèges, etc. Mais il peut arriver que dans certains systèmes, vous puissiez simplifier la vérification du contrôle d'accès si cela peut être fait indépendamment dans l'application. Ne pensez-vous pas que c'est un plan intelligent? Êtes-vous d'accord avec cela? Y a-t-il un danger de répéter ce test?

Public: si vous effectuez des vérifications dans l'application, vous ne pouvez tout simplement pas effectuer d'autres vérifications.

Professeur: oui, vous pouvez facilement sauter d'autres vérifications, c'est absolument vrai. Donc, d'une certaine manière, quand ils ont utilisé le compilateur Fortran ici, il n'a même pas essayé de faire de vérifications, alors ils ont échoué. Une autre conséquence, en plus du manque de vérifications, est que le noyau peut changer tout le temps, puis il aura des vérifications légèrement différentes. Cela introduira des exigences de sécurité supplémentaires, mais l'application ne changera pas et implémentera l'ancien style de contrôles. Ce n'est donc pas un bon plan.

N'oubliez pas qu'il y a une bonne idée dans le domaine de la sécurité - une réduction du nombre de mécanismes impliqués. Par conséquent, le programme ne dispose que d'un petit nombre d'emplacements dans lesquels les politiques de sécurité sont appliquées. Vous ne voulez probablement pas répéter la même fonctionnalité dans les applications, dans le noyau, etc. Vous voulez vraiment concentrer ces contrôles en un seul endroit dans le programme. Alors, quelle devrait être la solution au problème de l'octroi de l'autorité?

Les capacités de description de fichiers sur Unix sont les plus proches de la résolution du problème.



Dans le monde des possibilités, une alternative à ce schéma est qu'au lieu de suivre la chaîne Nom -> Objet -> Autorisation et de décider de l'utiliser ou non en fonction des autorisations externes de l' UID du processus de processus , vous pouvez utiliser un schéma très simple.

Supposons que vous ayez des capacités liées à un objet spécifique. Et ces fonctionnalités peuvent avoir un certain nombre de limitations quant à ce que vous pouvez faire avec cet objet.



Mais en gros, si vous avez des opportunités pour cet objet, vous pouvez y accéder. . , , , .
, Capability , , , , . . Capability , - , — .

Capability , . , ?

, , . , . , , .

, , , « ». , , Capsicum ? ?

: , , , Capability .

: , , , , . — . Unix , 0, , 1, . . , , . , - , , . PID , , PID:57 , . , , . , , , , , .. .



, , , . , -, - , .

, , , Unix , , , /etc/pwd .

. . , . , « »?



, , integer . , . , .

, . , ? , . , .

, , Capability , Fortran . sysx/fort ? , ?

: , . , , output- . , , .

: , . , Fortran /sysx/stat . , .

, , . , , «» Unix . , , , Fortran , , , , , .

. fort1 , , - , , foo.f , , , — o , . , . , .

, , , . ! , , , , setuid Fortran .



, setuid - , . , . , , , , .

, , , , . , , , Capability , , , , .

26:30

:

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


La version complète du cours est disponible ici .

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?