6.4 Zugriffsschutz Betriebssystem muss Betriebssicherheit garantieren: unerwünschte Auswirkungen von Hardware/Software-Fehlern ( „safety“) von absichtlichen Manipulationen ( „security“) sollen verhindert, begrenzt, oder zumindest erkannt werden. bs-6.4

Beispiele für Folgen von Sicherheitslücken im Betriebssystem: Systemabsturz, verursacht durch Hardware-Fehler, Betriebssystem-Fehler, Programmfehler, Sabotage Monopolisierung von Ressourcen Ausspionieren vertraulicher Daten Verfälschen oder Löschen fremder Daten bs-6.4

Beispiele für Sicherheitsmaßnahmen des Betriebssystems: Wiederholung von Lese/Schreibversuchen nach Fehler Geordnetes Abschalten bei Stromausfall Zugangskontrolle mit Passwortsystem Virtualisierung von Ressourcen ! bs-6.4

Wichtigste Kategorie von Sicherheitsmaßnahmen gegen geplante Angriffe ( „security“) ist Zugriffsschutz (access protection, access control): Objekte (z.B. Geräte, Segmente, Dateien!, ...) werden vor unerwünschten Zugriffen geschützt; Subjekte (z.B. Prozesse, Programme) sind die Auslöser der Zugriffsversuche. Zugriffsschutzsystem (protection system, reference monitor) weiß, was erlaubt bzw. verboten ist, überwacht alle Zugriffsversuche und verhindert sie gegebenenfalls. bs-6.4

6.4.1 Autorisierung eines Prozesses = Menge von Attributen eines Prozesses, die für die Überwachung des Zugriffs auf Dateien (manchmal auch für andere Systemaufrufe) relevant sind, z.B. Benutzerkennung (user identity), Ermächtigungsstufe (clearance), Rolle des Benutzers (role), . . . . . bs-6.4

Jeder Benutzer hat einen Login-Namen und ist einer Beispiel Unix: Jeder Benutzer hat einen Login-Namen und ist einer oder mehreren benannten Benutzergruppen zugeordnet. Systemintern werden Benutzer und Gruppen durch Nummern identifiziert, UID - user identifier ( 0 für Systemverwalter root) GID - group identifier ( 0 für Systemgruppe wheel) die man in den Einträgen von /etc/passwd und /etc/group finden kann: bs-6.4

Eintrag von /etc/passwd : lohr:X4sCwh/Da%pT2:123:97:Peter Löhr:/usr/lohr:/bin/csh UID GID (Primärgruppe) Eintrag von /etc/group : prof:5p%swAxb72WzG :97 :alt,fehr,graf,..... Jeder Benutzer gehört zu einer Primärgruppe, die in der Passwortdatei für ihn vermerkt ist, kann aber weiteren Gruppen angehören. bs-6.4

Autorisierung eines Prozesses besteht aus RUID – real userid, EUID – effective userid, RGID – real groupid, EGID – effective groupid, Initialisierung: bei fork werden diese Attribute vom Erzeuger kopiert. Abfragen: getuid() liefert RUID geteuid() liefert EUID getgid() liefert RGID getegid() liefert EGID bs-6.4

Ändern der Autorisierung ist stark eingeschränkt: setuid(uid) Vor.: uid == RUID oder EUID == 0 (d.h. Super-User root) Eff.: RUID == EUID == uid setgid(gid) ( = dasselbe für groupid) Vor.: gid == RGID oder EUID == 0 (d.h. Super-User root) Eff.: RGID == EGID == uid bs-6.4

exec(prog,...) berücksichtigt Dateiattribute von prog: UID (Eigner) GID (Eignergruppe) SUID („setuid bit“) SGID („setgid bit“) Eff.: RUID und RGID bleiben unverändert, aber: wenn SUID, dann EUID == UID ; wenn SGID, dann EGID == GID . ? Wozu ist das gut ? bs-6.4

Datenabstraktion mit Programmiersprache: prozedurale Schnittstelle verborgene Datenrepräsentation

Datenabstraktion mit Programmiersprache: bei Dateien: prozedurale Schnittstelle Programme mit SUID und UID = y verborgene Datenrepräsentation Dateien mit UID = y syntaktisch über gleiche UID Kapselung

mit y-Autorisierung aus“ exec mit SUID und UID = y RUID = x EUID = x RUID = x EUID = y „x führt y-Programm mit y-Autorisierung aus“ setuid(x) bs-6.4

