Cours MIT "Sécurité des systèmes informatiques". Conférence 4: «Partager les privilèges», 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

Aujourd'hui, nous allons parler de partage des privilèges, puisque nous nous sommes retrouvés avec des dépassements de tampon à un certain niveau, mais nous y reviendrons. Nous ne parlerons pas des détails sur la façon d'utiliser les débordements de tampon, mais passerons à la réduction de ce problème et parlerons de la façon de développer un système dans lequel les débordements de tampon ne seront pas un gros problème pour vous, comme d'autres vulnérabilités.



Donc, aujourd'hui, nous parlerons du partage des privilèges comme méthode qui vous permet de créer un système plus sécurisé, et dans les documents de cours, nous mentionnons un serveur Web appelé OKWS . Ce n'est pas l'exemple le plus révélateur de la séparation des droits, mais le système y est bien décrit pour comprendre comment toutes ses parties fonctionnent. Mais cela ne signifie pas que vous devez y aller dès maintenant, télécharger OKWS et lancer votre site.

Donc, avant de nous plonger dans les détails des autorisations OKWS et Unix, voyons ce qu'est le partage de privilèges et pourquoi c'est une si bonne idée? La semaine dernière, James a montré que si vous écrivez un programme en C, vous aurez presque inévitablement quelque chose de mal ou de mal dedans. De plus, le problème est que si vous avez une application suffisamment grande et qu'il y a une sorte de vulnérabilité, les attaquants peuvent se connecter au programme, envoyer des requêtes à cette application, la piéger et faire de «mauvaises» choses.

Toute application dispose de privilèges d'accès. Cela signifie qu'il comprend un grand nombre de données qui peuvent être obtenues avec accès. Vous pouvez même supprimer ces fichiers, comme vous l'avez fait dans le laboratoire numéro 1. Le problème est qu'une vulnérabilité dans cette grande application pourrait permettre à un attaquant de modifier l'une de ces données ou d'acquérir suffisamment de privilèges pour gérer le programme si vous n'y faites pas attention.
Dans cette conférence, nous verrons ce que les privilèges de partage essaient de faire. Il vaut la peine de prendre le programme, de le diviser en parties et de s'assurer que chacun des éléments individuels n'a que les privilèges nécessaires pour effectuer correctement son travail.



À gauche, nous avons un programme en 3 parties, et à droite, des données, également composées de trois parties. Des privilèges correctement attribués signifient que chaque partie de l'application n'a accès qu'à sa partie des données. Et si nous avons une vulnérabilité dans le programme X, cela nous permettra de prendre le contrôle d'une seule partie des données et ne pourra pas affecter les données des deux autres parties.
Cette idée de partager des privilèges est donc extrêmement forte. Il ne sert pas à affecter spécifiquement le problème des débordements de tampon ou d'autres vulnérabilités; ce sont simplement des exigences générales pour l'architecture des produits logiciels pour garantir que les vulnérabilités à un endroit du système n'affectent pas ses autres parties. La séparation des privilèges est largement utilisée. Ainsi, pour assurer l'isolement des composants au sein d'un programme, les machines virtuelles sont souvent utilisées.

Vous pouvez prendre votre grand système et le diviser en un tas de machines virtuelles pour isoler les différentes parties, mais vous pouvez également utiliser Unix pour réellement effectuer cette isolation avec un «découpage». Unix fournit plusieurs mécanismes qu'OKWS utilise réellement pour séparer les privilèges.

De nombreuses applications utilisent en fait des pratiques de partage de privilèges. Vous avez probablement utilisé SSH, ou «shell sécurisé», assez souvent. Il s'agit d'un protocole réseau utilisé pour contrôler à distance le système d'exploitation et transférer des fichiers. Il utilise le partage de privilèges dans bon nombre de ses composants pour garantir que ses clés de chiffrement ne sont pas effacées et que le serveur ne sera pas compromis. Le navigateur Web Chrome est plus pertinent pour vous, dans lequel le partage de privilèges est également mis en œuvre assez largement. Donc, s'il y a une sorte de «bogue» dans Chrome, l'adversaire ne pourra pas contrôler totalement votre ordinateur.

