5.7 Zugriffsschutz in Programmiersprachen

Transkript

1 5.7 Zugriffsschutz in Programmiersprachen Schichtung abstrakter Maschinen geschützte Objekte Systemobjekte, Anwendungsobjekte Programmiersprache Systemobjekte, insbesondere Dateien Betriebssystem Adreßräume, Segmente Hardware

2 5.7.1 Sichtbarkeit und Benutzbarkeit von Namen und der durch sie bezeichneten Objekte wird gesteuert durch Kapselung (encapsulation, information hiding), z.b. so: component C oder module, class,... X x... von außen nicht sichtbar visible void y(){...} von außen sichtbar readonly int i; von außen nur lesbar useonly T t; von außen nur dereferenzierbar end C (vgl. mit R/W/X-Rechten!) Beispiel Java: Sichtbarkeitssteuerung sowohl für Elemente von Paketen als auch für Elemente von Klassen

3 Differenzierte Rechtevergabe an spezifische Programmkomponenten z.b. so (vgl. Eiffel): component C X x... visible{a} void y(){...} visible{a,b} void z(){...} readonly{b} useonly T t; end C Beurteilung: Kapselung schützt Code vor Code statisch, ohne dynamische Prüfungen; unterstützt least-privilege-prinzip, dient vor allem dem Selbstschutz, d.h. fördert Programmsicherheit; aber auch Schutz vor Trojanischen Bibliotheken

4 5.7.2 Einkleiden der Schutzmechanismen des Betriebssystems über Bibliothek, Fehlercodes, Ausnahmemeldungen Generelles Problem: Wünschenswert: Homogenisierung heterogener Mechanismen der unterschiedlichen Betriebssysteme möglichst elegante Ausnutzung der Sprachmittel Z.B. Ausnahmen: AccessDeniedException wäre wünschenswert (in Java aber lediglich mit erläuterndem Text) IOException oder FileNotFoundException

5 Bibliothek: stellt ausgewählte Systemaufrufe in geeigneter Einkleidung zur Verfügung! Semantik ist plattformabhängig z.b. Schutzstatus einer in Java mit new FileOutputStream(path) neu erzeugten Datei! Objektorientierung: Konsequente Verwendung von Objekten/Schnittstellen/Vererbung: Verweis auf Kanal-Objekt statt Unix-Kanalnummer bzw. Windows Handle Wahl von InputStream bzw. OutputStream statt RandomAccessFile schließt falschen Zugriff a priori aus