Beispiele: „Systemprogramme“ mit y = 0 (Super-User) passwd ändert nach Eingabe eines neuen Passworts das Passwort des Benutzers in der Passwortdatei login usr ändert nach korrekter Passworteingabe für usr die Autorisierung der Shell in diejenige für usr (!) su usr startet nach korrekter Passworteingabe für usr eine neue Shell mit der Autorisierung für usr (!) newgrp gr (Solaris) startet neue Shell mit neuer Autorisierung RGID/EGID gemäß Gruppe gr (RUID/EUID bleiben unverändert) Vor.: Benutzer muß der Gruppe angehören und ggfls. Gruppenpasswort kennen) bs-6.4

POSIX-Standard erweitert Autorisierung um sEUID , d.i. „saved EUID“ sEGID , d.i. „saved EGID“ Entsprechend geänderte setuid/setgid, z.B. setuid(uid) Vor.: (1) EUID == 0 (Super-User) oder (2) uid == RUID oder uid == sEUID Eff.: EUID == RUID == sEUID == uid im Fall (1), sonst lediglich EUID == uid bs-6.4

 beliebiges Hin- und Herschalten der EUID ! RUID = x EUID = x sEUID = .... RUID = x EUID = x sEUID = y setuid(x) exec mit SUID und UID = y RUID = x EUID = y sEUID = y setuid(y)  beliebiges Hin- und Herschalten der EUID ! bs-6.4

6.4.2 Schutzstatus von Dateien Jede Datei (Daten, Programm, Verzeichnis, ...) hat Schutzstatus (protection mode, access control list), gespeichert als Attribut(e) im Dateideskriptor. Zugriffsschutzsystem (protection system) realisiert Abbildung accessOK : Autorisierung  Schutzstatus  Operation  Boolean bs-6.4

Beispiel: Schutzstatus in Unix (vgl. 6.2.2): UID des Eigners GID der Eignergruppe SUID bit SGID bit Ru Wu Xu Rg Wg Xg Ro Wo Xo (Zugriffs–) Rechte (access rights, permissions), (je 1 Bit) Read, Write, eXecute für user, d.h. Eigner, group, d.h. Eignergruppe, others, d.h. alle anderen bs-6.4

Initialisierung bei Dateierzeugung, z.B. mit creat,mkdir: UID = EUID GID = EGID Bits SUID, SGID, Ru, Wu, Xu, Rg, Wg, Xg, Ro, Wo, Xo gemäß den niederwertigen Bits des 2. Arguments mode von creat,mkdir modifiziert durch die aktuelle mode mask mask : wo mask-Bit gesetzt ist wird mode-Bit ignoriert. Die mode mask ist ein Prozessattribut (!), anfangs 022 (oktal), vererbt an Kindprozesse, änderbar durch Systemaufruf umask(mask) und Befehl umask mask bs-6.4

Abfragen des Schutzstatus durch stat, fstat und Befehl ls –l , z.B. -rws--x--x 1 lohr institut 9 Feb 10 15:38 tst s statt x bedeutet „Xu-Recht und SUID-Bit“ Ändern des Schutzstatus durch chmod, chown (6.1.1.2): chmod darf nur der Datei-Eigner oder Super-User ausführen! chown darf nur der Super-User ausführen ! ( Schutz des Schutzstatus !) System V: chown auch wenn EUID=UID – dann wird aber als Seiteneffekt auch SUID/GUID gelöscht! bs-6.4

6.4.3 Überwachung der Dateioperationen durch einen Reference Monitor im Zugriffsschutzsystem, der diese Abbildung umsetzt: accessOK : Autorisierung  Schutzstatus  Operation  Boolean Falls der Zugriff verwehrt wird, Fehlermeldung (z.B. Fehler EACCES in Unix) bs-6.4

Zugriffsrecht im Schutzstatus bezieht sich i.a. – abhängig vom jeweiligen Dateityp! – auf verschiedene Operationen und: eine Operationen kann mehrere Rechte erfordern Hypothetische Beispiele (nicht Unix!): Rechte Dateityp sequentiell indexsequentiell Verzeichnis eXecute exec - - Read read lookup,update lookup,list Write write update,delete unlink Append append enter link,create* Protect chmod chmod chmod * Erzeugen und Eintragen einer Datei. bs-6.4

sequentiell Verzeichnis R read read, link,unlink W write creat,mkdir, Unix: Rechte Dateityp sequentiell Verzeichnis R read read, link,unlink W write creat,mkdir, X exec ( lookup *) In Minix NICHT konsequent realisiert. * BS-intern für Weg-Auflösung, nicht an der Systemschnittstelle. bs-6.4

Kriterium für erlaubten Zugriff mit einer Operation, die das Recht R (und/oder W oder X) erfordert: Ru und EUID = UID oder Rg und EUID  UID und EGID = GID oder Ro und EUID  UID und EGID  GID Bemerkung: Rechte wie z.B. ---R--RW- sind möglich, aber selten sinnvoll bs-6.4