Ceci est un très bref résumé de ce qu'est le partage de privilèges et pourquoi OKWS est un exemple intéressant. Cependant, il est plus un exemple vivant qu'un logiciel important.

Ainsi, OKWS , comme je l'ai mentionné, utilisera les autorisations Unix et une sorte de mécanismes Unix pour séparer les différents composants. Il est important pour nous de comprendre le fonctionnement des mécanismes de sécurité Unix. Unix en tant qu'outil de partage de privilèges est important non seulement pour comprendre OKWS , mais, comme tout autre outil d'isolation, comme UID , VM , conteneurs ou toute technologie similaire, vous permet de comprendre les détails du processus. Parce qu'il existe de nombreuses parties complexes du processus d'obtention des droits d'accès, et vous pouvez faire face à un attaquant qui profitera de la vulnérabilité de l'une de ces parties. Par conséquent, nous examinerons Unix de manière suffisamment détaillée pour comprendre de quoi il s'agit et à quoi il devrait ressembler dans un mécanisme de sécurité particulier.

Unix a toujours été le meilleur exemple de la manière de construire un mécanisme de sécurité. Son mécanisme de sécurité est apparu dans le processus de satisfaire le besoin de séparer les utilisateurs les uns des autres sur le même système Unix. En même temps, on pensait qu'il y avait un tas d'utilisateurs qui utilisent le même ordinateur, et vous devez les garder séparés les uns des autres. Ainsi, ce n'est pas nécessairement un mécanisme à usage général, mais toujours l'un des plus courants et largement utilisés. Chrome essaie donc d'utiliser de nombreux mécanismes de partage de privilèges d'Unix.

Lorsque vous pensez à un mécanisme de protection, vous devez penser à ses principes, ce qui signifie qu'il y a quelqu'un avec des privilèges ou des droits, et Unix initie ou prend en charge ces droits. Par conséquent, je pense que le sujet ou le sujet d'Unix est un processus, car un processus est pris en charge, car chaque opération ou demande que nous considérons d'un point de vue de la sécurité devrait autoriser ou refuser quelque chose. Ce sera probablement l'opération appelée par le processus en effectuant l' appel système syscall . Ce qui importe ici, c'est la façon dont nous décrivons les privilèges de ce processus.

Ensuite, il y a un objet que notre processus agit comme un sujet. Il peut modifier des objets, les lire, les observer. Il existe de nombreux objets dans le système d'exploitation que vous devez vous soucier de protéger. De quels objets pensez-vous que nous devrions nous préoccuper?

Public: à propos des fichiers!

Professeur: à droite, sur les fichiers et les répertoires. Quoi d'autre?



Public: à propos des sockets réseau!

Professeur: oui, très bien sur les sockets réseau. Y a-t-il autre chose qui se passe dans notre système?

Public: autres processus.

Professeur: C'est vrai. En fait, cela est similaire à ce dont l'application ou l'utilisateur doit s'occuper, mais il y a divers composants internes du système que vous devez également protéger. Par conséquent, le processus lui-même n'est pas le sujet qui appelle le système, c'est aussi quelque chose sur lequel un autre processus peut agir. Il peut le tuer ou en créer un nouveau. Par conséquent, vous devez savoir quelles sont les règles pour percevoir un processus comme un objet pouvant être manipulé. Quelles autres choses peuvent nous inquiéter?

Public: variables d'environnement.

Professeur: Je pense que ce n'est probablement pas un sujet que vous pouvez changer dans le sens de la gestion des OC et de la mise en place d'une politique de sécurité. Je pense que les variables d'environnement ne sont qu'une sorte d'état d'un processus contenu dans la mémoire. Mais, je pense que, plus généralement, nous nous soucions de cette partie du processus, qui est contenue dans la mémoire - variables d'environnement, piles, arguments, c'est aussi très important. Probablement, dans la mémoire du processus, il y a beaucoup de choses qui sont sensibles aux interférences extérieures. Quoi d'autre?

