Betriebssysteme:Aufgaben S
AyAYoR <a href="http://cmigevvvttgk.com/">cmigevvvttgk</a>, [url=http://cdhwjjczhcbz.com/]cdhwjjczhcbz[/url], [link=http://qwbexbapyfpt.com/]qwbexbapyfpt[/link], http://usjxfenylebr.com/
Inhaltsverzeichnis
S2
In einem Unix-System soll für die Person P, die zu einer Gruppe G gehört, ein Terminkalender implementiert werden. Die Datenbasis des Kalenders liege als ASCII-Text in einer Unix-Datei kaldb. Für alle Gruppenmitglieder und nur für diese soll das Lesen der Datenbasis (z.B. mit einem beliebigen Editor) möglich sein, das Vornehmen von Einträgen dagegen nur unter Nutzung eines P gehörenden Unix-Programms kaleintr. Geben Sie die Schutzattribute von kaldb und kaleintr an (in symbolischer Form)!
rwx r-x --- (Owner P) (Gruppe G) /kaleintr rwx r-- --- (Owner P) (Gruppe G) /kaldb
bei uns in der Übung wurde das so gemacht:
kaldb: (P, G, rwx) , (*, G, r--) , (*, *, ---) kaleint: (P, G, rwx) , (*, G, r-x), (*, *, ---)
Das ist ACL, es steht aber explizit UNIX da!
S3
ED: user: rw-, group: r--, others: ---
P: user: r-x, group: r-x, others: ---
Die Spieler A, B und C können P ausführen, welches mit der UID von M auf ED schreibend zugreifen darf.
--Qimokore 13:37, 19. Feb 2007 (CET)
rwx r-x --- (Owner M) (Gruppe SC) /P rw- r-- --- (Owner M) (Gruppe SC) /ED
ich hätte es so gemacht, ist fast identisch, aber bei dir P ja keine Schreibrechte für Programm P. Ist aber nicht so wild glaube ich
wir benutzten ein S, um dem Prog Userrechte vom Besitzer zu geben
rws r-x --- (Owner M) (Gruppe SC) /P rw- r-- --- (Owner M) (Gruppe SC) /ED
S4
Erläutern Sie für jedes der nachfolgend angegebenen Schutzprobleme, inwieweit die Mechanismen Capabilities – Zugriffskontrollisten – Schutzbits rwx in UNIX geeignet sind − Anton möchte, daß seine Dateien für jeden Benutzer außer Berta lesbar sind. − Cäsar und Dora möchten einige geheime Daten gemeinsam benutzen. − Emil möchte einige seiner Daten öffentlich zugänglich machen.
1. Anton möchte, daß seine Dateien für jeden Benutzer außer Berta lesbar sind.
- mit ACL nur schwer machbar
- besser: mit Capabilities (aber in Unix - keine Capabilities sondern rudimentäre ACLs)
Zum Beispiel:
Schema: (User):(Datei,Rechte),(Datei,Rechte),... (*):(Datei1,r--),(Datei2,r--),... (Berta):(Datei1,---),(Datei2,---),...
bzw. allgemeiner:
(*):(*,r--) (Berta):(*,---)
Die Reihenfolge muss doch andersrum sein sonst kann Berta auch lesen!
/* oder einfach ne neue gruppe "notBerta" anlegen, in die alle user außer berta kommen, dieser gruppe die leserechte geben, allen anderen nicht, dann is das auch mit unix easy"
2. Cäsar (C) und Dora (D) möchten einige geheime Daten gemeinsam benutzen.
- per ACL ganz gut machbar
- man könnte sich, also denen eine eigene Gruppe anlegen -> G
- die "einigen Dateien" bekommen dann folgende Attribute:
rwx rwx --- (Owner D) (Gruppe G) /Datei1 rwx rwx --- (Owner C) (Gruppe G) /Datei2 rwx rwx --- (Owner C oder D) (Gruppe G) /Datei*
- per Capabilities
C gibt sein Zeug für D frei und NUR für D (*):(Datei1,---),(Datei2,---),... //niemand darf etwas (D):(Datei1,rwx),(Datei2,rwx),... // außer D
D gibt sein Zeug für C frei und NUR für C
(*):(Datei1,---),(Datei2,---),... //niemand darf etwas (C):(Datei1,rwx),(Datei2,rwx),... // außer C
3. Emil möchte einige seiner Daten öffentlich zugänglich machen.
- per ACL
rwx --- rw- (Owner E) (Gruppe ?) /Datei1 // Nicht näher angegeben ob rw oder nur r halt nur "zugänglich" rwx --- r-- (Owner E) (Gruppe ?) /Datei2
- per Capabilities
(*):(Datei1,rw-),(Datei2,rw-),... //
//Anmerkung: es gibt in Capabilities keine WildCards! Das ist eine Schwäche von Capabilities, dort müssen die User explizit angegeben werden, Lösungen also nur bedingt richtig!
S5
Erläutern Sie die Notwendigkeit, in verteilten Systemen Verschlüsselungsverfahren anzuwenden! Gehen Sie auf Unterschiede von secret-key Verfahren und public-key Verfahren ein!
Verschlüsselungsverfahren sind notwendig, um Bedrohungen entgegenzuwirken, also speziell um folgende Forderungen verteilter Systeme zu erfüllen:
- Konzelation als Grundlage der Vertraulichkeit - Authentifikation als Grundlage der Integrität (Absender, Inhalt)
public-key Verfahren (asymmetrisches Verschlüsselungsverfahren):
- nur Schlüssel Kpriv muss geheimgehalten werden (private key) - Kpriv != Kpub -> unterschiedliche Schlüssel für Ver- und Entschlüsselung
single-key Verfahren bzw. secret-key Verfahren (symmetrisches Verschlüsselungsverfahren):
- nur Besitzer von Schlüssel k kann Klartext ermitteln - der selbe Schlüssel zum Ver- und Entschlüsseln
S6
S7
S8
Public von Kunz.
S9
siehe "Lösungen zu ausgewählten Aufgaben des Gebiets Betriebssysteme" (kl-Loe.pdf)
S10
$ P_A $: {D1,r-x},{D2,r-x} $ P_B $: {D1,--x},{D2,rwx} $ P_C $: {D1,rwx},{D2,r-x} $ P_D $: {D1,--x},{D2,rwx}
ACL: Zuordnung Objekt -> Rechte der Subjekte
Capability: Zuordnung Subjekt -> Rechte an Objekten
S11
Erklären Sie die Begriffe „ACL“ und „capability“! Welchem Zweck dienen diese Begriffe? Erläutern Sie zwei Gesichtspunkte, in denen sie sich unterscheiden!
Siehe Aufgabe S1
S12
Möglicher Angriff: Ein Angreifer gibt sich für A aus und sendet eine zufällige Bitkette Z an B, der diese mit S XOR-verknüpft und zurückschickt (Z XOR S). Nun muss der Angreifer die Nachricht nur noch mit Z XOR-verknüpfen, um an S zu gelangen ((Z XOR S) XOR Z = S).
Weiterhin ist es auch möglich, dass der Angreifer beide Bitketten abfängt, diese XOR-verknüpft und somit den geheimen Schlüssel hat, ohne jemals mit einem der Opfer in direktem Kontakt gestanden zu haben.
Somit ist es für die Zielpersonen des Angriffs nicht nachvollziehbar, dass ein Angreifer den Schlüssel hat.
Hingegen ist die erste Angriffsmöglichkeit sehr leicht als solche erkennbar, nämlich spätestens wenn A mit B über die nicht wirklich zwischen den beiden stattgefundene Verifikation redet.
Weiß man also, dass zwei Personen die o.g. Methode verwenden, empfiehlt sich Angriffsmethode 2 (also eine Man-in-the-Middle Attacke), um von dem erhaltenen Key möglichst lange etwas zu haben.
3. Möglichkeit: Man sendet an B eine Null-Bitkette, ist der Antwortvorgang automatisiert sendet B seinen Schlüssel S = 0 XOR S.
S13
Angenommen, die Ergebnisse (Noten) dieser Klausur sind beim verantwortlichen Hochschullehrer
Prof in zwei Dateien infnot, mednot abgelegt, die den beteiligten Studiengängen INF
und MED entsprechen. Der Hochschullehrer möchte folgendes ermöglichen:
– ein Student kann genau die Notenliste seines Studienganges einsehen, aber nicht verändern;
– er selbst kann alle Listen sowohl lesen als auch bearbeiten;
– das gleiche ist auch den Mitarbeitern des Prüfungsamts Prüfamt gestattet;
– weitere Zugriffe sollen nicht möglich sein.
Außerdem möchte er die Einsichtmöglichkeit für die Studenten zu einem bestimmten, nicht
von vornherein bekannten Termin beenden.
Erläutern Sie (möglichst durch Angabe der entsprechenden Zuordnungen), wie die drei Mechanismen
ACL (Zugriffssteuerlisten) – Capabilities – Rechteschema von Unix
zur Lösung dieses Schutzproblems eingesetzt werden können bzw. welche Probleme dabei
auftreten!
per ACL bzw. UNIX
- man bräuchte z.B. in UNIX 2 Gruppen: Gruppe: MedInf, Gruppe: Inf (Mitglieder dementsprechend)
rwx r-- --- (Owner Prof) (Gruppe Inf) /mednot rwx r-- --- (Owner Prof) (Gruppe MedInf) /infnot
- Problem: wie mit dem PA verfahren?
- Lösung: PA könnte über ein spezielles Programm (/PA) zugreifen:
rws r-x --- (Owner Prof) (Gruppe PA) /PA
..wäre aber ein wenig doof, diese Variante
Einsichtmöglichkeit für die Studenten zu einem bestimmten nicht von vornherein bekannten Termin beenden
- ich sehe da spontan die Mölichkeiten:
- es sind ja nur 2 Dateien -> einfach per Hand das Schreibrecht entfernen
- ein Programm erstellen, welches dies tut
- ggf. einen cronjob, wobei da ja wieder das Problem besteht das der Termin ja vorher nicht bekannt ist
per ACL
/mednot (Prof,Professoren, RWX), (*, PA, RWX),(*, MedInf, R--), (*, *, ---) /infnot (Prof,Professoren, RWX), (*, PA, RWX),(*, Inf, R--) , (*, *, ---)
- der Sachverhalt mit dem Zeitpunkt ist rein in ACL´s meiner Meinung nach nicht umsetzbar, da ACLs ja keine Zeitkoordinate oder dergleichen haben
aber Rechteentzug ist doch möglich, der Prof entzieht einfach beiden Objekten (wann immer er es möchte) die Leserechte für Inf bzw. MedInf!
per Capabilities
- schwer machbar, bzw man muss statt User Gruppen angeben können
(User):(Datei,Rechte),(Datei,Rechte),... (Group):(Datei,Rechte),(Datei,Rechte),...
- dann wäre es so möglich
(Prof):(mednot,rw),(infnot,rw) (MedInf):(mednot,r) (Inf):(infnot,r) (PA):(mednot,rw),(infnot,rw)
Nachteil: Einsicht ist nur schwer zu beenden, da ein Rechtentzug nicht so ohne weiteres möglich ist
- Wieso? Was ist wenn nun für (MedInf) bzw. (Inf) keine Datei mednot bzw. infnot angegeben wird? Dann häte diese Gruppe keine Leserechte und das Problem ist gelöst. Oder?
- Weil Capabilities am Objekt (Nutzer, Prozeß) gespeichert werden. Ist also einmal eine Capability rausgegeben, die einem Nutzer ein Recht einräumt, dann behält er dieses Recht solange er die Capability hält. Umgehen dkönnte man das, indem man nur zeitlich befristet Capabilities ausstellt und die Nutzer sich dann ggf. eine neue holen müssen, sobald die ausläuft. Alternativ eine zusätzliche Indirektion über den Kern oder Krypto.
S14
a
DA: (A,rw), (B,r), (C,r), (T,rw), (*,-)
DB: (B,rw), (A,r), (C,r), (T,rw), (*,-)
DC: (C,rw), (A,r), (B,r), (T,rw), (*,-)
laut allg. Form (aus der Übung Sicherheit.1) einer ACL müßte auch gehen:
DA: (A,T:rw)(B,C:r)(*,-)
DB: (B,T:rw)(A,C:r)(*,-)
DC: (C,T:rw)(B,C:r)(*,-)
b
A: (DA,rw), (DB,r), (DC,r)
B: (DB,rw), (DA,r), (DC,r)
C: (DC,rw), (DA,r), (DB,r)
T: (DA,rw), (DB,rw), (DC,rw)
Beim Hinzukommen/Weggehen eines Studenten müssen 2n Capabilities gesetzt/entfernt werden.
Rechteentzug (wenn jemand die Gruppe verläßt) schwierig
c
Wenn außerhalb stehende Personen keinen Zugriff haben dürfen, dann kann nur ein Nutzer (der Owner der Datei) andere Zugriffsrechte haben als eine Gruppe von anderen Nutzern. Hier brauchen aber sowohl X als auch T jeweils rw-Rechte und alle Y$ \neq $X haben nur r-Rechte.