6 Achtung bei Ausführung von interpretiertem Code, z.b. mit java Test: Aus Sicht des Betriebssystems handelt es sich um Daten, d.h. das Recht Nur Ausführen kann nicht vergeben werden, und das Recht Lesen berechtigt zum Lesen und Ausführen (Zur Erinnerung: anders ist die Situation bei einer Datei swap mit Inhalt #!/bin/csh -f mv $1 ~/tmp/temp mv $2 $1 mv ~/tmp/temp $2 z.b. mit Schutzstatus -rwxr-x--x )

7 5.7.3 Capabilities in Programmiersprachen durch Erweiterung von Verweistypen zu Berechtigungstypen, z.b. mit operationsbezogenen Rechten interface T {...op1...op2...op3...} class C implements T {...} T in Vereinbarungen von Variablen und Parametern: (unqualifizierter Typ:) (qualifizierter Typ:) T T<op1,op3> heißt Berechtigungstyp (capability type) mit Basistyp T T ist äquivalent mit T<op1,op2,op3> (alle Operationen)

8 Zuweisung an Variable/Argument/Ergebnis ist genau dann (statisch) typkorrekt, wenn dabei die Rechtemenge nicht erweitert wird T x = new C(...); T<op1,op3> y = x; y.op2(); y = op(x); Fehler Fehler wenn T<op1> op (T<op2> t) {...} Beachte: widening cast ist nicht erlaubt (T)y qualifizierter Typ ad-hoc-interface-typ! Implementierung: Capability = Verweis (ohne Rechte!)

9 Typischer Einsatz nicht nur zum Selbstschutz, sondern auch zum Schutz vor Trojanischen Bibliotheken: interface Bib {void op(t<op1> t);} class BibImpl implements Bib { public void op(t<op1,op2> t) { T x = t;... } } Beurteilung: Erweiterung von 5.8.1

10 Kontrollierte Rechteerweiterung (capability amplification): class FileSystem { public static class File { File() { } public char read(...) {...} public void write(..) {...}... } public static File<read> newdirectory() { return new File(); } public static void enter(string name, File file, File dir){... }... } Rechtfertigung: FileSystem ist Erzeuger von dir

11 5.7.4 Das Schutzsystem von Java schützt vor Trojanischen Klassen, lokal oder (mit Applets) übers Netz geladen, gemäß einer vorgegebenen Schutzstrategie (security policy), zusätzlich zum Schutz durch das Betriebssystem. 3 Sicherheitsstufen: 1 keine zusätzliche Einschränkung 2 differenzierte Rechtevergabe 3 Programm läuft in Sandkasten (sandbox): keine Rechte (außer daß Applet Verbindung zum Herkunftsort aufnehmen darf)

12 Z.B. für Dateizugriff: gewünschter Zugriff Strategie zugreifende Klasse JVM gemäß Strategie und Klasse erlaubter Zugriff BS gemäß Privilegien und Schutzstatus erlaubter Zugriff

13 Zugriffsschutzmodell (abstrakt:) Klassen aus C erhalten Berechtigungen aus P nach Maßgabe von wie folgt: grant: 2 C 2 P (mit Definitionsbereich D) Berechtigungen einer Klasse c = classes D c classes grant(classes) grant definiert die Schutzstrategie

14 (konkret:) Ein Element des Definitionsbereichs D von grant wird bestimmt durch code base = URL-benanntes Verzeichnis und besteht aus von dort erreichbaren Klassen. Eine Berechtigung ist entweder eine Capability (Objekt,Rechte) oder ein nicht objektbezogenes Recht.

15 Formulierung der Schutzstrategie in Strategie-Dateien (policy files).policy : globale (Standard-) Strategie unter java/jre/lib/security/java.policy persönliche Strategie unter ~/.java.policy Effektive Strategie ergibt sich aus beiden (und eventuell weiteren) Strategien Sandkasten, falls keine Strategie-Dateien angegeben Keine Beschränkung für java Prog wohl aber für java Djava.security.manager Prog

16 Typische Strategie-Datei mit spezieller Syntax: grant codebase " { permission java.io.filepermission "/*", "read"; permission java.io.filepermission "/tmp/*", "read,write"; }; grant codebase "file:/home/bwana/buddy/*" { permission java.io.filepermission "/usr/frank/*", "read";} // Standard extensions get all permissions by default: grant codebase "file:${java.home}/lib/ext/*" { permission java.security.allpermission; }; system property // allows anyone to listen on un-privileged ports: grant { permission java.net.socketpermission "localhost:1024-", "listen"; };

17 Verwaltung von Strategie-Dateien mit policytool :

18 Permission-Klassen Abstrakte Klasse mit Unterklassen java.security.permission java.security.allpermission java.io.filepermission... werden intern für konstante Permission-Objekte verwendet, z.b. in new java.io.filepermission("/tmp/123", "read");

19 Auszug aus für java.io.filepermission: The targets for this class can be specified in the following ways, where directory and file names are strings that cannot contain white spaces. file directory (same as directory/) directory/file directory/* (all files in this directory) * (all files in the current directory) directory/- (all files in the file system under this directory) - (all files in the file system under the current directory) "<<ALL FILES>>" (all files in the file system) Note that "<<ALL FILES>>" is a special string denoting all files in the system. On a Unix system, this includes all files under the root directory. On an MS-DOS system, this includes all files on all drives. The actions are: read, write, delete, and execute. Therefore, the following are valid code samples for creating file permissions:

20 import java.io.filepermission; FilePermission p = new FilePermission("myfile", "read,write"); FilePermission p = new FilePermission("/home/gong/", "read"); FilePermission p = new FilePermission("/tmp/mytmp", "read,delete"); FilePermission p = new FilePermission("/bin/*", "execute"); FilePermission p = new FilePermission("*", "read"); FilePermission p = new FilePermission("/-", "read,execute"); FilePermission p = new FilePermission("-", "read,execute"); FilePermission p = new FilePermission("<<ALL FILES>>", "read");