Public: descripteurs de fichiers en général.

Professeur: il y a une autre circonstance interne qui est d'une grande importance. Les fichiers qui se trouvent sur le disque devraient nous concerner. Mais il existe toujours un outil opérationnel tel qu'un descripteur de fichier, qu'OKWS essaie d'utiliser largement, et nous verrons ce qu'il est. Quelles autres choses aimeriez-vous protéger dans le système d'exploitation?



Public: matériel ou matériel.

Professeur: oui, le matériel nécessite une protection au moins égale aux éléments abstraits que nous fournit le système d'exploitation, car nous ne voulons pas que notre processeur se "fige" pour une raison quelconque.

Public: Vous devez également penser à protéger les périphériques!

Professeur: Oh oui! Donc, les appareils supplémentaires, vous avez raison, en particulier sur un ordinateur de bureau, il y a beaucoup de choses inutiles: une clé USB, une webcam, probablement l'écran lui-même - vous voudrez protéger une partie de cela, car les applications qui leur sont liées ne devraient pas "marcher" »Partout sur votre écran.

Je pense, en fait, que tous ces objets ne sont pas du côté serveur, ils sont juste assez proches. Sur votre téléphone, le microphone est probablement aussi un objet très important que vous souhaitez également protéger.

Mais je vais laisser cette liste, car dans ce qui suit nous parlerons principalement des applications serveur, mais vous avez absolument raison sur la liste des objets. Je pense que pour OKWS, c'est probablement une liste plus ou moins exhaustive de choses que nous pourrions prendre soin de protéger, ou du moins qui utilise OKWS .

Parlons donc de la façon dont le noyau du système d'exploitation décide quand un processus peut faire quelque chose avec l'un de ces objets. Par conséquent, à un niveau élevé, nous considérons principalement le processus comme une entité ayant les privilèges accordés par ce principe, et le principe dans le système Unix est une chose assez compliquée.

Il y a quelque chose appelé User ID , qui est un entier 32 bits. Il existe un ID de groupe , qui est également un entier 32 bits. En fait, il n'y a aucune raison particulière pour laquelle ils devraient être différents.



Ce serait bien s'ils ne constituaient qu'un seul ensemble d'entiers 32 bits, mais, malheureusement, Unix les divise en deux catégories. Il existe des entiers ID utilisateur et des entiers ID groupe . Lorsque nous parlons d'un processus qui a certains privilèges, nous entendons un processus associé à une certaine valeur uid . En règle générale, un processus a un uid , ainsi qu'une liste d'identifiants de groupe gid que le processus possède. Pour des raisons historiques, il s'est avéré qu'ils sont combinés en un seul gid , puis combinés en une liste d'autres identifiants. En gros, un processus peut exercer les privilèges représentés par tous ces identifiants. Donc, si uid donne accès à quelque chose, le processus peut tout faire avec.

Parlons maintenant des fichiers, des répertoires et d'autres types d'objets. Alors, qu'advient-il des fichiers, ou plutôt, comment créer des autorisations Unix pour travailler avec des fichiers? Tout est relativement simple avec les fichiers; vous êtes préoccupé par les opérations qui peuvent être effectuées avec eux: lecture, écriture, éventuellement exécution, ainsi que la possibilité de modifier les autorisations elles-mêmes ou d'autres propriétés de sécurité.

Public: rompre les liens!

Professeur: oui, rupture de liens, dissociation - selon vous, quelle est la propriété du fichier ou du répertoire lui-même? En fait, cette distinction n'est pas claire. Lorsque Unix pense à supprimer un fichier, il s'agit davantage du répertoire, car sous Unix, le fichier est vraiment un inode ou un inode. Par conséquent, sur Unix, vous pouvez avoir des liens durs vers des inodes et lorsque vous déconnectez un nom de fichier Unix spécifique à l'aide de unlink, vous ne détruisez en fait qu'un seul des noms de fichier, mais il peut avoir d'autres noms et d'autres liens. En fait, il est important de savoir si vous êtes autorisé à modifier le répertoire pointant vers le fichier et en même temps à ne rien faire avec l' inode du fichier lui-même. Les opérations de dissociation , de liaison , de changement de nom et de création sont donc généralement des opérations associées à un répertoire. Par conséquent, nous devons savoir quelles règles s’y appliquent.



Afin de décider que quelqu'un peut lire ou écrire un fichier, nous allons insérer quelques autorisations, ou bits, dans le fichier inode . Sous Unix, chaque inode qui est finalement un fichier ou un répertoire a plusieurs champs intéressants pour des raisons de sécurité. Voici l'ID utilisateur et l'identifiant du groupe qui, comme on dit, est propriétaire du fichier ou propriétaire du répertoire. Ainsi, vous pouvez gérer tous les fichiers de votre répertoire personnel car Unix a votre UID .
Unix possède également un ensemble de bits d'autorisation qui peuvent être considérés comme faisant partie de la matrice, dans la conception de base, ils ressemblent à r (lecture), w (écriture) et x (exécution). Nous pouvons spécifier ces autorisations pour diverses entités, et sur Unix, elles sont spécifiées pour le propriétaire propriétaire , c'est-à-dire pour l' inode uid , pour le groupe de groupe auquel appartient le fichier donné, c'est-à-dire pour gid et pour tous les autres - autre .

Vous pouvez remplir cette matrice binaire 3 par 3, où 1 signifie l'autorisation d'effectuer une certaine action et 0 interdit son exécution:



C'est ainsi qu'Unix stocke les autorisations. Il existe une manière traditionnelle de coder ces choses que vous verrez souvent et qui mérite probablement d'être mentionnée. Sous Unix, cette matrice est codée comme un nombre octal, donc chaque ligne ici doit être considérée comme un nombre de base de 8, donc notre matrice dans cet encodage ressemblera à ceci: r est 4 bits, w est 2 bits, x est 1 bit, respectivement, propriétaire - c'est 6 bits, et le groupe et les autres contiennent chacun 4 bits.



Vous verrez souvent de telles désignations dans les documents de cours, vous pouvez donc dire que ce fichier a une résolution de 6, 4, 4, c'est-à-dire que le propriétaire peut lire et écrire le fichier et que le propriétaire du groupe et les autres ne peuvent que le lire.

Ces notations nous indiquent quand lire, écrire et exécuter un fichier. Qu'en est-il de la modification des autorisations pour ce fichier? Ce n'est pas une question juste, mais qu'en pensez-vous? Comment devrions-nous décider que quelqu'un devrait pouvoir modifier ces autorisations, car cela pourrait également être nécessaire? Des réflexions à ce sujet?

Public: si cette personne a accès au fichier?

Professeur: cela dépend peut - être aussi des privilèges d'accès. D'autre part, vous pouvez créer un fichier réinscriptible réinscriptible que vous souhaitez partager avec quelqu'un afin qu'il puisse lire, ajouter et modifier votre fichier, mais cela signifie également que vous pouvez changer soudainement les autorisations pour rendre le fichier non réinscriptible ou attribuer seulement pour moi.

Par conséquent, les créateurs d'Unix ont décidé que si vous avez un fichier, c'est-à-dire que votre uid correspond à l' uid entré dans le fichier, alors par défaut, vous pouvez modifier les autorisations. Sinon, vous ne pouvez pas. Par conséquent, si vous n'avez que gid et que ce groupe dispose de toutes les autorisations dans le fichier, vous ne pouvez toujours pas modifier les autorisations pour ce fichier. Vous pouvez simplement lire, réécrire, faire quoi que ce soit avec, mais sans uid, vous ne pouvez pas modifier les autorisations.

Les répertoires Unix suivent les mêmes règles. Ainsi, le détachement de la dissociation et la liaison des entrées de lien dans un répertoire signifie que vous êtes autorisé à écrire dans ce répertoire. Si vous souhaitez renommer un fichier, vous devez probablement avoir un accès en écriture au répertoire d'où vous l'avez obtenu et un accès en écriture au répertoire dans lequel vous l'avez placé. Dans certains cas, les liens durs peuvent causer des problèmes et dans les documents de cours, ces détails sont mis en évidence.

En fait, il y a une autre opération intéressante dans le catalogue - la recherche. Grâce à elle, vous pouvez simplement retrouver le fichier dans le répertoire. Unix encode les autorisations d' exécution comme la possibilité d'implémenter une recherche de répertoires, donc avoir l'autorisation d' exécution pour un répertoire signifie en fait être capable de rechercher un nom de fichier spécifique. Il se peut que vous n'ayez pas besoin d'avoir l'autorisation sur le répertoire pour rechercher le nom du fichier, mais si vous n'avez pas l'autorisation de lecture, vous ne pourrez pas afficher le contenu du répertoire, c'est-à-dire trouver le fichier. Ceci est utile dans certaines situations où vous devez restreindre les actions avec certains fichiers ou les masquer à l'utilisateur.

Regardons un exemple. Que se passe-t-il sous Unix si j'entre la commande open ("/ etc / password") ? Qu'est-ce qui vérifie le noyau du système en mon nom lorsque je lui commande de passer un appel système?

Public: Vérifie-t-il si vous avez la permission d'exécuter, etc.?

Professeur: Oui, dans une certaine mesure, c'est le cas. J'ai besoin de faire quelque chose, etc.

Public: puis exécutez la barre oblique spécifiée!

Professeur: oui, en fait, je dois regarder vers quoi / etc pointe? Donc, si je ne comprends pas les autorisations root - les droits, cela ne fonctionnera pas.

Public: alors vous devez lire / etc / password .



Professeur: oui, cela a du sens. Voici un petit puzzle pour vous. Supposons que le MIT crée un groupe pour toutes les personnes associées au cours 6.858, et d'autres groupes pour tous les TA dans le MIT, qui dans la terminologie Unix est désigné comme gids , mais ils ne sont pas inclus dans le groupe TA 6.858 pour des raisons stupides. Comment puis-je créer un fichier qui sera disponible uniquement pour le groupe TA 6.858?

Supposons que j'ai 6,858 gid et TAs gid, mais je ne peux insérer qu'un seul gid dans le fichier.

Public: Vous ne seriez pas en mesure de le faire, car ici vous pouvez avoir des TA, pas 6.858 TA.

Professeur: oui, c'est vrai. Bien qu'il y ait des étudiants dans le groupe 6.858 qui sont TAs d'autres classes, alors peut-être que ce n'est pas vraiment génial. Mais, néanmoins, essayons de faire en quelque sorte les intersections de ces groupes. Pour ce faire, nous pouvons utiliser le mécanisme d'autorisation.
/foo/bar/grades , foo , gid 6.858 . , , /foo . /bar , gid TAs, . /foo/bar/ , grades . , .



: , , , , 6.858 gid, TA - - 6.858 ?

: , . , , , Unix , , , , , . , MACS — mandatory accesscontrol systems, . , , : , . . , - .

Unix , , , TA - , Unix . , - . - , Unix , , . , , . , , , . , . Unix.

, , , , - , . - , , , .

, , Unix.

, — . OKWS , Unix . Unix , . , «» , .

, : , . , . - , , Unix – , , , , .

– Unix - , .

OKWS , . , , , - , . , , , - . - , .

, . , , .

? ? ? Unix . , , – Unix , ptrace .



. , , , , , . , , web , gid TAs, .

, , . userid . ptrace — uid uid .

ptrace Linux . , , , - , , , . - . , ID.

27:50

:

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


.

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?