Handbuch de

Installations- und

Konfigurationshandbuch

GeNUA mbH, Kirchheim

0.9.5

Urheberrecht ©2007–2011 GeNUA Gesellschaft für Netzwerk- und Unix–AdministrationmbH. Alle Rechte vorbehalten.

• Einführung

• Installation

• GUI Überblick

• Konfiguration

• Betrieb

• Logging

• Fehlerbehandlung

• Anhang

• Glossar

Inhaltsverzeichnis

1 Einführung 3

1.1 Anoubis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.2 Was ist Anoubis? . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Über dieses Handbuch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1 Terminologien und Abkürzungen . . . . . . . . . . . . . . . . . . . 4

1.2.2 Die Gliederung des Handbuchs . . . . . . . . . . . . . . . . . . . 5

2 Installation 9

2.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Empfohlene Systemkonfiguration . . . . . . . . . . . . . . . . . . 9

2.2 Debian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Deinstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Fedora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.1 Deinstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 OpenSuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.1 Deinstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5.1 Deinstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.6 Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.6.1 Deinstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 GUI Überblick 21

3.1 Statusanzeige . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Navigationsleiste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Hauptfenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4 Infoleiste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5 Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.6 Trayicon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.6.1 Benachrichtigung über offene Nachfragen . . . . . . . . . . . . . 23

3.6.2 Benachrichtigung über Alarme . . . . . . . . . . . . . . . . . . . . 23

3.6.3 Normalzustand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

vi INHALTSVERZEICHNIS

3.7 Benachrichtigungen und Anfragen . . . . . . . . . . . . . . . . . . . . . . 24

3.7.1 Benachrichtigungen . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.8 Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.8.1 Einstellungen zur Esklationsbenachrichtigung . . . . . . . . . . . 25

3.8.2 Einstellungen zur Alarmbenachrichtigung . . . . . . . . . . . . . . 25

3.8.3 Autostart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.8.4 RuleEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.8.5 Verbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.8.6 Tool Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.9 Upgrade Dialogbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Konfiguration 31

4.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.1 anoubisctl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.2 sfssig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.3 Playground . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Kontexte und Kontextwechsel . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.2 Aufbau von Kontext-Regeln . . . . . . . . . . . . . . . . . . . . . . 39

4.2.3 Spezielle Kontextwechsel . . . . . . . . . . . . . . . . . . . . . . . 40

4.3 ALF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4 SFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4.1 Behandlung von symbolischen Links . . . . . . . . . . . . . . . . 45

4.4.2 SFS-Ausnahmen für einzelne Anwendungen . . . . . . . . . . . . 45

4.5 Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.6 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.7 Schlüssel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.8 Regelwizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.9 anoubisd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.9.1 Unixsocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.9.2 Upgradeoptionen . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.9.3 Authentisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.9.4 Inhaltsscanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.9.5 Sonstige Optionen . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.10 Spezielle Hinweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.10.1 .xanoubis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.10.2 nscd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.10.3 System-V IPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Anoubis by GeNUA mbH, Kirchheim. All rights reserved / Alle Rechte vorbehalten.

INHALTSVERZEICHNIS vii

5 Betrieb 59

5.1 Anzeigen und Beantworten von Eskalationen . . . . . . . . . . . . . . . . 59

5.1.1 Benachrichtigung über offene Eskalationen . . . . . . . . . . . . . 59

5.1.2 Anzeigen und Entscheiden von Eskalationen . . . . . . . . . . . . 59

5.2 Regelwizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2.1 Regelkonfiguration einer Anwendung mit dem Regelwizard . . . . 60

5.3 LogViewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.4 RuleEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.4.1 Bearbeiten von Regeln . . . . . . . . . . . . . . . . . . . . . . . . 72

5.4.2 Administratorregeln . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.4.3 Speichern und Aktivieren . . . . . . . . . . . . . . . . . . . . . . . 74

5.5 Applikationsregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.5.1 Regeleditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.5.2 Der Prozessbrowser . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.6 ALF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.6.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.6.2 RuleEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.7 SFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.7.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.7.2 RuleEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.7.3 Einführung in den SFS-Browser . . . . . . . . . . . . . . . . . . . 80

5.7.4 Schlüssel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.7.5 Prüfsumme validieren . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.7.6 Prüfsumme anzeigen . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.7.7 Prüfsumme hinzufügen . . . . . . . . . . . . . . . . . . . . . . . . 83

5.7.8 Prüfsumme entfernen . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.7.9 Erweiterte Operationen . . . . . . . . . . . . . . . . . . . . . . . . 84

5.8 Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.8.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.8.2 RuleEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.9 Playground . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.9.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.9.2 Manuelles Starten von Applikationen im Playground . . . . . . . . 86

5.9.3 Regelbasiertes Starten von Applikationen im Playground . . . . . 88

5.9.4 Arbeiten in Playgrounds . . . . . . . . . . . . . . . . . . . . . . . . 90

5.9.5 Auflisten von Playgrounds . . . . . . . . . . . . . . . . . . . . . . 91

5.9.6 Übernehmen von Dateien aus einem Playground . . . . . . . . . 93

5.9.7 Löschen von Dateien aus einem Playground . . . . . . . . . . . . 94

5.10 Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.10.1 Einführung in den Profil Editor . . . . . . . . . . . . . . . . . . . . 94


viii INHALTSVERZEICHNIS

5.10.2 Laden eines Profils . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.10.3 Erzeugen und Aktualisieren eines Profils . . . . . . . . . . . . . . 95

5.10.4 Löschen eines Profils . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.11 Versionskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.11.1 Version wiederherstellen . . . . . . . . . . . . . . . . . . . . . . . 96

5.11.2 Version exportieren . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.11.3 Version löschen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.12 Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.12.1 Benutzer-Signaturen . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.12.2 Administrator-Signaturen . . . . . . . . . . . . . . . . . . . . . . . 98

5.13 Authorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

6 Logging 101

6.1 Übersicht über die Ereignisarten . . . . . . . . . . . . . . . . . . . . . . . 101

6.2 Logviewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

6.2.1 Öffnen des Logviewers . . . . . . . . . . . . . . . . . . . . . . . . 102

6.2.2 Ergebnis eines Ereignisses . . . . . . . . . . . . . . . . . . . . . . 102

6.2.3 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.2.4 Speicherung von Log-Meldungen . . . . . . . . . . . . . . . . . . 103

6.3 ALF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.3.1 Typen von ALF-Meldungen . . . . . . . . . . . . . . . . . . . . . . 103

6.3.2 Detailinformationen in ALF-Meldungen . . . . . . . . . . . . . . . 104

6.4 Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.5 SFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.6 Playground . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

7 Fehlerbehandlung 109

7.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

7.1.1 Beim Klick auf eine Eskalationsmeldung bekommt die Anwendungkeinen Fokus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

7.1.2 Bei aktiviertem Autostart von xanoubis werden mehrere Instanzenerzeugt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

7.1.3 Bei Aktivieren einer Policy wird ein Fehler gemeldet . . . . . . . . 111

7.1.4 Nach Hinterlegen des Zertifikates wird Policy nicht geladen . . . . 111

7.1.5 Beim Editieren von Sandbox-/SFS-Regeln kann ich keinen Pfadauswählen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.1.6 Auswahldialog für Datei oder Verzeichnis zeigt keine verstecktenObjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7.1.7 Neu einlesen der Konfiguration funktioniert nicht . . . . . . . . . . 112

7.1.8 Xanoubis meldet, dass ein neuer Kernel installiert wurde . . . . . 112

7.1.9 Xanoubis meldet: Falsche APN-Version . . . . . . . . . . . . . . . 112


INHALTSVERZEICHNIS ix

7.1.10 Xanoubis meldet: Falsche Anoubis-Protokoll-Version . . . . . . . 112

7.1.11 Xanoubis meldet: Falsche .xanoubis-Version . . . . . . . . . . . . 112

7.1.12 Xanoubis meldet: Fehlender Schlüssel . . . . . . . . . . . . . . . 113

7.1.13 Xanoubis meldet: Falsches Zertifikat . . . . . . . . . . . . . . . . . 113

7.1.14 Der Anoubis-Kern bootet nicht in einer VirtualBox . . . . . . . . . 113

7.1.15 Aus einer Eskalation kann keine Regel erzeugt werden . . . . . . 113

7.2 ALF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

7.2.1 Nach einiger Zeit ist keine Netzwerkverbindung mehr möglich . . 114

7.2.2 Das automatische Update funktioniert nicht mehr . . . . . . . . . 114

7.3 Sandbox und SFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

7.3.1 Zugriff auf eine Datei wird verweigert . . . . . . . . . . . . . . . . 114

7.3.2 Nach einer Regeländerung hängt das System . . . . . . . . . . . 114

7.3.3 Es kann kein neuer SFS-Block erstellt werden . . . . . . . . . . . 115

7.3.4 Im Schlüssel-Tab wird eine Warnung angezeigt . . . . . . . . . . 116

7.3.5 Beim Erstellen einer Prüfsumme wird ein Fehler gemeldet . . . . 116

7.3.6 Im Sandbox-Modul wird eine Regel angezeigt, diese wirkt aber nicht116

7.3.7 Nach dem Hinzufügen vieler Prüfsummen treten Fehler auf . . . . 116

7.4 Playground . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

7.4.1 Firefox startet, aber nicht im Playground . . . . . . . . . . . . . . . 117

7.4.2 Eine Applikation startet, aber nicht im Playground . . . . . . . . . 117

7.4.3 Playground kann nicht gelöscht werden . . . . . . . . . . . . . . . 117

8 Fremdsoftware 121

8.1 Virenscanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

8.1.1 Avira Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

8.1.2 ClamAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

8.1.3 Sophos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

8.2 Festplattenverschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . . 124

8.2.1 TrueCrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

8.2.2 eCryptfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

8.3 X-Server (Xorg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

8.3.1 Deaktivieren von Xtest . . . . . . . . . . . . . . . . . . . . . . . . 126

A Abstract Policy Notation 127

A.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

A.1.1 Administrator- und Benutzerregeln . . . . . . . . . . . . . . . . . . 127

A.1.2 Vererbung von Regeln (Kontext-Modul) . . . . . . . . . . . . . . . 127

A.1.3 Standardvorgaben für Ereignisse . . . . . . . . . . . . . . . . . . 128

A.2 Allgemeine Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

A.2.1 Allgemeine Grammatik . . . . . . . . . . . . . . . . . . . . . . . . 129

A.2.2 Identifikation von Applikationen . . . . . . . . . . . . . . . . . . . . 129


x INHALTSVERZEICHNIS

A.2.3 Regel-Identifikation . . . . . . . . . . . . . . . . . . . . . . . . . . 130

A.2.4 Scope – Regeln mit eingeschränkter Gültigkeit . . . . . . . . . . . 130

A.2.5 Kommentare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

A.2.6 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

A.3 Vererbung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

A.4 Application Level Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

A.4.1 Filterregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

A.4.2 Capability-Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

A.4.3 Default-Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

A.5 Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

A.6 SFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

B Architektur und Pfade 137

B.1 Kernelkomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

B.2 Der Anoubis-Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

B.2.1 Pfade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

B.3 Anoubis Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

C SFS Import/Export 141

D Interface für Inhaltsscanner 143

E Glossar 147


EINFÜHRUNG

• Anoubis

• Über dieses Handbuch

Kapitel 1

Einführung

1.1 Anoubis

1.1.1 Einleitung

Anoubis - die Security-Suitefür Enterprise-Umgebungen Webhoster und mobile Rechner:

• Kontrolliert anwendungsbezogen Netzwerk- und Dateizugriffe

• Schützt vor persistenten Manipulationen Ihrer Anwendungen und Dokumente

• Stellt die Integrität Ihrer Dokumente sicher

• Verfügbar für OpenBSD und GNU/Linux-Distributionen

1.1.2 Was ist Anoubis?

Anoubis ist eine benutzerfreundliche Security Suite, die eine stark abgesicherte Ablau-fumgebung für Softwareprogramme implementiert. Zielsetzung von Anoubis ist es, eineerstmalig alle Aspekte des Sicherheitsmanagements von Rechnersystemen umfassendeLösung zu schaffen, die sowohl die Betriebssysteme der Linux- als auch der BSD-Familieunterstützt.

Das Kernstück der Security Suite bilden zum Einen eine Application Level Firewall1 undeine Sandbox, mit deren Hilfe Prozesse in einer abgeschotteten Umgebung ausgeführtwerden können, die nur die notwendigen Zugriffe auf vorhandende Dateien und Netz-werkresourcen erlaubt. Zum Anderen bieten Playgrounds die Möglichkeit, Programme soauszuführen, dass diese keinerlei Änderungen an Dateien im Produktivsystem direkt vor-nehmen können. Die Programme werden dadurch weder in ihrer Funktion beeinträchtigtnoch müssen die Programme angepaßt oder verändert werden.

Zusammen kann damit sowohl der ungewollte Abfluß von Informationen aus dem Systemals auch das ungewollte Eindringen von Daten in das System verhindert werden.

Darüber hinaus werden Mechanismen zur Sicherstellung der Authentizität von Dateienund Verzeichnissen sowie von Applikationen bereitgestellt. Hierbei werden diese mittelszeitgemäßer Prüfsummen versehen, die darüber hinaus noch signiert werden können.

1kursiv notierte Begriffe können dem Glossar in Anhang E entnommen werden

4 1. Einführung

Die Maßnahmen zur Verbesserung der Sicherheit der Laufzeitumgebung sind sowohl fürden Desktop- als auch für den Serverbetrieb gedacht.

Anoubis besteht aus den folgenden vier Modulen, die unterschiedliche Aspekte einer ab-gesicherten Umgebung realisieren:

Application Level Firewall (ALF) Die Application Level Firewall oder kurz ALF kontrol-liert die Netzwerkzugriffe einzelner Applikationen. Dabei kann für jede Applikationindividuell festgelegt werden, welche Netzwerkdienste diese nutzen darf.

Sandbox (SB) Die Sandbox oder kurz SB kontrolliert die Dateisystemzugriffe einzelnerApplikationen. Dabei kann wieder für jede Applikation individuell festgelegt werden,welche Zugriffe zulässig sind.

Sicheres Filesyste (SFS) Das sichere Filesystem oder kurz SFS sorgt für die Verwaltungvon Prüfsummen für Dateien im System. Jeder Benutzer kann individuell Prüfsum-men verwalten. Änderungen an Dateien können dadurch festgestellt werden. Darüberhinaus können die Prüfsummen aber auch direkt beim Zugriff auf Dateien geprüft wer-den. So kann der Zugriff auf eine Datei vollständig verhindert werden, wenn Ihr Inhaltnicht mehr mit der registrierten Prüfsumme übereinstimmt.

Playground (PG) Der Playground bietet die Möglichkeit, Programme so zu starten, dasssie keine Änderungen an existierenden Dateien vornehmen können. Versucht einProgramm dennoch Änderungen zu machen, dann wird die Datei kopiert und dieÄnderungen werden nur auf der Kopie vorgenommen. Das Playground Modul sorgtdafür, dass dies durch das Programm selbst nicht bemerkt wird. Es sind auch keinerleiÄnderungen am Programm selbst notwendig.

Bevor auf Dateien, die in einem Playground verändert wurden, von anderen Program-men außerhalb des Playgrounds zugegriffen werden können, müssen Sie durch denBenutzer ins System übernommen werden. Dabei kann vor der Übernahme der Da-teiinhalt durch Inhaltsscanner (z.B. einen Virenscanner) überprüft werden.

So wird zuverlässig verhindert, dass Daten durch die in einem Playground laufendeAnwendung unkontrolliert ins eigentliche System gelangen können.

1.2 Über dieses Handbuch

1.2.1 Terminologien und Abkürzungen

Im vorliegenden Handbuch werden u.a. die nachfolgenden Abkürzungen verwendet:

ALF für Application Level Firewall

SFS für Sicheres Filesystem

SB für Sandbox

PG für Playground


1.2. Über dieses Handbuch 5

Textdarstellungen

Konvention BedeutungText Text für Aus- oder Eingaben, Dateinamen�� Enter Einzelne Taste auf der TastaturObjekt Name eines Objektes im GUI (z.B. Menü) oder eines ProgrammsBegriff Kennzeichnet einen Begriff des Glossars

Darüber hinaus finden zahlreiche Abkürzungen aus dem Netzwerk- und Security-BereichVerwendung, die zumeist im Glossar in Anhang E nachgeschlagen werden können.

1.2.2 Die Gliederung des Handbuchs

Das vorliegende Handbuch untergliedert sich in die folgenden Abschnitte:

Einführung Neben der hier vorliegenden Einleitung finden Sie hier darüber hinaus allge-meine Informationen zu Anoubis.

Installation Im Kapitel Installation werden die notwendigen Schritte zur Installation vonAnoubis dargelegt.

GUI Überblick Das Kapitel GUI Überblick gewährt einen Überblick hinsichtlich der we-sentlichen Bestandteile der Graphischen Oberfläche von Anoubis.

Konfiguration Nach erfolgter Installation beschreibt dieses Kapitel alle Schritte zur Kon-figuration von Anoubis. Hierbei werden zu Beginn allgemein gültige und modulüber-greifende Konfigurationsmöglichkeiten der Security Suite Anoubis dargelegt. Daranschließt sich eine detaillierte Vorstellung der einzelnen Sicherheitsmodule und de-ren spezifischen Einstellungsmöglichkeiten an. Die umfassenden Möglichkeiten zurKonfiguration mittels GUI werden hierbei in einem eigenen Kapitel aufgezeigt.

Betrieb Dieses Kapitel stellt typische Konfigurationsszenarien von Anoubis vor und rich-tet sich hauptsächlich an fortgeschrittene Anwender.

Logging Dieses Kapitel bietet ein Übersicht über die Ereignisarten, eine Beschreibungdes LogViewer und Loggingfunktionen von ALF, SB und SFS.

Fehlerbehandlung Anhand von ausgewählten Szenarien beschreibt dieses Kapitel dienotwendigen Schritte zur Lösung von Problemen.

Abstract Policy Notation In Anhang A wird eine Übersicht zur von den einzelnen Kom-ponenten verwendeten Metasprache gegeben.

Architektur und Pfade Hier wird eine grobe Übersicht über den Aufbau von Anoubisgegeben, sowie über wichtige Dateien die zu Anoubis gehören.

SFS Import/Export Das beim Import und Export von Prüfsummen und Signaturen ver-wendete Dateiformat, wird in Anhang C ausführlicher beschrieben.

Interface für Inhaltsscanner In Anhang D wird die Schnittstelle zu Inhaltsscannern fürden Playground spezifiziert.

Glossar Ein Großteil der im Handbuch verwendeten Begrifflichkeiten kann im Glossar inAnhang E nachgeschlagen werden.


6 1. Einführung


INSTALLATION

• Allgemein

• Debian

• Fedora

• OpenSuse

• OpenBSD

• Ubuntu

Kapitel 2

Installation

2.1 Allgemein

Die Anoubis-Security-Suite besteht aus drei Paketen:

• dem Kernel (Name plattform- bzw. distributionsabhängig)

• dem Daemon (anoubisd unter Linux bzw. anoubis-daemon unter OpenBSD)

• der graphischen Benutzeroberfläche xanoubis (anoubis-gui unter OpenBSD)

Um die Sicherheitsfunktionen von Anoubis nutzen zu können, müssen alle drei Kompo-nenten installiert sein und der Anoubis-Kernel muss gebootet sein. Auch wenn Anoubisinstalliert ist, ist es auch weiterhin möglich, einen Kernel ohne Anoubis-Funktionalität zubooten.

2.1.1 Empfohlene Systemkonfiguration

Partition für SFS Prüfsummen

Anoubis verwaltet den Prüfsummenbestand unterhalb des Verzeichnisses/var/lib/anoubis/sfs/. Dort werden unter Umständen sehr viele, in der Re-gel aber sehr kleine Dateien erzeugt. Wir empfehlen daher, für das Verzeichnis/var/lib/anoubis/sfs/ eine separate Partition zu verwenden. Diese sollte für dasSpeichern von sehr vielen kleinen Dateien optimiert sein. Hier bietet sich zum Beispieleine XFS-Partition an, die wie folgt erzeugt wurde:

mkfs.xfs -b size=512 -i maxpct=80 /device/of/partition

Wenn keine geeignete Partition zur Verfügung steht, kann auch eine Datei verwendet undmit Hilfe von loopback-Mounts als Partition gemountet werden.

Playground Spool Verzeichnis

Wenn Sie vorhaben, Inhaltsscanner zusammen mit dem Playground einzusetzen, dannmuss diesen ein Spool-Verzeichnis zur Verfügung stehen. Als Spool-Verzeichnis wird das

10 2. Installation

Heimatverzeichnis des Benutzers _anoubisscan verwendet. Dort sollte genügen freierPlatz zum Zwischenspeichern von Dateien vorhanden sein. Normalerweise liegt diesesunter /var/spool/anoubis.

Achtung: Das verwendete Spool-Verzeichnis darf nur für den Benutzer _anoubisd les-bar sein.

2.2 Debian

Die Anweisungen in diesem Abschnitt beziehen sich auf Debian 5.0 “Lenny”. Um das In-stallieren der Debian-Pakete - vom lokalen Dateisystem aus - mittels dpkg durchzuführen,kopieren Sie bitte die drei Pakete (kernel, anoubis und xanoubis) auf Ihr System. Wech-seln Sie nun in das Verzeichnis, das die zuvor heruntergeladenen Pakete enthält. DieInstallation der Anoubis-Pakete kann danach wie folgt durchgeführt werden

dpkg -i linux-image-2.6.26-anoubis-0.9.2.d023.972.d076_1_i386.deb

dpkg -i anoubisd_0.9.2.D023.972.D076_i386.deb

dpkg -i xanoubis_0.9.2.D023.972.D076_i386.deb

Dabei wird durch den Aufruf in der ersten Zeile das Kernel-Paket installiert. Wenndie default Bootloader-Konfiguration verwendet wird, wird ab dem nächsten Reboot dieAnoubis-Security-Suite aktiviert. Ansonsten muss der neue Kernel noch in →Grub oder→Lilo konfiguriert werden.

Um die Installation, der von den Anoubis-Paketen benötigten Abhängigkeiten zu ermögli-chen, geben Sie abschließend den folgenden Befehl ein.

apt-get -f install

Bei Bedarf kann der Zugriff auf das Device /dev/eventdev zusätzlich weiter einge-schränkt werden:

chmod 600 /dev/eventdev

2.2.1 Deinstallation

Starten Sie das System neu und booten Sie den jeweiligen Standard-Kernel, der von ihrerDistribution bereitgestellt wird. Um sowohl das Kernel-Paket als auch die Anoubis-Pakete(anoubisd und xanoubis) sowie die zugehörigen Konfigurationsdateien zu deinstallie-ren, gehen Sie - nach dem erfolgten Neustart des Systems - wie folgt vor.

Bestimmen Sie die installierten Anoubis-Pakete mittels des folgenden Kommandos.

dpkg --get-selections | grep anoubis | awk '{print $1}'

Eine beispielhafte Ausgabe könnte wie folgt aussehen.

anoubisd

linux-image-2.6.26-anoubis-0.9.2.d023.972.d133

xanoubis


2.3. Fedora 11

Um die aufgelisteten Pakete zu deinstallieren, gehen Sie wie folgt vor.

dpkg --purge xanoubis

dpkg --purge anoubisd

dpkg --purge linux-image-2.6.26-anoubis-0.9.2.d023.972.d133

Beachten Sie bitte, dass die Anweisung zur Deinstallation des Kernel-Pakets den vollstän-digen Namen (inklusive der Versionsnummer) aufweisen muss. Dieser ist entsprechendder Ausgabe des oben genannten Kommandos anzupassen.

Die Komponenten anoubisd und xanoubis greifen auf zusätzliche Dateien und Pfadezurück, die nicht im Rahmen der Deinstallation der Pakete entfernt werden. Um eine voll-ständige Deinstallation aller für Anoubis relevanten Bestandteile durchzuführen, müssendie unter Punkt B.2.1 und B.3 genannten Pfade und Dateien vom System entfernt werden.

Nach der Deinstallation der Anoubis-Pakete ist ein Reboot des Systems ratsam.

2.3 Fedora

Diese Anweisungen beziehen sich auf Fedora Core 11.

Wenn die RPM-Pakete anoubisd und xanoubis sowie das Kernel-Paket ins aktuelleVerzeichnis heruntergeladen wurden, können sie mit dem folgenden Kommando installiertwerden.

yum install *.rpm --nogpgcheck

Hierbei kann es zu Konflikten mit Paketen kommen, die auf dem System installiert undaktueller sind, als die, die installiert werden sollen. Dabei kommt es zur folgenden Fehler-meldung.

$ Transaction Check Error:

package <Paketname> (which is newer than <Paketname>) is already installed

Um das Paket dennoch zu installieren, rufen Sie bitte folgendes Kommando auf:

$ rpm -i --force <Paketname>

Wenn die default Bootloader-Konfiguration verwendet wird, wird ab dem nächsten Rebootdie Anoubis-Security-Suite aktiviert. Ansonsten muss der neue Kernel noch in →Gruboder→Lilo konfiguriert werden.




12 2. Installation


Starten Sie das System neu und booten Sie den jeweiligen Standard-Kernel, der von ihrerDistribution bereitgestellt wird. Um sowohl das Kernel-Paket als auch die Anoubis-Pakete(anoubisd und xanoubis) sowie die zugehörigen Konfigurationsdateien zu deinstallie-ren, gehen Sie - nach dem erfolgten Neustart des Systems - wie folgt vor.Bestimmen Sie die installierten Anoubis-Pakete mittels des folgenden Kommandos.

rpm -qa | grep anoubis


xanoubis-0.9.2.D023.972.D133-2

kernel-2.6.26anoubis0.9.2.d023.972.d133-1

anoubisd-0.9.2.D023.972.D133-2


yum remove xanoubis

yum remove anoubisd

yum remove kernel-2.6.26anoubis0.9.2.d023.972.d105-1

Beachten Sie bitte, dass die Anweisung zur Deinstallation des Kernel-Pakets den vollstän-digen Namen (inklusive der Versionsnummer) aufweisen muss. Dieser ist entsprechendder Ausgabe des oben genannten Kommandos anzupassen.Die Komponenten anoubisd und xanoubis greifen auf zusätzliche Dateien und Pfadezurück, die nicht im Rahmen der Deinstallation der Pakete entfernt werden. Löschen Siedie Dateien und Verzeichnisse, die unter den Punkten B.2.1 und B.3 genannt werden, umeine vollständige Deinstallation durchzuführen.Nach der Deinstallation des Anoubis-Pakete ist ein Reboot des Systems ratsam.

2.4 OpenSuse

Diese Anweisungen beziehen sich auf OpenSuse 11.2.Wenn die RPM-Pakete anoubisd und xanoubis sowie das Kernel-Paket ins aktuelleVerzeichnis heruntergeladen wurden, können sie mit folgenden Kommandos installiertwerden.

zypper install kernel-default-2.6.31.5-0.1.i586.rpm

zypper install anoubisd-0.9.2-1.i586.rpm

zypper install xanoubis-0.9.2-1.i586.rpm

In diesen Kommandos müssen die Versionsnummern der Pakete durch die Versionsnum-mern der heruntergeladenen Pakete ersetzt werden.Wenn die default Bootloader-Konfiguration verwendet wird, wird ab dem nächsten Rebootdie Anoubis-Security-Suite aktiviert. Ansonsten muss der neue Kernel noch in →Gruboder→Lilo konfiguriert werden.Bei Bedarf kann der Zugriff auf das Device /dev/eventdev zusätzlich weiter einge-schränkt werden:



2.5. OpenBSD 13




rpm -qa | grep anoubis


anoubisd-0.9.2.D023.972.D130-2

xanoubis-0.9.2.D023.972.D130-2

kernel-2.6.26anoubis0.9.2.d023.972.d130-1


rpm -e xanoubis

rpm -e anoubisd

rpm -e kernel-2.6.26anoubis0.9.2.d023.972.d130-1

Beachten Sie bitte, dass die Anweisung zur Deinstallation des Kernel-Pakets den vollstän-digen Namen (inklusive der Versionsnummer) aufweisen muss. Dieser ist entsprechendder Ausgabe des oben genannten Kommandos anzupassen.



2.5 OpenBSD

Zur Installation des OpenBSD Release von Anoubis brennen Sie das ISO-Image auf CDund booten von dieser. Alternativ lässt sich die Installation auch mittels einer Virtualisie-rungssoftware wie qemu(1) wie folgt vornehmen:

qemu-img create <Pfad/zum/Dateisystemimage> 4G

qemu -hda <Pfad/zum/Dateisystemimage> -cdrom <Pfad/zum/ISO> -boot d

Im Folgenden wird schrittweise die Installation von Anoubis unter OpenBSD beispielhaftdurchgeführt.

Nach dem Bootvorgang begrüßt Sie der OpenBSD-Installer:

root on rd0a swap on rd0b dump on rd0b

erase ^?, werase ^W, kill ^U, intr ^C, status ^T

Welcome to the OpenBSD/i386 4.6 install program.

(I)nstall, (U)pgrade or (S)hell? I


14 2. Installation

Cool! Let's get to it.

At any promp except password prompts you can escape to a shell by

typing '!'. Default answers are shown in []'s and are selected by

pressing RETURN. You can exit this program at any time by pressing

Control-C. But this can leave your system in an inconsistent state.

Choose your keyboard layout ('?' or 'L' for list) [default] de

kbd: keyboard mapping set to de

Anschließend erfolgt die Konfiguration des Netzwerks.

System hostname? (short form, e.g. 'foo') anoubis

Available network interfaces are: fxp0 x10.

Which one do you wish to configure? (or 'done') [x10] <Enter>

IPv4 address for x10? (or 'dhcp' or 'none') [dhcp] <Enter>

Issuing hostname-associated DHCP request for x10.

DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 2

DHCPOFFER from 192.168.1.257 (00:30:48:8c:50:21)

DHCPREQUEST on x10 to 255.255.255.255 port 67

DHCPACK from 192.1668.1.254 (00:30:48:8c:50:21)

bound to 69.241.244.76 -- renewal in 1800 seconds.

IPv6 address for x10? (or 'rtsol' or 'none') [none] <Enter>

Available network interfaces are: fxp0 x10.

Which one do you wish to configure? (or 'done') [done] <Enter>

Using DNS domainname example.com

Using DNS nameserver at 68.87.77.130 68.87.72.130

Do you want to do any manual network configuration? [no] <Enter>

Im nächsten Schritt wird das Passwort für den Nutzer root festgelegt.

Password for root account? (will not echo) pAssWOrd

Password for root account? (again) pAssWOrd

Start sshd(8) by default? [yes] <Enter>

Start ntpd(8) by default? [no] <Enter>

Do you expect to run the X Window System? [yes] <Enter>

Do you want the X Window System to be started by xdm(1)? [no] <Enter>

Change the default console to com0? [no] <Enter>

Setup a user? (enter a lower-case loginname, or 'no') [no] <Enter>

Since you setup a user, disable sshd(8) logins to root? [yes] <Enter>

Im folgenden Schritt wird die Partitionierung der Festplatte vorgenommen.

Available disks are: wd0

Which one is the root disk? (or 'done') [wd0] <Enter>

Offset: 1312752 Signature: 0xAA55

Starting Ending LBA Info:

#: id C H S - C H S [ start: size ]

-------------------------------------------------------------------------------

*0: 0B 0 1 1 - 195 254 63 [ 63: 3148677 ] WinXP FAT-32

1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused

2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused

3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused





2.5. OpenBSD 15

-------------------------------------------------------------------------------

0: 0B 0 1 1 - 195 254 63 [ 63: 3148677 ] OpenBSD

1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused.....

2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused.....

3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused...




-------------------------------------------------------------------------------

0: 0B 0 1 1 - 195 254 63 [ 63: 3148677 ] Linux

1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused.....

2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused.....

3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused...

Use (W)hole disk, use the (O)penBSD area, or (E)dit the MBR? [OpenBSD] O

The auto-allocated layout for wd0 is:

# size offset fstype [fsize bsize cpg]

a: 984.5M 1012158 4.2BSD 2048 16384 1 # /

b: 256.0M 3028435 swap

c: 76319.1M 0 unused

d: 3072.0M 3552726 4.2BSD 2048 16384 1 # /usr

e: 1413.8M 9844182 4.2BSD 2048 16384 1 # /home

e: 494.2M 63 ext2fs

j: 70096.1M 12739608 unknown

Use (A)uto layout, (E)dit auto layout, or create (C)ustom layout? [a] A

/dev/rwd0a: 984.5MB in 2016280 sectors of 512 bytes

5 cylinder groups of 202.47MB, 12958 blocks, 25984 inodes each

/dev/rwd0e: 1413.8MB in 2895360 sectors of 512 bytes


/dev/rwd0d: 3072.0MB in 6291456 sectors of 512 bytes


/dev/wd0a on /mnt type ffs (rw, asynchronous, local)

/dev/wd0e on /mnt/home type ffs (rw, asynchronous, local, nodev, nosuid)

/dev/wd0d on /mnt/usr type ffs (rw, asynchronous, local, nodev)

Let's install the sets!

Location of sets? (cd disk ftp http or 'done') [cd] <Enter>

Available CD-ROMs are: cd0.

Which one contains the install media? (or 'done') [cd0] <Enter>

Pathname to the sets? (or 'done') [4.6/i386] <Enter>

Select sets by entering a set name, a file name pattern or 'all'. De-select

sets by prepending a '-' to the set name, file name pattern or 'all'. Selected

sets are labeled '[x]'.

[X] bsd [X] etc46.tgz [X] game46.tgz [X] xserv46.tgz

[X] bsd.rd [X] misc46.tgz [X] xbase46.tgz [ ] site46.tgz

[X] bsd.mp [X] comp46.tgz [X] xetc46.tgz

[X] base46.tgz [X] man46.tgz [X] xshare46.tgz

Set name(s)? (or 'abort' or 'done') [done] all

[X] bsd [X] etc46.tgz [X] game46.tgz [X] xserv46.tgz

[X] bsd.rd [X] misc46.tgz [X] xbase46.tgz [X] site46.tgz

[X] bsd.mp [X] comp46.tgz [X] xetc46.tgz

[X] base46.tgz [X] man46.tgz [X] xshare46.tgz

Set name(s)? (or 'abort' or 'done') [done] <Enter>

bsd 100% |***************************************| 6356 KB 00:09 ETA

bsd.rd 100% |***************************************| 5003 KB 00:03 ETA

bsd.mp 100% |***************************************| 6401 KB 00:04 ETA

base46.tgz 100% |***************************************| 42854 KB 00:38 ETA

etc46.tgz 100% |***************************************| 1190 KB 00:01 ETA

misc46.tgz 100% |***************************************| 2252 KB 00:02 ETA

comp46.tgz 100% |***************************************| 77563 KB 01:05 ETA

man46.tgz 100% |***************************************| 7530 KB 00:08 ETA

game46.tgz 100% |***************************************| 2547 KB 00:01 ETA


16 2. Installation

xbase46.tgz 100% |***************************************| 9450 KB 00:08 ETA

xetc46.tgz 100% |***************************************| 76180 KB 00:00 ETA

xshare46.tgz 100% |***************************************| 2678 KB 00:05 ETA

xserv46.tgz 100% |***************************************| 8543 KB 00:07 ETA

site46.tgz 100% |***************************************| 8543 KB 00:32 ETA

Location of sets? (cd disk ftp http or 'done') [done] <Enter>

What timezone are you in? ('?' for list) [Europe/Berlin] <Enter>

Saving configuration files...done.

Generating initial host.random file...done.

Making all device nodes...done.

Mulitprocessor machine; using bsd.mp instead of bsd.

***********************************Installing Anoubis packages

***********************************

==> Installing anoubisd ..

==> Installing xanoubis ..

CONGRATULATIONS! Your OpenBSD install has been successfully completed!

To boot the new system, enter 'reboot' at the command prompt.

When you login to your new system the first time, please read your mail

using the 'mail' command.

Die Installation ist hiermit abgeschlossen. Um in das neue System zu booten geben Sieam Shell-Prompt das Kommando reboot ein.

# reboot

syncing disks... done




Starten Sie das System neu und geben Sie am Boot-Prompt die folgende Zeile ein.

> boot bsd.mp

Um sowohl den Anoubis-Kernel als auch die Anoubis-Pakete anoubis-daemon undanoubis-gui sowie die zugehörigen Konfigurationsdateien zu deinstallieren, gehen Sie- nach dem erfolgten Neustart des Systems - wie folgt vor.

pkg_delete anoubis-gui

pkg_delete daemon

mv /bsd /bsd.anoubis

cp /bsd.GENERIC.UP /bsd

Die Komponenten anoubis-daemon und anoubis-gui greifen auf zusätzliche Dateienund Pfade zurück, die nicht im Rahmen der Deinstallation der Pakete entfernt werden. Um


2.6. Ubuntu 17

eine vollständige Deinstallation aller für Anoubis relevanten Bestandteile durchzuführen,müssen die unter Punkt B.2.1 und B.3 genannten Pfade und Dateien vom System entferntwerden.


2.6 Ubuntu

Die Anweisungen in diesem Abschnitt gelten sowohl für das Release Ubuntu 9.0.4 “JauntyJackalope” als auch Ubuntu 9.10 “Karmic Koala”. Um das Installieren der Ubuntu-Pakete- vom lokalen Dateisystem aus - mittels dpkg durchzuführen, kopieren Sie bitte die dreiPakete (kernel, anoubis und xanoubis) auf Ihr System.

Wechseln Sie nun in das Verzeichnis, das die zuvor heruntergeladenen Pakete beinhaltet.Die Installation der Anoubis-Pakete kann danach wie folgt durchgeführt werden

dpkg -i linux-image-2.6.26-anoubis-0.9.2.d023.972.d076_1_i386.deb

dpkg -i anoubisd_0.9.2.D023.972.D076_i386.deb

dpkg -i xanoubis_0.9.2.D023.972.D076_i386.deb

Dabei wird durch den Aufruf in der ersten Zeile das Kernel-Paket installiert. Wenndie default Bootloader-Konfiguration verwendet wird, wird ab dem nächsten Reboot dieAnoubis-Security-Suite aktiviert. Ansonsten muss der neue Kernel noch in →Grub oder→Lilo konfiguriert werden.

Um die Installation, der von den Anoubis-Paketen benötigten Abhängigkeiten zu ermögli-chen, geben Sie abschließend den folgenden Befehl ein

apt-get -f install






dpkg --get-selections | grep anoubis | awk '{print $1}'


anoubisd

linux-image-2.6.26-anoubis-0.9.2.d023.972.d133

xanoubis


18 2. Installation


dpkg --purge xanoubis

dpkg --purge anoubisd

dpkg --purge linux-image-2.6.26-anoubis-0.9.2.d023.972.d133

Beachten Sie bitte, dass die Anweisung zur Deinstallation des Kernel-Paket den vollstän-digen Namen (inklusive der Versionsnummer) aufweisen muss. Dieser ist entsprechendder Ausgabe des oben genannten Kommandos anzupassen.




GUI ÜBERBLICK

• Statusanzeige

• Trayicon

• Navigationsleiste

• Hauptfenster

• Infoleiste

• Werkzeuge

• Benachrichtigungen undAnfragen

• Einstellungen

Kapitel 3

GUI Überblick

3.1 Statusanzeige

Wichtige Informationen werden in der Statusanzeige, unabhängig von der aktuell aktivenAnsicht, links oben dargestellt. Dadurch wird es ermöglicht, jederzeit über Statusänderun-gen des Systems informiert zu werden.

Abbildung 3.1: Strukturelle Übersicht der Graphischen Benutzeroberfläche..

22 3. GUI Überblick

3.2 Navigationsleiste

In der links unterhalb der Statusanzeige angeordneten Navigationsleiste befinden sichAuswahlfelder, die den Zugriff auf die einzelnen Module von Anoubis ermöglichen. Im Be-reich Übersicht wird dem Benutzer ein Gesamtüberblick über den Status aller Anoubis-Module gegeben. Weiterhin ist hier eine direkte Zugriffsmöglichkeit - mittels der Schaltflä-chen Verbinden und Trennen - gegeben, um sich mit dem anoubisd zu verbinden bzw.sich von ihm abzumelden. Der Bereich ALF umfasst die vereinfachte Übersicht hinsicht-lich der Firewallfunktionalität. Im Teil SFS, können Einstellungsmöglichkeiten hinsichtlichder zu überwachenden Dateien auf dem Rechner vorgenommen werden. Darüberhinausist die vereinfachte Übersicht der aktiven SFS-Regeln dargestellt. Im Bereich SB befin-det sich die vereinfachte Übersicht der aktiven Sandbox-Regeln. Der Bereich Anoubisermöglicht das Arbeiten mit Benachrichtigungen und Anfragen.

3.3 Hauptfenster

Innerhalb der Module SFS und Anoubis erfolgt die Navigation mittels Reitern, die amoberen Ende des Hauptfensters dargestellt werden. Beispielsweise werden im Modul SFSinnerhalb des Reiters Browser sowohl die Sicht auf das Dateisystem dargestellt als auchdie Verwaltung von Prüfsummen und Signaturen im Kontext des SFS ermöglicht.

3.4 Infoleiste

Die Infoleiste (links unten) stellt verschiedene Informationen zur Aktivität von Anoubis dar.So wird beispielsweise eine fehlgeschlagene Verbindung zum Anoubis Daemon oder dasErgebnis beim Laden einer Regeldatei hier dargestellt.

3.5 Werkzeuge

Im rechten unteren Teil des Anoubis-Hauptfensters befinden sich Schaltflächen, die dendirekten Zugriff auf den RuleEditor, LogViewer und den Wizard erlauben. Der RuleE-ditor ermöglicht hierbei sehr feingranulare Einstellungsmöglichkeiten zu den Regelsätzender jeweiligen Anoubis-Module. Im LogViewer werden alle Logmeldungen, Alarme undEskalationen zugänglich gemacht. Der Wizard stellt eine Alternative zur Regelerstellungim RuleEditor dar. Hierbei wird der Benutzer bei der Erstellung von Regeln unterstützt undbegleitet. Alternativ können über die Menüleiste mit Werkzeuge -> LogViewer, Werkzeu-ge -> RuleEditor oder Werkzeuge -> Wizard diese Fenster aufgerufen werden.

3.6 Trayicon

Zusätzlich zum Hauptfenster der Graphischen Benutzeroberfläche steht ein Trayicon zurVerfügung. Trayicons sind die kleinen Symbole, die in der Taskleiste, neben der Uhr er-


3.6. Trayicon 23

scheinen. Diese bieten schnellen und direkten Zugriff auf die GUI. Hierbei werden ab-hängig vom Status des Trayicons die drei folgenden Fälle - mit abnehmender Priorität -unterschieden.

3.6.1 Benachrichtigung über offene Nachfragen

Bei bestehenden Eskalationsmeldungen, die eine Nachfrage beim Benutzer erfordern,erscheint das Trayicon mit einem roten Fragezeichen im Vordergrund. Ein Linksklick derMaus auf das Symbol führt in diesem Fall direkt in das Fenster zur Beantwortung derentsprechenden Eskalationen.

3.6.2 Benachrichtigung über Alarme

Bei aufgelaufenen Logmeldungen und Alarmen (Fehlschlagen der Verbindung zum Dae-mon, nichtgeladene Module) wird das Trayicon mit einem gelben Ausrufezeichen verse-hen. Ein Linksklick der Maus auf das Symbol öffnet automatisch die Ansicht der Logmel-dungen im GUI.

3.6.3 Normalzustand

Stehen weder Alarme noch Eskalationen an, so wird das Trayicon ohne weitere farbli-che Hervorhebung präsentiert. In diesem Zustand führt ein Linksklick der Maus auf dasSymbol zum Umschalten der Sichtbarkeit der GUI. Dies führt bei sichtbarer GUI zum Ver-bergen des Fensters und im gegenteiligen Fall zur Anzeige dergleichen.

Darüber hinaus kann jederzeit - durch einen Rechtsklick der Maus auf das Symbol - dasKontextmenü der grafischen Benutzeroberfläche aktiviert werden. Dieses bietet sowohleine Option zum Beenden als zum Wiederherstellen der GUI.



Abbildung 3.2: Darstellungsfenster für Benachrichtigungen..

3.7 Benachrichtigungen und Anfragen

Wenn eine „ask”-Regel erstellt wurde, entscheidet Anoubis nicht selbst darüber, was Pro-zesse dürfen und was nicht. Statt dessen erzeugt Anoubis eine Nachfrage, d. h. Anoubisüberlässt dem Benutzer die Entscheidung, ob ein Programm z.B. eine Netzwerkverbin-dung erstellen darf oder nicht.

Wenn beispielsweise die Applikation Firefox eine „ask”-Regel hat, fragt Anoubis bei je-der von Firefox aufgebauten Verbindung beim Benutzer nach, ob diese zugelassen oderverhindert werden soll.

3.7.1 Benachrichtigungen

Im Navigationselement Anoubis erscheint unter dem Reiter Benachrichtigungen (sieheAbbildung 3.2) ein Drop-Down-Menü mit Auswahlmöglichkeit zu verschiedenen Ansichten(Aktuelle Anfragen, Benachrichtigungen, Geschlossene Nachfragen, Alle).

Aktuelle Anfragen

Unter Aktuelle Anfragen können die von Anoubis generierten Nachfragen beantwortetwerden. Nachdem über die Dauer der Gültigkeit entschieden wurde, kann mittels derSchaltflächen erlauben oder verbieten die gewünschte Entscheidung getroffen werden.


3.8. Einstellungen 25

Sollte der Firefox eine „ask”-Regel haben dann erscheint bei einem Verbindungsaufbau ei-ne Nachfage. Diese Nachfage beinhaltet einen Informationsteil und einen Einstellungsteil.Im Einstellungsteil lässt sich die Bedingung zur Gültigkeit präzise festlegen.

Benachrichtigungen

Im Bereich Benachrichtigungen können entstandene Benachrichtigungen betrachtetwerden. Benachrichtigungen werden von Regeln erzeugt, bei denen im Regeleditor un-ter „Logging” das Attribut normal oder kritisch aktiviert wurde.

Geschlossene Nachfragen

Wenn Geschlossene Nachfragen ausgewählt wurde, kann Einblick in die bereits beant-worteten Nachfragen genommen werden.

Alle

Hier lassen sich alle Nachrichten darstellen.

3.8 Einstellungen

Der Reiter Einstellungen bietet Zugriff auf die Konfigurationsmöglichkeiten hinsichtlichdes Verhaltens der grafischen Benutzeroberfläche.

3.8.1 Einstellungen zur Esklationsbenachrichtigung

Die Einstellung Sende Eskalationen ermöglicht die Darstellung von Nachfragen in Pop-Up-Fenstern am rechten unteren Bildschirmrand an- oder auszuschalten. Dabei kannebenfalls eingestellt werden, wie lange diese Pop-Up-Fenster geöffnet bleiben sollen.

3.8.2 Einstellungen zur Alarmbenachrichtigung

Mittels der Einstellung Sende Alarme besteht die Möglichkeit, die Darstellung von Alar-men in Pop-Up-Fenstern am rechten unteren Bildschirmrand an- oder auszuschalten. Hierkann ebenfalls eingestellt werden, wie lange diese Pop-Up-Fenster geöffnet bleiben sol-len.

3.8.3 Autostart

Die Aktivierung der Einstellung Autostart registriert die Graphische Benutzeroberflächefür den automatischen Start unter den Desktopumgebungen KDE und Gnome.



Abbildung 3.3: Upgrade Dialogbox

3.8.4 RuleEditor

Bei Aktivierung der Einstellung Automatische Prüfsummenüberprüfung werden auto-matisch alle direkt in einem Regelsatz enthaltenen Prüfsummen vor dem Senden desRegelsatzes an den Daemon überprüft.

3.8.5 Verbindung

Beim Aktivieren der Einstellung Automatisches Verbinden zum Daemon verbindet sichdie GUI beim Start automatisch mit dem Daemon.

3.8.6 Tool Tips

Wird diese Einstellung aktiviert, so werden dem Benutzer weitergehende Informationen zuden einzelnen Schaltflächen des GUI angezeigt, wenn der Mauszeiger für die Dauer dereingestellten Zeit in Sekunden auf diesen verweilt.

3.9 Upgrade Dialogbox

Beim Verbinden mit dem Anoubis Daemon oder nach Abschluss der Installation neuerSoftware im Rahmen eins Upgrades wird überprüft, ob Signaturen registriert sind, diejetzt angepasst werden müssen. Ist dies der Fall wird dem Benutzer eine Dialogbox (sieheAbbildung 3.3) angezeigt, um ihn auf diese Änderungen hinzuweisen. In diesem Dialoghat er die Möglichkeit, die Option zum Wiederanzeigen der Dialogbox auszuschalten, denDialog ohne weitere Aktionen zu beenden oder den SFS Browser zu öffnen, um dort einUpdate der signierten Prüfsummen vorzunehmen.

Der Dialog wird standardmäßig angezeigt, allerdings höchstens einmal innerhalb von 60Sekunden. Er kann im Anoubis Main Panel unter der Option Upgrade - Enable UpgradeMessage ausgeschaltet werden. (siehe Abbildung 3.4).

Manche Distributionen installieren im Rahmen eines Upgrades jede Softwarekomponenteeinzeln. Wenn dies der Fall ist, kann es vorkommen, dass der Dialog für einen UpgradeVorgang mehrmals angezeigt wird.


3.9. Upgrade Dialogbox 27

Abbildung 3.4: Ein- bzw. Ausschalten der Upgrade Dialogbox



Das Update der signierten Prüfsummen ist wichtig, da sonst auf diese Dateien nicht mehrzugegriffen werden kann. Diese Zugriffsverweigerung kann die Funktionalität des Systemsbeeinträchtigen.


KONFIGURATION

• Allgemein

• Kontexte undKontextwechsel

• Konfiguration ALF

• Konfiguration SFS

• Konfiguration Sandbox

• Schlüssel

• Regelwizard

• Spezielle Hinweise

Kapitel 4

Konfiguration

4.1 Allgemein

Die Konfiguration von Anoubis erfolgt über Policies, die die Berechtigungen für einzelneAnwendungen enthalten. Zusätzlich kann eine Konfigurationsdatei verwendet werden Fürjeden Nutzer gibt es zwei voneinander unabhängige Regelsätze:

Der Administratorregelsatz mit Priorität 0 Dieser Regelsatz wird vom Administratorvorgegeben und kann vom Nutzer nicht verändert werden. Die darin enthaltenen Re-geln geben den Rahmen vor innerhalb dessen der Nutzer für einzelne Anwendungennoch weitergehende Einschränkungen vornehmen kann.

Der Nutzerregelsatz mit Priorität 1 Dieser Regelsatz steht vollständig unter der Kontrol-le des Nutzers selbst. Damit kann dieser Einschränkungen für Anwendungen nachseinen persönlichen Vorstellungen festlegen.

4.1.1 anoubisctl

Das Kommandozeilenwerkzeug anoubisctl ermöglicht die manuelle Kontrolle des anou-bisd.

• Anzeige des aktiven Regelsatzes

Der aktuell in Verwendung befindliche Regelsatz lässt sich mittels des folgenden Auf-rufs anzeigen:

anoubisctl dump -

Hierbei erfolgt die Ausgabe per default auf stdout. Optional kann die Ausgabe aberauch direkt in eine Datei geschrieben werden, um sie z. B. später manuell zu editie-ren. Der oben genannte Aufruf würde in diesem Fall wie folgt abgeändert:

anoubisctl dump /path/to/file

Eine beispielhafte Ausgabe eines aktuellen Regelsatzes sei im Folgenden zur Veran-schaulichung angeführt.

32 4. Konfiguration

# Policies for UID 1002 PRIO 1

apnversion 1.3

alf {

3: any {

1: ask connect log tcp from any to any port 22

2: default log allow

}

}

sfs {

}

sandbox {

}

context {

5: any {

4: context new any

}

}

• Testen und Aktivieren von Regelsatzdateien

Nachdem Änderungen an einer (zuvor gespeicherten bzw. erstellten) Regelsatzdateivorgenommen wurden, kann diese vor der eigentlichen Aktivierung auf syntaktischeKorrektheit getestet werden.

anoubisctl -n -v load /path/to/file

Die Bedeutung der Optionen ist wie folgt:

-n teste die Regeln aus der übergebenen Regeldatei, aber aktiviere sie nicht.

-v ausführliche Ausgabe

Wenn keine Fehlermeldungen erzeugt wurden, so können die Regeln aus der Dateimit dem folgenden Kommando aktiviert werden.

anoubisctl load /path/to/file

• Weitere Optionen

-p admin Ein folgendes load oder dump Kommando bezieht sich auf die Admini-stratorregeln statt auf die Nutzerregeln. Für den Administrator ist dies die Voreinstel-lung. Im Falle von load ist diese Option nur dem Administrator erlaubt.

-p user Ein folgendes load oder dump Kommando bezieht sich auf die Nutzerre-geln. Für normale Benutzer ist dies die Voreinstellung.

-u uid Ein folgendes load oder dump bezieht sich auf den angegebenen User undnicht auf den Aufrufer des Programms, bei Angabe von -u DEFAULT auf die Default-Policies. Diese Option steht nur dem Administrator zur Verfügung.

• Anzeigen der eigenen Prozesse

Mit anoubisctl lässt sich auch ermitteln, welche Regelsätze für welche Prozesse aktivsind. Dazu listet das folgende Kommando die Prozesse des aufrufenden Benutzersauf.

anoubisctl ps


4.1. Allgemein 33

Zu jedem Prozess werden die verschiedenen Informationen in einer Zeile angezeigt.Eine Ausgabe könnte zum Beispiel folgendermaßen aussehen:

pid=1060 cookie=1628530 alf=15:3 sb=59:0 ctx=49:5 /bin/bash

pid=1102 cookie=1629191 alf=2:3 sb=6:0 ctx=45:5 secureexec /sbin/anoubisctl

Die Informationen bedeuten im Einzelnen:

pid die Prozess-ID des Prozesses

cookie eine vom anoubisd verwendete, eindeutige ID des Prozesses, welche biszum nächsten Systemstart garantiert nur einmal verwendet wird

alf die IDs der für den Prozess aktiven ALF-Regelsatzblöcke

sb die IDs der für den Prozess aktiven Sandbox-Regelsatzblöcke

ctx die IDs der für den Prozess aktiven Kontext-Regelsatzblöcke

secureexec Wenn dieses Flag angezeigt wird, wird der Prozess wie Setuid-Programme behandelt (ptrace ist eingeschränkt, LD_PRELOAD wird ignoriert).

name der Pfad- und Dateiname des Programms

contexts Pfad- und Dateiname der Prozesse, in deren Kontexten das Programm aus-geführt wird (wird nur in Verbindung mit -v angezeigt)

Bei den Feldern alf, sb und ctx wird vor bzw. nach dem Doppelpunkt jeweilsdie ID des aktiven Regelsatzblocks des Admin- bzw. des Benutzer-Regelsatzesausgegeben. Die ID-Nummern finden sich auch in der Ausgabe des Kommandosanoubisctl dump und können so den konkreten Regeln zugeordnet werden.

Analog wird beim Feld contexts vor bzw. nach dem Doppelpunkt der Name derjeni-gen Prozesse ausgegeben, in deren Admin- bzw. Benutzer-Kontext der aktuelle Pro-zess läuft. Dies wird im Normalfall identisch mit dem Namen des aktuellen Prozessessein, es sei denn, der aufrufende Prozess hatte keine entsprechendecontext new

Regel.

Wird die Option -v zweimal angegeben, werden zu den Dateinamen zusätzlich auchdie Prüfsummen der Programmdateien ausgegeben.

Mit Hilfe der Option -u kann sich der Root-Benutzer auch die Prozesse von anderenBenutzern anzeigen lassen.

Hinweis: Die Informationen zu Prozessen die gestartet wurden, bevor anoubisd lief,können unvollständig sein.

• Starten und Stoppen des anoubisd

Des Weiteren ermöglicht anoubisctl die Kontrolle des Anoubis-Daemon mittels derfolgenden Kommandos:

anoubisctl start Der Anoubis-Daemon wird gestartet.

anoubisctl stop Der Anoubis-Daemon wird beendet.

anoubisctl restart Der Anoubis-Daemon wird neu gestartet. Falls notwendig wirdder Neustart so lange verzögert, bis ein gerade laufendes Upgrade beendet ist.

anoubisctl reload Die Konfiguration des Anoubis-Daemon wird neu geladen.

anoubisctl status Der Status des Anoubis-Daemon wird überprüft und ausgegeben.


34 4. Konfiguration

• Passphrase des privaten Schlüssels von root zur Verfügung stellen

Wenn der mit Hilfe der rootkey Option des Anoubis-Daemon konfigurierte priva-te Schlüssel von root durch eine Passphrase geschützt ist, muss diese dem Anou-bis Daemon mitgeteilt werden, bevor ein Upgrade den privaten Schlüssel verwendenkann. Dies kann wie folgt geschehen

anoubisctl passphrase

Der Benutzer wird dann nach der Passphrase gefragt, und diese wird dem Anoubis-Daemon mitgeteilt.

• Versionsinformationen anzeigen

anoubisctl version

Es werden nützliche Versionsinformationen ausgegeben. Dazu gehören die Versionder Anoubis-Installation, aber auch Versionen von internen Schnittstellen. Im Fehler-fall ist die Ausgabe dieses Kommandos von entscheidener Bedeutung!

4.1.2 sfssig

Das Kommandozeilenwerkzeug sfssig dient der Verwaltung von Prüfsummen und Signa-turen des SFS.

Bei der einfachen Prüfsummenverwaltung können Dateien zum SFS hinzugefügt, mit demaktuellen Stand verglichen, aufgelistet und entfernt werden.

• HinzufügenDas Kommando add fügt dem Prüfsummenbestand eine Datei hinzu.

$ sfssig add /pfad/zur/datei

• Validieren (vergleichen)Der Prüfsummenbestand und der Ist-Zustand können mit dem Kommando valida-te verglichen werden. Stimmen beide miteinander überein, wird Checksum Matchausgegeben. Sollten die Prüfsummen nicht übereinstimmen, so wird ChecksumMissmatch zurück gegeben.

$ sfssig validate /pfad/zur/datei

Checksum Match

• AuflistenDie im Prüfsummenbestand zur Überwachung registrierten Dateien können mit demKommando list ausgegeben werden. Mit Hilfe verschiedener Filteroptionen könnenauch verwaiste Einträge aufgefunden werden.

$ sfssig list /pfad/zur/

/pfad/zur/datei1

/pfad/zur/datei2

/pfad/zur/datei3


4.1. Allgemein 35

• EntfernenEin Eintrag kann aus dem Prüfsummenbestand mit dem Parameter del entfernt wer-den.

$ sfssig del /pfad/zur/datei

• ExportUm den eigenen Prüfsummenbestand in eine Datei zu sichern, wird das Kommandoexport verwendet.

$ sfssig export /pfad/zu/dateien/ > export.sfs

• ImportDer gesicherte Prüfsummenbestand kann mit dem Kommando import wieder in anou-bis eingepflegt werden.

$ sfssig import export.sfs

Um diese Kommandos auf Signaturen anzuwenden muss die Kommandozeilenoption--sig hinzugefügt werden.

$ sfssig --sig add /pfad/zur/datei

Sollten keine Schlüssel wie im Kapitel 4.7 beschrieben hinterlegt worden sein, so könnendiese mittels -k und --cert als Optionen sfssig bekannt gemacht werden.

$ sfssig -k /pfad/zum/private.key --cert /pfad/zum/pub.crt \

--sig add /pfad/zur/datei

Um ein Kommando rekursiv auf ein Verzeichnis anzuwenden, wird die Option -r mitgege-ben.

Filteroptionen können verwendet werden, um ein Kommando auf eine bestimmte Men-ge an Dateien oder Prüfsummeneinträgen gezielt anzuwenden. Im Folgenden sollen dieeinzelnen Filteroptionen erläutert werden.

• –hassig oder –hassumDiese Filteroptionen wenden das Kommando nur auf die Menge an übergebenen Da-teien an, die einen Eintrag im Prüfsummenbestand haben. Dabei werden von –hassigEinträge mit Signaturen und von –hassum alle nicht signierten Einträge erfasst.

• –hasnosig oder –hasnosumDiese Filteroptionen wenden das Kommando nur auf die Menge von übergebenenDateien an, die keine Einträge im Prüfsummenbestand haben. Die Option –hasnosigbetrachtet Dateien ohne Signatur, –hasnosum ohne Prüfsumme.

• –orphaned oder –notfileDiese Filteroptionen wenden das Kommando auf Einträge im Prüfsummenbestandan, denen entweder keine Dateien oder Verzeichnisse zugeordnet werden können(–orphaned), oder keine regulären Dateien sind (–notfile).


36 4. Konfiguration

• –upgradedDiese Filteroption ist nur auf Signaturen (–sig) anwendbar. Sie wendet das Komman-do auf signierte Einträge an, welche von einem Upgrade Prozess verändert wurden.

Zu den eben beschriebenen Funktionen, ermöglicht sfssig die Verwaltung von System-Signaturen. System-Signaturen sind Prüfsummen, die in den Extended-Attributes einerDatei abgelegt werden. Hier durch können auch dann Aussagen über systemkritischeDateien getroffen werden, bevor der Anoubis-Daemon gestartet wurde.

• Hinzufügen einer System-Prüfsumme zu einer Datei:

$ sfssig -A /Pfad/zur/Datei

• Aktualisieren einer System-Prüfsumme von einer Datei:

$ sfssig -U /Pfad/zur/Datei

• Entfernen einer System-Prüfsumme von einer Datei:

$ sfssig -R /Pfad/zur/Datei

• Anzeigen einer System-Prüfsumme von einer Datei:

$ sfssig -L /Pfad/zur/Datei

Extended-Attributes können nur mit Administrator-Rechten verändert werden. MittelsExtended-Attributes kann dem Kernel aber auch mitgeteilt werden, bestimmte Dateienbei der Kalkulation von Prüfsummen auszunehmen.

• Verifikation einer Datei durch den Kernel verhindern:

$ sfssig -S /Pfad/zur/Datei

• Verifikation einer Datei durch den Kernel zulassen:

$ sfssig -C /Pfad/zur/Datei

Weitere Details zu sfssig sind in der Manpage sfssig(8) zu finden.

4.1.3 Playground

Mit dem Kommandozeilenwerkzeug playground lässt sich die Playground-Umgebung vonAnoubis, wie auch mit xanoubis, steuern und verwalten.

Neben dem Starten von Programmen in einem Playground lassen sich aktive und be-endete Playgrounds (sowie die von ihnen angelegten oder modifizierten Dateien) an-zeigen, löschen oder in das System übernehmen. Die folgende Beschreibung der play-ground-Parameter und -Optionen entspricht der zum Programm gehörigen Manpageplayground(8):

• Ein Programm in einer Playground-Umgebung starten:


4.1. Allgemein 37

$ playground start <Kommando> [weitere Optionen]

Wenn die gestartete Anwendung ein X-Windows Programm ist, dann wird zusätzlichdie Option -X empfohlen. Diese sorgt dafür, daß die Anwendung in einer isoliertenX11 Umgebung gestartet wird. Dadurch wird klarer ersichtlich, welche Programme ineiner Playground-Umgebung laufen und welchen nicht.

Zum Aufbau der X11-Umgebung wird ein Skript in verwendet, das zusammen mitdem xanoubis Paket unter /usr/share/xanoubis/utils/xpgwrapper instal-liert wird. Das Skript ist so gestaltet, dass keine weiteren Anpassungen an die lo-kalen Gegebenheiten notwenig sind, es kann aber Bedarf durch den Administratoreditiert werden. Insbesondere kann dort die Displaygröße der X11-Umgebung von1024x768x24 auf einen anderen Wert abgeändert werden.

• Anzeigen aller aktiven oder beendeten Playground-Sitzungen:

$ playground list

Beispiel:

$ playground list

PGID USER STATUS FILES TIME COMMAND

1061bc 1000 active 3 2010-09-08 10:45:07 /usr/bin/xterm

105c82 1000 inactive 3 2010-09-07 16:15:36 /bin/bash

105c7b 1000 inactive 2 2010-09-07 15:41:38 /bin/bash

PGID ist die Playground-ID, welche für alle folgenden Kommandos anzugeben ist.Der erste Playground in der Liste ist noch aktiv, was bedeutet, dass das Komman-do xterm noch nicht beendet wurde. Das hat zur Folge, dass aus diesem Playgroundweder Dateien übernommen noch gelöscht werden können. Entsprechend kann auchder gesamte Playground noch nicht gelöscht werden, solange er aktiv ist. Desweite-ren können alle folgenden Playground-Kommandos, vom Anzeigen der darin befind-lichen Dateien abgesehen, nur auf Playgrounds mit dem Status ’inactive’ angewandtwerden.

• Auflistung neuer oder modifizierter Dateien in einem bestimmten Playground:

$ playground files <Playground ID>

Beispiel:

$ playground files 1061bc

PGID DEV INODE FILE

1061bc fc00004 1e /tmp/foo

1061bc fc00004 20 /tmp/bar

1061bc fc00004 42 /tmp/another_example

• Übernehmen von Dateien aus einem Playground:

$ playground commit [--ignore-recommended] <Playground ID>


38 4. Konfiguration

Die Option –ignore-recommended bzw. -F erlaubt die Übernahme von Dateien trotzWarnungen von ’empfohlenen’ (recommended) Inhaltsscannern (Virenscanner bei-spielsweise). Ist ein solcher jedoch als required (erforderlich) konfiguriert und gibtdieser eine entsprechende Warnung aus, so ist eine Übernahme der gemeldeten Da-tei(en) in das System nicht mehr möglich.

Desweiteren kann man in diesem Zusammenhang die Option -f verwenden, was einÜberschreiben der bereits im System vorhandenen Dateien erlaubt.

Für das folgende Beispiel wurde der erste Playground aus der Liste zuerst beendet,d.h. das xterm Terminal-Programm geschlossen, womit der Playground nicht mehrals aktiv geführt wird. Nun versuchen wir die Datei /tmp/foo in das System zu über-nehmen:

$ playground commit 1061bc /tmp/foo

$ ls /tmp/foo

/tmp/foo

Das commit-Kommando hat in diesem Beispiel keine Fehlermeldung ausgegeben,was bedeutet, dass die Übernahme von /tmp/foo erfolgreich war. Dies sieht man auchdaran, dass der darauf folgende Aufruf des ls-Kommandos die Datei als im Systemvorhanden darstellt.

• Löschen einzelner Dateien aus einer Playground-Sitzung:

$ playground delete <Playground ID> <Dateiname> ...

Im nächsten Beispiel soll eine einzelne Datei aus dem selben Playground entferntwerden:

$ playground delete 1061bc /tmp/another_example

UNLINKED /tmp/another_example

Wie man aus der UNLINKED-Meldung entnehmen kann, war auch dies erfolgreich.Würde man nun die Dateien dieser Playground-Sitzung erneut auflisten, so wäre nurnoch die Datei /tmp/bar vorhanden.

Es können Fälle auftreten, bei denen sich zwar Dateien und Verzeichnisse in einemPlayground befinden, sie aber nicht mehr physikalisch existieren. Solche Situationenentstehen, wenn Playgrounds Dateien referenzieren, die auf nicht-persistenten Datei-systemen (wie zum Beispeil tmpfs) gespeichert werden. Nach einem Reboot gehendiese Dateien verloren. Um diese Dateien trotzdem aus einem Playground löschenzu können, kann das delete-Kommando mit der Option -f aufgerufen werden. Jetzterwartet das Kommando keinen Dateinamen mehr sondern das Device- und Inode-Paar (getrennt durch einen Doppelpunkt):

$ playground -f delete 1061bc fc00004:42

UNLINKED fc00004:42

• Löschen eines gesamten Playgrounds:

$ playground remove <Playground ID>

Beispiel:


4.2. Kontexte und Kontextwechsel 39

$ playground remove 1061bc

UNLINKED /tmp/bar

$ playground list

PGID USER STATUS FILES TIME COMMAND

105c82 1000 inactive 3 2010-08-10 16:15:36 /bin/bash

105c7b 1000 inactive 2 2010-08-10 15:41:38 /bin/bash

Wie man anhand der Ausgabe beider Befehle in dem obigen Beispiel sehen kann,wurde zuerst der Inhalt des Playgrounds, also die Datei /tmp/foo, gelöscht und an-schlies̈end die gesamte Playground-Sitzung aus der Liste ausgetragen.

Ferner unterstützt das playground-Kommandozeilenwerkzeug, wie anoubisctl undsfssig die Optionen -h, um die möglichen Optionen und Kommandos (bzw. derenSyntax) anzuzeigen, sowie -k und -c, um alternative Schlüssel oder Zertifikate ver-wenden zu können.

Analog zum delete-Kommando kann auch hier die Option -f angegeben werden. So-mit kann ein Playground gelöscht werden, obwohl der Dateien enthällt, die nicht mehrreferenziert werden können.

4.2 Kontexte und Kontextwechsel

Regeln für den Kontextwechsel legen fest, welche Regeln aktiv werden, wenn ein Pro-gramm (mit Hilfe des Systemaufrufs exec(2)) eine andere Anwendung ausführt.

4.2.1 Grundlagen

Die Sandbox-, ALF- und Kontext-Regeln in einem Regelsatz bestehen aus einer Reihevon Blöcken. Jeder Block gilt für eine oder mehrere Anwendungen und enthält einen Satzvon Regeln. Der Kontext einer Anwendung besteht aus dem Pfad eines ausführbaren Pro-gramms und der zugehörigen Prüfsumme. Er entscheidet in den Modulen ALF und Sand-box sowie wiederum bei den Regeln für Kontextwechsel, welcher Regelblock für dieseAnwendung aktiv ist.

Um die Regeln für eine Anwendung zu finden, wird für jedes der drei Module (ALF, Sand-box und Kontext) der erste Block gesucht, der in seiner Liste von Anwendungen den aktu-ell gültigen Kontext enthält. Ein spezieller Block, der mit „any” gekennzeichnet wird, findetAnwendung, wenn in einem Modul kein anderer Block vorhanden ist, der zum aktuellenKontext passt.

Kontext-Regeln legen fest, ob beim Ausführen eines Programms der Kontext des Pro-zesses beibehalten wird, oder ob Pfad und Prüfsumme des ausgeführten Programms alsKontext übernommen werden.

Der Kontext eines ausgeführten Programms muss also nicht notwendigerweise mitden Daten des ausgeführten Programms übereinstimmen.

4.2.2 Aufbau von Kontext-Regeln

Regeln für den Kontextwechsel sind wie folgt aufgebaut:


40 4. Konfiguration

context {

{ app } flags {

context new { app }

context new any

}

}

Die Bedeutung der einzelnen Komponenten ist dabei wie folgt:alf Ein Schlüsselwort, das den ALF-Regelblock einleitet.{ app } Eine Liste von Applikationen. Jede Applikation besteht aus ei-

nem absoluten Pfadnamen. Zusätzlich kann angegeben wer-den, dass nicht der Pfadname sondern eine unter diesem Pfad-namen hinterlegte (signiert oder unsignierte) Prüfsumme zurIdentifikation der Applikation verwendet werden soll. Mehre-re Applikationen werden durch Komma voneinander getrennt.Statt einer Liste von Applikationen, kann auch das spezielleSchlüsselwort „,any” verwendet werden.

context new Leitet eine Kontext-Regel ein.any Ein Schlüsselwort, das statt einer Liste von Anwendungen ver-

wendet werden kann, um eine Aussage über alle Anwendun-gen zu treffen.

flags Mit Hilfe von zwei zusätzliche Flags können besondere Ei-genschaften für Programme aktiviert werden, die mit diesemKontext laufen: Das Flag nosfs bewirkt, dass Zugriff diesesProzesses auf das Dataisystem nicht den SFS-Regeln unter-liegen. Das Flag pgforce erzwingt einen neuen Playgroundfür den Prozess, falls dieser nicht bereits in einem Playgroundläuft.

Eine Liste von Applikationen kommt in Kontextregeln an zwei verschiedenen Stellen inganz unterschiedlicher Bedeutung vor:

Unmittelbar vor einem Block Hier geben die Anwendungen in der Liste an, für welcheKontexte dieser Block gilt.

In einer context new Regel Hier enthält die Liste alle Anwendungen, bei deren Ausfüh-rung ein neuer Kontext mit den Daten der Anwendung geöffnet wird. Wenn für eineausgeführte Anwendung keine Regel zutrifft, dann wird der aktive Kontext des aus-geführten Programms beibehalten.

4.2.3 Spezielle Kontextwechsel

In einigen speziellen Fällen ist es nicht nur beim Ausführen eines Programms sinnvolleinen Kontextwechsel durchzuführen, sondern auch dann, wenn bestimmte Dateien (inder Regel Shared Libraries) geöffnet werden.

Das kann über besondere Kontext-Regeln erreicht werden. Sie unterscheiden sich von ei-ner normalen Kontextregel dadurch, dass das Schlüsselwort new durch das Schlüsselwortopen ersetzt wird.


4.3. ALF 41

Allerdings erfordert der sichere Umgang mit dieser Art von Kontext-Regeln eine gewisseSorgfalt und birgt die Gefahr, dass ungewollte Effekte entstehen können. Daher solltendiese Regeln nur dann eingesetzt werden, wenn sie unbedingt notwendig sind.

4.3 ALF

Die Konfiguration der ALF geschieht über Policies mit folgendem Aufbau:

alf {

{ app } [ pgonly ] {

action operation [log|alert] [family] protocol \

from address [port x] to address [port x]

action [log|alert] capability

default [log|alert] action

}

}

Die einzelnen Komponenten haben folgende Bedeutung:

app Die Anwendung (siehe A.2.2), für die die Regel gelten soll. Hierkann „any” bzw. ein Pfad mit Prüfsumme angegeben werden.Wird das optionale Flag pgonly angegeben, dann wird die-ser Regelblock nur verwendet, wenn die Anwendung in einemPlayground läuft.

action Die Aktion, die beim Zutreffen der Regel ausgeführt werdensoll. Mögliche Aktionen sind allow (Zulassen der Verbindung),deny (Unterbinden der Verbindung) und ask (Nachfrage anden Benutzer).

operation Netzwerkoperation, auf die die Regel zutreffen soll. MöglicheOperationen sind send (Senden von Datenpaketen), receive(Empfangen von Datenpaketen), connect (Aufbauen von Ver-bindungen (TCP/SCTP)) und accept (Annehmen von Verbin-dungen (TCP/SCTP)).

log, alert (optional) Optionale Schlüsselwörter mit der Bedeutung, dass das Zutref-fen der Regeln mitprotokolliert werden soll. „alert” hat hierbeieine höhere Priorität als „log”.

capability Angabe, ob die Regel Zugriff auf privilegierte Sockets habensoll. Mögliche Werte sind raw (RAW Socket), other (andereSockets) und all (alle Sockets). In der Regel muss die An-wendung zusätzlich über Root-Rechte verfügen.

family (optional) Angabe der Adressfamilie, auf die die Regel zutreffen soll.Mögliche Adressfamilien sind inet für IPv4 und inet6 fürIPv6.

protocol Angabe des IP-Protokolls, auf das die Regel zutreffen soll.Mögliche Protokolle sind tcp, udp und sctp.

from Schlüsselwort, auf das die Angabe einer Absenderinformationfolgt.


42 4. Konfiguration

to Schlüsselwort, auf das die Angabe einer Empfängerinformati-on folgt.

address Adressangabe für Absender- und Empfängerinformation. Eswird die übliche Darstellung der gewählten Adressfamilie ge-nutzt, z.B. 127.0.0.1 (IPv4) oder 127::1 (IPv6). Statt einer ein-zelnen Adresse ist auch die Angabe eines Netzwerks mit Hilfevon Netzmasken zulässig.

port x Angabe des Netzwerkports für Absender- und Empfängerinfor-mation. Der gültige Wertebereich ist 0 bis 65535.

default Schlüsselwort, das eine Default-Regel angibt. Diese Regelwird ausgewählt, wenn keine andere Regel zutrifft.

Im folgenden Beispielsregelsatz (gültig in jedem Kontext) werden Verbindungen zu ei-nem Webserver (192.168.0.10) mit Protokollierung zugelassen, Verbindungen zu einemSSH-Server (192.168.0.200) abgelehnt, aber SSH-Verbindungen zu allen anderen Com-putern in dem Subnetz 192.168.0.0/24 zugelassen. Weiterhin können DNS-Anfragen anden DNS-Server 192.168.0.1 gestellt und die Antworten empfangen werden. Ein andererComputer mit der IPv6-Adresse fe80::200:12ff:fe34:5678 darf SSH-Verbindungen auf denlokalen Rechner aufbauen. Sollte keine der vorherigen Regeln zutreffen, wird der Netz-werkverkehr unterbunden und ein Protokolleintrag erzeugt.

alf {

any {

allow connect log inet tcp from any to 192.168.0.10 port 80

deny connect inet tcp from any to 192.168.0.200 port 22

allow connect inet tcp from any to 192.168.0.0/24 port 22

allow send inet udp from any to 192.168.0.1 port 53

allow receive inet udp from 192.168.0.1 to any port 53

allow accept log inet6 from \

fe80:0000:0000:0000:0200:12ff:fe34:5678 to any port 22

default log deny

}

}

4.4 SFS

Das Modul SFS bietet jedem Nutzer die Möglichkeit, Prüfsummen zu Dateien in einer vomSystem verwalteten Datenbank einzutragen. Diese Prüfsummen können optional signiertwerden, wenn der Administator den öffentlichen Schlüssel des Nutzers im System hinter-legt hat.

Diese Prüfsummen können genutzt werden, um den Zugriff mit Hilfe von SFS-Regelneinzuschränken. Die dazu verwendeten SFS-Regeln sind wie folgt aufgebaut:

sfs {

path subject valid action invalid action unknown action

default path action

}


4.4. SFS 43

Die Bedeutung der einzelnen Komponenten ist dabei wie folgt:


44 4. Konfiguration

sfs Ein Schlüsselwort, das den SFS-Regelblock einleitet.path Entweder das spezielle Schlüsselwort „any” für „ein beliebiger

Pfad” oder das Schlüsselwort „path” gefolgt von einem Pfad-präfix, das den Gültigkeitsbereich der Regel auf Dateien unter-halb dieses Pfades einschränkt.

subject Dieser Teil einer Regel gibt an, welche Prüfsumme für die Re-gel herangezogen werden soll. Die folgenden Möglichkeitenstehen zur Verfügung:

• „self”: Eine vom Nutzer selbst hinterlegte unsigniertePrüfsumme.

• „self-signed”: Eine vom Nutzer selbst hinterlegte si-gnierte Prüfsumme

• „uid 4711”: Eine vom Nutzer mit der User-ID 4711 hin-terlegte unsignierte Prüfsumme.

• „key d5ab3...abcd”: Eine durch einen Schlüssel mitder angegebenen Key-ID signierte Prüfsumme.

valid action Die Aktion wird angewandt, falls die Prüfsumme zum Inhalt derDatei passt.

invalid action Die Aktion wird angewandt, falls die Prüfsumme nicht zum In-halt der Datei passt.

unknown action Die Aktion wird angewandt, falls keine geeignete Prüfsummeim System gefunden wurde.

action Eine Aktion besteht aus einer optionalen Anweisung, mit dereine Logmeldung erzeugt werden kann („log” oder „alert”)und der eigentlichen Aktion. Mögliche Aktionen sind:

• „allow” Zugriff erlauben

• „deny” Zugriff verbieten

• „ask” Beim Nutzer rückfragen

• „continue” Keine Entscheidung. Die Auswertung wirdmit der nächsten Regel fortgesetzt.

„default” Schlüsselwort, das eine Default-Regel kennzeichnet. Default-Regeln enthalten lediglich ein Pfadpräfix und eine Aktion. EinePrüfsumme ist nicht notwendig. Eine Default-Regel findet nurAnwendung, wenn keine andere SFS-Regel anwendbar ist.

Ein Beispiel für einen SFS-Regelsatz könnte wie folgt aussehen:

sfs {

default path / ask

path /tmp valid log allow invalid allow unknown allow

path /etc uid 0 valid allow invalid log deny unknown ask


4.4. SFS 45

path / self valid allow invalid log deny unknown continue

}

Diese Policy drückt folgendes aus:

• Unterhalb von /tmp sind Zugriffe unabhänig von Prüfsummen erlaubt.

• Zugriffe unterhalb von /etc sind erlaubt, wenn eine gültige Prüfsumme von root (uid0) vorhanden ist. Bei einer ungültigen Prüfsumme, ist der Zugriff verboten, ansonstenwird beim Nutzer nachgefragt.

• Für alle anderen Dateien (unterhalb von /) wird der Zugriff bei einer gültigen eige-nen Prüfsumme erlaubt und bei einer ungültigen eigenen Prüfsumme verboten. Istkeine eigene Prüfsumme vorhanden, dann wird anhand der verbleibenden Regelnentschieden.

• In diesem Fall ist dies nur noch die Default-Regel, die angibt, dass beim Nutzer nach-gefragt werden soll.

• Alle Zugriffe, die verboten werden, erzeugen eine Logmeldung.

4.4.1 Behandlung von symbolischen Links

Ist ein Pfad in dem SFS-Regelsatz ein symbolischer Link, dann müssen die folgendenzwei Möglichkeiten betrachtet werden.

• Die Prüfsumme wird über den Link berechnet.

• Die Prüfsumme wird über den Dateiinhalt berechnet.

Diese beiden Möglichkeiten unterscheiden sich in ihrer Aussagekraft. Wenn die Prüfsum-me über den Link berechnet wird, dann wird eine Aussage über den Link getroffen. Ändertsich das Linkziel, so wird sich auch die Prüfsumme ändern. Diese Prüfsumme wird heran-gezogen, wenn beim Öffnen einer Datei der symbolische Link verfolgt wird.

Wenn hingegen die Prüfsumme über den Dateiinhalt berechnet wird, dann wird eine Aus-sage über die Konsistenz des verlinkten Dateiinhalts getroffen. Die Prüfsumme muss dannunter dem echten Namen der verlinkten Datei in die Prüfsummen-Datenbank eingetragenwerden. Diese Prüfsumme wird verwendet, wenn die Datei tatsächlich geöffnet wird.

4.4.2 SFS-Ausnahmen für einzelne Anwendungen

Die SFS-Regeln sind im Gegensatz zu denen von ALF und Sandbox immer für alle An-wendungen eines Nutzers gültig. Allerdings besteht gelegentlich der Bedarf, spezielle Pro-gramme von den SFS-Regeln auszunehmen. Dies kann zum Beispiel für Virenscannersinnvoll sein, die eine Datei scannen sollen, bevor eine neue Prüfsumme erstellt wird.Genauso ist dies für Anoubis-Clients notwendig, die selbst Prüfsummen erstellen. In bei-den Fällen besteht die Notwendigkeit, dass diese Programme unabhängig von eventuellhinterlegten Prüfsummen und den aktiven SFS-Regeln auf Dateien zugreifen dürfen.

Um dies zu erreichen, muss in der Context-Policy für die betroffenen Applikationen mussdas Flag nosfs angegeben werden.


46 4. Konfiguration

Konfigurieren der SFS-Ausnahme in Policies

Das folgenden Beispiel zeigt, wie eine Policy aussehen könnte, die die Programme/usr/bin/vscan und /sbin/sfssig von den SFS-Regeln des Users ausnimmt.

apnversion 1.1

sfs {

path "/" uid 0 valid allow invalid deny unknown ask

}

context {

/usr/bin/vscan nosfs {

context new any

}

/sbin/sfssig nosfs {

context new any

}

any {

context new any

}

}

Die konfigurierte Ausnahme gilt nur für den Nutzer und die Priorität für die sie konfigu-riert wurde. Wenn sowohl der Administrator als auch der Nutzer SFS-Regeln konfigurierthaben, müssen beide in den jeweiligen Regeln dafür Ausnahmen vorsehen.

4.5 Sandbox

Die Konfiguration der Sandbox (SB) geschieht über Policies mit folgendem Aufbau:

sandbox {

{ app } [ pgonly ] {

action path [ subject ] rwx

default action

}

}

Dabei ist die Bedeutung der einzelnen Komponenten wie folgt:

sandbox Ein Schlüsselwort, das den Sandbox-Regelblock einleitet.app Die Anwendung (siehe A.2.2), für die die Regel gelten soll. Hier

kann „any” bzw. ein Pfad mit Prüfsumme angegeben werden.Wird das optionale Flag pgonly angegeben, dann wird die-ser Regelblock nur verwendet, wenn die Anwendung in einemPlayground läuft.

action Eine Aktion besteht aus einer optionalen Anweisung, mit dereine Logmeldung erzeugt werden kann („log” oder „alert”)und der eigentlichen Aktion. Mögliche Aktionen sind:

• „allow” Zugriff erlauben

• „deny” Zugriff verbieten

• „ask” Beim Nutzer rückfragen


4.5. Sandbox 47

path Entweder das spezielle Schlüsselwort „any” für einen belie-bigen Pfad oder das Schlüsselwort „path” gefolgt von einemPfadpräfix, das die Anwendbarkeit der Regel auf Dateien un-terhalb von diesem Pfadpräfix einschränkt.

subject Durch die optionale Angabe einer Prüfsummenquelle in derselben Form, wie es auch im Modul SFS möglich ist, kann dieGültigkeit der Regel auf Dateien eingeschränkt werden, für dieeine gültige Prüfsumme aus der durch subject angegebenenQuelle vorliegt. Wenn die Regel für alle Dateizugriffe unabhän-gig von eventuell hinterlegten Prüfsummen gelten soll, danndarf hier nichts angegeben werden.

rwx Durch eine beliebige Kombination der Buchstaben „r”, „w” und„x” wird die Gültigkeit der Regel auf bestimmte Zugriffsarten(lesen, schreiben bzw. ausführen) eingeschränkt. Auf Zugriffs-arten, die hier nicht genannt werden, hat diese Regel auch kei-nen Einfluss. Um lesende und schreibende Zugriffe auf eineDatei zu erlauben, das Ausführen aber zu verbieten, sind alsozwei Regeln notwendig:

allow /path/to/file rw

deny /path/to/file x

default Das Schlüsselwort „default” kennzeichnet eine Default-Regel. Eine solche Regel findet nur dann Anwendung, wennkeine andere Sandbox-Regel für den fraglichen Zugriff exi-stiert.

Das folgende Beispiel zeigt einen Sandbox-Regelsatz, der Regeln für die Anwendung/usr/sbin/ntpd definiert. Die ersten beiden Zugriffsregeln sagen aus, dass Dateien,für die eine gültige signierte oder unsignierte Prüfsumme hinterlegt wurde, immer gelesenund ausgeführt werden dürfen.

Die weiteren Regeln beschreiben Dateien, oder im Falle von /lib und /usr ganze Ver-zeichnisse mit ihren Unterverzeichnissen, auf die zugegriffen werden darf. Schreibzugriffesind hier nur auf die beiden Dateien /var/run/ntpd.pid und /var/log/ntpstats

erlaubt.

Die Default-Regel am Ende legt fest, dass Zugriffe, die nicht ausdrücklich durch eine an-dere Regel zugelassen wurden, geloggt und verboten werden.

sandbox {

/usr/sbin/ntpd self

{

allow path / signed-self rx

allow path / self rx

allow path /etc/ntp.conf r

allow path /var/run/ntpd.pid rw

allow path /var/lib/ntp rw

allow path /var/log/ntpstats rw

allow path /etc/ld.so.cache r


48 4. Konfiguration

allow path /etc/localtime r

allow path /etc/services r

allow path /etc/nsswitch.conf r

allow path /etc/host.conf r

allow path /etc/hosts r

allow path /lib r

allow path /usr r

default log deny

}

}

4.6 Version

Eine Policy sollte die Versionsnummer der APN-Syntax A enthalten, die sie verwendet.Diese sollte am Anfang einer Policy stehen und folgender Form entsprechen:

apnversion 1.0

4.7 Schlüssel

Zum Registrieren von signierten Prüfsummen und Laden von signierten Policies ist esnotwendig einen RSA Schlüssel zu generieren. Dies soll im Folgenden erläutert werden.

Als erstes muss ein privater RSA Schlüssel erzeugt werden.

openssl genrsa 1024 > private.key

Es besteht hierbei die Möglichkeit, den privaten Schlüssel mit einem Passwort abzusi-chern, was unbedingt zu empfehlen ist.

openssl genrsa -des3 1024 > private.key

Nun kann das Zertifikat mit dem enthaltenen öffentlichen Schlüssel erstellt werden.

openssl req -new -x509 -days 999 -key private.key -out pub.crt

Die so erzeugten Schlüssel sollten danach in das vorgesehene Verzeichnis kopiert wer-den.

cp private.key ~/.xanoubis/default.key

cp pub.crt ~/.xanoubis/default.crt

Alle diese Schritte können auch mit Hilfe des Kommandos anoubis-keygen durchge-führt werden. Dabei wir der Schlüssel erzeugt und so im Verzeichnis ~/.xanoubis ab-gelegt, dass er von dem User-Interfaces gefunden wird. Der Benutzer hat zusätzlich dieMöglichkeit, sein Schlüsselpaar mit xanoubis zu erzeugen. Details dazu sind im Ab-schnitt 5.7.4 zu finden.


4.8. Regelwizard 49

Um den Schlüssel tatsächlich verwenden zu können muss der Administrator den öf-fentlichen Teil des Schlüssels (pub.crt im obigen Beispiel) zusätzlich dem Anoubis-Daemon bekannt machen. Dies geschieht, indem der Administrator das Kommandoanoubis-keyinstall aufruft.

anoubis-keyinstall -u username /path/to/user/certificate

Dadurch wird der Schlüssel im Verzeichnis /var/lib/anoubis/policy/pubkeys/

abgelegt. Der Name des Schlüssels in diesem Verzeichnis entspricht dabei dem nume-rischen Usernamen des Benutzers. Im Anschluss muss der Anoubis-Daemon mit folgen-dem Kommando über den neuen Schlüssel informiert werden.

sudo pkill -HUP anoubisd

Das Kommando anoubis-keygen überprüft vor der Installation des neuen Schlüssels,ob für alle Policies, die dann mit diesem Schlüssel signiert sein müssen bereits gültigeSignaturen vorhanden sind. Ist dies nicht der Fall, wird der Schlüssel nicht installiert. Vor-her muss dann entweder eine gültige Signatur zur Verfügung gestellt werden oder dievorhandene Datei muss entfernt werden, so dass wieder die default-Policy gilt.

Mit Hilfe der Option -k kann zusätzlich der private Schlüssel angegeben werden. Diesist vor allem für den Root-User sinnvoll, dem ja in der Regel in diesem Schritt sowohlder öffentliche als auch der private Schlüssel zur Verfügung stehen. Wenn die Option -k

angegeben ist, werden für alle relevanten Dateien Signaturen erzeugt, bevor der Schlüsselinstalliert wird.

4.8 Regelwizard

Der Administrator darf Standard ALF- und SB-Freigaben erstellen. Klickt der Benutzer imRegelwizard auf add default services (ALF) bzw. add default permissions (SB), dannwerden die entsprechenden Freigaben geladen.

Die Listen werden im Verzeichnis /etc/anoubis/profiles/wizard/ abgelegt. DieDatei alf enthält die ALF-, sandbox die SB-Freigaben.

# defaults for alf wizard

#

# Format:

# <protocol>/<port>

#

udp/53

tcp/53

#

# Defaults for sandbox wizard

#

# Format:

# <object> <permission>

#

# Object may be a file or a directory. Please use

# absolute paths only. And directories must have


50 4. Konfiguration

# trailing '/'.

#

# Permisson may be any combination of the characters:

# r: read permission

# w: write permission

# x: execute permission

#

/bin/ rx

/dev/ r

/dev/shm/ rwx

/dev/tty/ rw

/dev/pts/ rw

/etc/ rx

/home/ rwx

/lib/ rx

/opt/ rx

/proc/ r

/sbin/ rx

/tmp/ rwx

/usr/ rx

/var/ rx

/var/tmp/ rwx

/var/lock/ rwx

4.9 anoubisd.conf

Die Konfigurationsdatei anoubisd.conf, die unter /etc/anoubis zu finden ist, bein-haltet verschiedene Optionen, welche das Laufzeitverhalten des Anoubis Daemons beein-flussen.

Das Format eines Konfigurationsschalters ist:

Option = Wert

Zeilen die mit einem Doppelkreuz (#) beginnen oder leer sind, werden ignoriert. Endeteine Zeile mit einem Backslash (\), wird der Wert in der nächsten Zeile weitergeführt.

Im Folgenden werden die einzelnen Optionen der Konfigurationsdatei erläutert.

4.9.1 Unixsocket

unixsocket Pfad des Unix Domain Sockets, welcher zur Kommunikati-on mit Benutzerprogrammen, wie z. B. anoubisctl oderxanoubis, verwendet wird. Der standardmäßig eingestelltePfad ist /var/run/anoubisd.sock.

4.9.2 Upgradeoptionen

Um den Upgradeprozess zu verfolgen, müssen zwei Optionen eingestellt werden.


4.9. anoubisd.conf 51

upgrade_mode Der Upgrade-Modus definiert, wie Start und Ende eines Upgra-des erfasst werden. Mögliche Werte sind:

• off: Der Upgradeprozess ist ausgeschalten. Es werden kei-ne Upgrades erfasst.

• strictlock: Eine bestimmte Datei wird gelockt, dies istder Beginn des Upgrades. Wird dieser Lock wieder entfernt,ist das Upgrade beendet. Die Lockdatei muss unter der Op-tion upgrade_trigger eingetragen werden.

• looselock: Eine bestimmte Datei wird gelockt, dies ist derBeginn des Upgrades. Wird der Prozess, der den Lock ge-setzt hat beendet, ist dies auch das Ende des Upgrades.Die Lockdatei muss unter der Option upgrade_trigger

eingetragen werden.

• process: Ein bestimmter Prozess wird gestartet, dies istder Beginn des Upgrades. Wird dieser Prozess geschlos-sen ist das Upgrade beendet. Der Pfad zur Binärdatei mussunter der Option upgrade_trigger eingetragen werden.

upgrade_trigger Hier kann eine durch Komma separierte Liste von Auslösern fürein Upgrade angegeben werden. Im Falle von upgrade_mode

= off muss nichts angegeben werden. In allen anderen Fällenmuss die Liste mindestens einen Eintrag beinhalten. Ist mehr alsein Auslöser angegeben, muss nur einer zutreffen, um den Up-gradestart auszulösen.

rootkey Mit dieser Option kann dem Daemon der private Schlüssel desroot-Users zur Verfügung gestellt werden. Wenn vorhanden,dann wird er benutzt, um von root signierte Prüfsummen automa-tisch zu aktualisieren. Wenn der Schlüssel mit einer Passphrasegeschützt ist, dann muss sie mittels anoubisctl zur Verfügunggestellt werden.


52 4. Konfiguration

rootkey_required Hier wird das Verhalten festgelegt, wenn die Upgrade-Prozedurstartet, aber der private Schlüssel des root-Users noch nicht zurVerfügung steht. Dieser Fall tritt ein, wenn die mit rootkey konfi-gurierte Datei nicht existiert, oder die Passphase noch nicht zumDaemon gesendet wurde. Mögliche Werte sind:

• true Wenn der private Schlüssel benötigt wird, dann wirdder Upgrade-Prozess kein Lock auf die Paketdatenbank be-kommen, und er beendet sich mit einer entsprechendenFehlermeldung.

• false Durch root signierte Prüfsummen werden nicht auto-matisch aktualisiert. Er muss es, wie jeder andere Benutzerauch, manuell nach Beendigung des Upgrades durchfüh-ren.

Die Upgrade-Konfiguration für Debian basierende Distributionen sieht beispielsweise fol-gendermaßen aus:

upgrade_mode = looselock

upgrade_trigger = /var/lib/dpkg/lock

4.9.3 Authentisierung

Der Anoubis-Daemon kann verlangen, dass Clients sich beim Verbindungsausbau au-thentisieren. Die Option auth_mode legt das Verhalten fest.

auth_mode Diese Option bestimmt, ob sich Anoubis-Clients gegenüber demAnoubis-Daemon authentisieren sollen, wenn sie eine Verbin-dung aufbauen. Mögliche Werte sind:

• enabled Die Authentisierung ist aktiviert. Die Verbindungwird durch den Anoubis-Daemon nur dann akzeptiert, wennder Client den korrekten Schlüssel verwendet.

• optional Die Authentisierung ist genau dann aktiv, wennein Zertifikat für den anfragenden Benutzer am Anoubis-Daemon hinterlegt wurde. Konnte der Anoubis-Daemonkein Zertifikat finden, dann wird die Verbindung immer ak-zeptiert.

• off Es wird keine Authentisierung vorgenommen. Client-Verbindungen werden durch den Anoubis-Daemon immerakzeptiert.

Der Standardwert ist optional.


4.9. anoubisd.conf 53

4.9.4 Inhaltsscanner

Inhaltsscanner werden ausgeführt, bevor eine Datei aus einem Playground in das Produk-tivsystem übernommen werden kann (commit). Dabei kann der Administrator für jedenScanner festlegen, ob dieser zwingend ausgeführt werden muss (required) oder nurempfohlen ist (recommended).

commit Mit dieser Option wird ein Inhaltsscanner konfiguriert. Diecommit Option kann mehrmals verwendet werden, um mehrereScanner zu konfigurieren. Die Syntax besteht aus drei Teilen:recommended|required /pfad/zum/scanner Name

• Das erste Wort gibt an, ob der Benutzer den Scanner um-gehen kann (recommended) oder nicht (required).

• Danach wird der Pfad- und Dateiname des Scanners ange-geben. Alternativ können auch die Schlüsselwörter allowund deny verwendet werden, wodurch Dateien immer ak-zeptiert bzw. abgelehnt werden.

• Der Rest der Zeile enthält einen Namen für diesen Scanner,der dem Benutzer im Falle einer Einstufung als gefährlichangezeigt wird. Der Name kann auch Leerzeichen enthal-ten.

In der Standardeinstellung ist das Übernehmen von Dateien auseinem Playground nicht möglich. Um ein Übernehmen aller Da-teien ohne Inhaltsscan zu ermölichen, kann die folgende Zeileverwendet werden:commit = required allow Immer akzeptieren

scanner_timeout Diese Option bestimmt, wie lange ein Inhaltsscanner pro Dateibenötigen darf, bevor er abgebrochen wird. Der Wert wird in Se-kunden angegeben, wird aber nur mit einer Granularität von etwa10 Sekunden ausgewertet.Der Standardwert ist 300 (5 Minuten).

Die genaue Spezifikation, wie zu prüfende Dateien an die Inhaltsscanner übergeben wer-den, ist in Anhang D dokumentiert.

4.9.5 Sonstige Optionen

allow_coredumps Diese Option legt fest, ob anoubisd nach einem Absturz einenCoredump erstellen soll. Mögliche Werte sind:

• true Die Erstellung von Coredumps ist aktiv.

• false Es werden keine Coredumps erstellt.

Der Standardwert ist false.


54 4. Konfiguration

policysize Legt die maximale Größe einer Policy fest. Der Anoubis-Daemonlehnt Policies ab, die größer sind, als der festgelegte Wert. Wirdder Wert 0 konfiguriert, dann wird anoubisd die Größe nichtüberprüfen und alle Policies akzeptieren.Der Standardwert ist 20971520 (20MiB).

4.10 Spezielle Hinweise

Dieser Abschnitt enthält Hinweise und Konfigurationstipps für spezielle Anwendungen.

4.10.1 .xanoubis

Das .xanoubis-Verzeichnis liegt im Heimatverzeichnis eines Benutzers. Es enthält dasvon Anoubis verwendete Schlüsselpaar sowie ein Versionsmanagementsysteme für diePolicies. Manipulationen an diesem Verzeichnis könnten daher weitreichende Folgenauf die Sicherheit des Systems haben. Es ist somit anzuraten, dieses Verzeichnis nicht nurmit Unix-Dateirechten abzusichern, sondern auch durch Anoubis. Eine Policy für .xanoubiskönnte somit wie folgt aussehen:

sandbox {

# Only allow anoubis to edit .xanoubis

{"/usr/bin/xanoubis", "/sbin/anoubisctl", "/sbin/sfssig"} {

allow path "/home/user/.xanoubis" rwx

allow any rwx

}

any {

deny path "/home/user/.xanoubis" rwx

allow any rwx

}

}

4.10.2 nscd

Der Name Service Cache Daemon (nscd) ist ein Prozess, der einen Cache für häufigbenutzte Namensdienste (Benutzer-, Gruppen- und Passwort-Daten, Host- und Service-Auflösungen) bereitstellt. Im Kontext mit Anoubis bedeutet es, dass eine Anwendung mög-licherweise DNS-Anfragen an den nscd weiterleitet. Dazu erzeugt die Anwendung überden Socket /var/run/nscd/socket eine Anfrage an den nscd. Daraufhin wird nscdggf. eine DNS-Anfrage (Port 53) starten, und das Resultat an die Anwendung zurück-schicken. Kann keine Verbindung zum nscd aufgebaut werden, erzeugt die Anwendungselbst die DNS-Anfrage.Das sind wichtige Details, die in die Erstellung der Policies einfließen müssen. Der An-wendung muss der Zugriff auf den nscd-Socket gestattet werden, während nscd DNS-Anfragen durchführen darf.Die Konfiguration einer Anwendung, die DNS-Anfragen über nscd durchführen soll, kön-nen auszugsweise folgendermaßen aussehen. Der Zugriff auf den UDP-Port 53 wird ge-sperrt, während die Applikation auf den nscd-Socket zugreifen darf.


4.10. Spezielle Hinweise 55

alf {

"/path/to/application" {

# Zugriff auf das DNS verbieten

deny both udp from any to any port 53

default ask

}

}

sandbox {

"/path/to/application" {

# Zugriff auf nscd-Socket gestatten

allow path "/var/run/nscd/socket" rw

default ask

}

}

Der nscd selbst benötigt ebenfalls Zugriff auf seinen eigenen Socket, und er muss zusätz-lich in der Lage sein, DNS-Anfragen über Port 53 abzusetzen. Die folgende Policy mussdem Benutzer zugeordnet werden, unter dem nscd läuft!

alf {

"/usr/sbin/nscd" {

# Zugriff auf das DNS gestatten

allow both udp from any to any port 53

default ask

}

}

sandbox {

"/usr/sbin/nscd" {

# Zugriff auf den nscd-Socket gestatten

allow path "/var/run/nscd/socket" rw

default ask

}

}

4.10.3 System-V IPC

System-V IPC stellt eine Schnittstelle für den Nachrichtenaustausch über Prozessgrenzenhinweg zur Verfügung. Sicherheitslücken in Programmen können über IPC-Mechanismenausgenutzt werden. System-V IPC wird derzeit von Anoubis nicht betrachtet. Programme,die solche Dienste anbieten, müssen selbst geeignet eingeschrängt werden.


56 4. Konfiguration


BETRIEB

• Eskalationen

• RuleEditor

• Regelwizard

• LogViewer

• Application Level Firewall /ALF

• Sicheres Filesystem / SFS

• Profile

• Versionskontrolle

Kapitel 5

Betrieb

5.1 Anzeigen und Beantworten von Eskalationen

Unter bestimmten Umständen entscheidet Anoubis nicht selbst, ob eine Operation einesProgramms zugelassen werden soll oder nicht. Stattdessen wird das Programm angehal-ten und eine Eskalation erzeugt.

Solche Eskalationen können im GUI angezeigt und im Einzelfall durch den Anwenderentschieden werden. Bis zu einer Entscheidung ist die Anwendung blockiert.

5.1.1 Benachrichtigung über offene Eskalationen

Ob Eskalationen entschieden werden müssen ist in xanoubis links oben im Statusbe-reich zu erkennen. Zusätzlich erscheint das Anoubis-Icon in einem solchen Fall mit einemFragezeichen.

5.1.2 Anzeigen und Entscheiden von Eskalationen

Um Eskalationen zu entscheiden, wählt man aus der Navigationsleiste links im Haupt-fenster den Eintrag Anoubis und anschließend im Hauptfenster den Reiter Nachrichtenaus.

In dem Auswahlmenü oben im Hauptfenster sollte bereits “aktuelle Nachfragen” vorein-gestellt sein. Dadurch werden nur Eskalationen angezeigt, die noch nicht entschiedenwurden. Darunter werden Informationen über die erste Eskalation angezeigt. Mit Hilfe derNavigationspfeile direkt unterhalb des Auswahlmenüs kann zu anderen Eskalationen ge-wechselt werden.

Mit Hilfe der Schaltflächen erlauben oder verbieten kann die Eskalation entschieden wer-den.

Dabei besteht für die meisten Eskalationen die Möglichkeit, eine temporär oder dauerhaftgültige Regel für dieses und ähnliche Ereignisse zu erstellen. Die Gültigkeit der Regel wird

60 5. Betrieb

durch die Auswahlbuttons auf der linken Seite festgelegt. Auf der rechten Seite werdenabhängig vom Ereignis verschiedene Möglichkeiten angeboten, um die erstellte Regelgenauer kontrollieren zu können.

Darüber hinaus kann durch Auswahl der entsprechenden Checkbox erreicht werden, dassunmittelbar nach dem Erstellen der Regel der Regeleditor geöffnet wird. Dabei wird auto-matisch die erste der neu erzeugten Regeln ausgewählt und angezeigt.

Gelegentlich kann es vorkommen, dass nicht alle Möglichkeiten zur Auswahl stehen. Dieskann verschiedene Ursachen haben:

• Für dieses spezielle Ereignis gibt es keine Regelvarianten zur Auswahl. Dies tritt zumBeispiel bei ICMP-Paketen auf.

• Die Regel, die das Ereignis auslöst, befindet sich nicht in dem Block, der zum Kontextder aktiven Anwendung gehört. Dies kann passieren, wenn der Regelsatz kurz zuvor(z.B. durch das Beantworten einer vorangegangenen Eskalation) modifiziert wurde.

5.2 Regelwizard

Der Regelwizard führt durch eine Reihe von Einstellungen, um möglichst einfach neueRegeln anzulegen.

Nachdem die Anwendung ausgewählt wurde, für die Regeln erzeugt werden sollen, wer-den der Reihe nach Einstellungen zum Kontextwechsel, ALF und Sandbox abgefragt.Existieren bereits Regeln für die einzelnen Module, wird nachgefragt, ob sie überschriebenwerden sollen. In diesem Fall wird der existierende Regelblock überschrieben und durchden Wizard neu erstellt. Ansonsten wird die Konfiguration des Moduls übersprungen.

Nach Beendigung des Wizards werden die neuen Regeln im Regeleditor angezeigt. Dortkönnen sie weiter verfeinert und aktiviert werden.

Achtung: Der Wizard kann nicht den Regeleditor ersetzen! Vielmehr stellt er eine Möglich-keit dar, einfach ein solides Grundgerüst zu erstellen. Feinheiten des Regelsatzen müssenim Regeleditor konfiguriert werden. Der Regelwizard ist nicht in der Lage, die kompletteAPN abzubilden.

5.2.1 Regelkonfiguration einer Anwendung mit dem Regelwizard

Das folgende Beispiel zeigt die Konfiguration der Anwendung Lynx unter Zuhilfenahmedes Regelwizards. Hierbei werden in den einzelnen Phasen Regeln für den Kontext, dieALF sowie Sandbox erstellt.

Zu Beginn des Konfigurationslauf begrüßt Sie das Startfenster des Regelwizards. Vonhier aus werden Sie durch die einzelnen Einstellungsmöglichkeiten geführt, die die jeweilsaktuell vorzunehmenden Einstellungen im aktuellen Dialog aufweisen. Dabei gibt Ihnendie linken Seite des Regelwizard-Dialogs stetig Auskunft über die aktuell bearbeitetenEinstellungen (Kontextwechsel, Alf, Sandbox) und etwaige Kontextinformationen (z.B. derName der Anwendung für die Einstellungen vorgenommen werden.) Die Navigation erfolgtüber die Schaltflächen Zurück und Weiter. Über die Schaltfläche Zurück gelangen Sie beiBedarf jederzeit in die vorhergehenden Dialoge des Regelwizards.


5.2. Regelwizard 61

Abbildung 5.1: Regelwizard: Anwendung Lynx wurde zur Konfiguration ausgewählt

Die Auswahl der Anwendung für die mittels des Regelwizards Regeln erstellt werden sol-len, kann durch direkte Eingabe des Pfades im Textfeld oder durch die Schaltfläche Aus-wahl erfolgen.


62 5. Betrieb

Abbildung 5.2: Regelwizard: Einstellungen zum Kontextwechsel

Die Einstellungen zum Kontextwechsel bestimmen welche Berechtigungen Anwendungenhaben, die von der konfigurierten Anwendung - im konkreten Fall Lynx - gestartet werden.So wird zum Beispiel bei der Betrachtung von PDF-Dateien die entsprechende Anwen-dung (z.B. Acrobat Reader) aufgerufen. Der Regelwizard bietet in diesem Zusammen-hang drei mögliche Einstellungen. Programme die von der Anwendung aufgerufen wer-den erhalten die gleichen Berechtigungen/Einschränkungen, die für die Hauptanwendunggelten (ja). Optional können durch das Auswählen der Checkbox Ausnahmen zulassenfeingranulare Einstellungen vorgenommen werden, mit nein erhält jedes aufgerufene Pro-gramm eigene Berechtigungen/Einschränkungen.


5.2. Regelwizard 63

Abbildung 5.3: Regelwizard: Einstellungen zur ALF

Im Folgenden werden ALF-Regeln für die Berechtigung der Anwendung, clientseitigeNetzwerkzugriffe durchzuführen, konfiguriert. Die Auswahl der Option ja erlaubt der An-wendung uneingeschränkten Netzwerkzugriff. Bei Wahl der Option eingeschränkt (Stan-dardwerte) werden vordefinierte Dienste erlaubt, alle weiteren führen zu einer Nachfra-ge beim Benutzer. Mittels der Option eingeschränkt können feingranulare Einstellungenvorgenommen werden. Diese können auf den nächsten Seiten (siehe Abbildung 5.4) ein-gestellt werden. Um der Anwendung, Zugriffe auf das Netzwerk vollständig zu verbieten,wählen Sie die Option Nein (kein Zugriff auf Netzwerkdienste erlauben).


64 5. Betrieb

Abbildung 5.4: Regelwizard: Einschränkungen zur ALF

Wurde die Option eingeschränkt ausgewählt, so können Sie die folgenden Einstellungenzum eingeschränkten Netzwerkzugriff der Anwendung vornehmen. Bei Wahl der Schalt-fläche Standarddienste hinzufügen werden vordefinierte Dienste hinzugefügt, die inder Datei /etc/anoubis/profiles/wizard/alf hinterlegt sind. Mittels der Schaltfläche Hinzu-fügen erhalten Sie Zugriff auf vordefinierte Dienste (Abbildung 5.5) auf Basis der Datei/etc/services.


5.2. Regelwizard 65

Abbildung 5.5: Regelwizard: Einschränkungen zur ALF hinzufügen

Hierbei besteht die Möglichkeit, eigene Dienste zu definieren. Hierzu wählen Sie im Ab-schnitt Einstellung zum kundenspezifischen Dienst den Protokolltyp aus und tragendie Portnummer in numerischer Form ein. Mittels der Schaltfläche eigenen Dienst hinzu-fügen werden diese Einstellungen übernommen.


66 5. Betrieb

Abbildung 5.6: Regelwizard: Startfenster der Sandboxregeln

Der initiale Dialog zur Konfiguration der Sandboxregeln der Anwendung erlaubt die folgen-den Einstellungsmöglichkeiten. Die durch den Wizard geführte Erstellung von Sandbox-regeln mittels der Option Ja, Regeln erstellen. Die Erstellung von Sandboxregeln unterEinbeziehung vordefinierter Berechtigungen durch die Wahl der Option Ja, Regeln ausStandardwerten laden. Möchten Sie keine Sandboxregeln für die Anwendung konfigurie-ren, so wählen Sie die Option Nein, keine Sandboxregeln erstellen.


5.2. Regelwizard 67

Abbildung 5.7: Regelwizard: Leseberechtigung der Anwendung

Die Berechtigungen für den lesenden Dateisystemzugriff der Anwendung können im Fol-genden vorgenommen werden. Der Anwendung wird uneingeschränkter lesender Datei-systemzugriff durch Wahl der Option uneingeschränkt erteilt. Bei Wahl der Option einge-schränkt (Standardwerte) werden vordefinierte Zugriffsrechte eingeräumt, alle weiterenführen zu einer Nachfrage beim Benutzer. Mittels der Option eingeschränkt können fein-granulare Einstellungen für die Anwendung vorgenommen werden. Diese können auf dernächsten Seiten eingestellt werden.


68 5. Betrieb

Abbildung 5.8: Regelwizard: spezifische Leseberechtigung der Anwendung

Wurde die Option eingeschränkt ausgewählt, so können Sie die folgenden Einstellun-gen vornehmen, um die Leseberechtigung der Anwendung einzuschränken. Mittels derSchaltfläche Datei können Sie einzelne Dateien definieren auf die Zugriff gestattet wird.Sie können den Zugriff auf ein ganzes Verzeichnis erweitern, indem Sie die SchaltflächeVerzeichnis auswählen. Bei Auswahl der Schaltfläche Standardberechtigungen werdenvordefinierte Zugriffsrechte festgelegt, die in der Datei /etc/anoubis/profiles/wizard/sb hin-terlegt sind.


5.2. Regelwizard 69

Abbildung 5.9: Regelwizard: Schreibberechtigungen der Anwendung Lynx

Die Berechtigungen der Anwendung hinsichtlich des Schreibzugriffs im Dateisystem kön-nen im Folgenden vorgenommen werden. Die Optionen bieten hierbei die gleichen Unter-scheidungsmöglichkeiten wie die schon beim lesenden Dateisystemzugriff erwähnten.


70 5. Betrieb

Abbildung 5.10: Regelwizard: Ausführberechtigungen der Anwendung

Die Berechtigungen der Anwendung hinsichtlich des ausführenden Dateisystemzugriffskönnen im Folgenden vorgenommen werden. Die Optionen bieten hierbei die gleichenUnterscheidungsmöglichkeiten wie die schon beim lesenden Dateisystemzugriff erwähn-ten.


5.2. Regelwizard 71

Abbildung 5.11: Abschluss der Konfiguration

Nach Abschluss der Konfiguration besteht die Möglichkeit, die erstellten Regeln sofort zuaktivieren. Hierzu muss eine Verbindung zum Anoubis-Daemon bestehen und die Check-box neu erstellte Regeln aktivieren gesetzt sein.


72 5. Betrieb

5.3 LogViewer

Im LogViewer werden Logmeldungen, Alarmmeldungen und Nachfragen dargestellt. DasSymbol am Anfang der Zeile symbolisiert jeweils eine Kategorie von Meldung. Die Zuge-hörigkeit der Meldung ist in der Spalte „Module” angegeben. Nachdem eine Anfrage einerApplikation zu einem Verbindungsaufbau eingegangen ist, erscheint das Anoubis Tray-Icon mit dem entsprechenden Meldungssymbol. Das Symbol in der Menüleiste wird erstnachdem der LogViewer aufgerufen wurde zurückgesetzt.

5.4 RuleEditor

Abbildung 5.12: RuleEditor

5.4.1 Bearbeiten von Regeln

Im RuleEditor können Regeln erstellt, geändert und gelöscht werden. Dieser wird mit derSchaltfläche RuleEditor rechts unten im Anoubis-Hauptfenster gestartet.


5.4. RuleEditor 73

Erstellen von Regeln

Zum Erstellen einer neuen Regel für eine Anwendung wählt man im Drop-Down-Menüoberhalb der linken Liste den Typ der Regel aus. Hier können Applikationsregeln für dieModule ALF, Sandbox und Kontext durch Auswahl der Schaltfläche Erstellen neu erzeugtwerden.Um neue Filterregeln für eine bereits existierende Applikation zu erzeugen, muss die Ap-plikationsregel in der linken Liste ausgewählt werden. In der rechten Liste werden danndie bereits vorhandenen Filterregeln für diese Applikation angezeigt. Außerdem stehen imDrop-Down-Menü über der rechten Liste die zulässigen Arten von Filterregeln zur Aus-wahl. Neue Filterregeln können durch anwählen der zur rechten Liste gehörenden Schalt-fläche Erstellen neu erzeugt werden.Unterhalb der rechten Liste können dann in den einzelnen Reitern die Eigenschaften fürdie aktuell ausgewählte Filterregel eingestellt werden. Welche Reiter angezeigt werden,hängt vom Typ der Filterregel ab.

Ändern von Regeln

Für das Ändern einer Regel muss zunächst eine Regel aus der linken Liste ausgewähltwerden. In den Reitern unterhalb der linken Liste können dann die Anwendungen, für diediese Regel gelten soll, verändert werden. Gleichzeitig werden die einzelnen Filterregelnfür diese Applikation in der rechten Liste angezeigt. Durch Auswahl einer Filterregel wer-den unter der rechten Liste Reiter angezeigt, mit denen die aktivierte Filterregel bearbeitetwerden kann.Um z.B. eine Regel vom ALF Modul zum Firefox zu ändern, muss die zum Firefox zuge-hörige Regel in der linken Regelliste selektiert werden. Anschließend wird in der rechtenListe die entsprechende Filteroption ausgewählt. Der Reiter unterhalb der Liste verändertsich entsprechend der Regel, dort können die gewünschten Änderungen vorgenommenwerden.Wichtig hierbei ist, dass die vorgenommenen Änderungen mittels der Schaltfläche Akti-vieren gespeichert und aktiviert werden müssen, bevor sie tatsächlich aktiv werden.Jeder Regelsatz enthält nur einen SFS-Block, der für alle Anwendungen gleichermaßengilt. Daher wird in diesem Block keine Möglichkeit zur Änderung der Anwendungen unter-halb der linken Liste angeboten.

Löschen von Regeln

Zum Löschen einer Regel wird sie selektiert und anschließend durch die Auswahl derSchaltfläche Entfernen gelöscht. Administratorregeln sowie der SFS-Block können nichtgelöscht werden.

5.4.2 Administratorregeln

Sobald eine Verbindung mit dem Anoubis-Daemon hergestellt wurde, werden im Regel-editor auch die Administratorregeln des aktuellen Benutzers angezeigt. Sie sind in derlinken Liste grau hinterlegt und mit (A) gekennzeichnet.


74 5. Betrieb

Diese Regeln können von einem nicht privilegierten Benutzer nur eingesehen, aber nichtverändert werden. Die zugehörigen Tabs sind daher deaktiviert.

Der Administrator hat die Möglichkeit, Administratorregeln von allen Nutzern anzuzeigenund zu verändern. Dazu muss der gewünschte Nutzer mit Hilfe der Auswahl links oben imRegeleditor ausgewählt werden. Es werden dann die Administratorregeln dieses Benut-zers angezeigt. Diese können wie gewohnt bearbeitet werden.

5.4.3 Speichern und Aktivieren

Im unteren Bereich des Regeleditors befindet sich eine Statusanzeige, sowie einigeSchaltflächen, mit denen Regelsätze aktiviert, geladen und gespeichert werden können.

Die Funktion der einzelnen Schaltflächen ist dabei wie folgt:

Aktivieren Bei Auswahl dieser Schaltfläche wird der aktuell im Regeleditor angezeigteRegelsatz an den Anoubis-Daemon gesendet und dadurch tatsächlich aktiv.

Neuladen vom Daemon Aktualisiert den Regelsatz im Regeleditor, sodass er sicher mitdem im Anoubis-Daemon aktiven Regelsatz übereinstimmt. In aller Regel geschiehtdies automatisch.

Importieren Bietet die Möglichkeit, einen Regelsatz aus einer Datei in den Regeleditorzu laden. Der Regelsatz kann vorher in einem Editor erstellt oder zuvor mit Hilfe desExports gespeichert worden sein.

Export Speichert den aktuell im Regeleditor angezeigten Regelsatz in einer Datei.

5.5 Applikationsregeln

Applikationsregeln legen fest, welche konkreten Filterregeln für eine Anwendung geltensollen. Der Anoubis-Daemon sucht nach den Applikationsregeln einer bestimmten An-wendung und bezieht die mit der Applikationsregel verknüpften Filterregeln in die Ent-scheidung ein. Somit wird sichergestellt, dass man verschiedene Regeln für verschiedeneAnwendungen definieren kann.

5.5.1 Regeleditor

Im Regeleditor werden die Applikationsregeln in der linken Liste angeordnet (siehe Abbil-dung 5.12). Um definieren zu können, welche Art von Filter dieser Regelblock beinhaltet,wird jeder Applikationsregel ein Typ (ALF, SFS, CTX oder SB) zugeordnet.

Folgende Einstellungen können vorgenommen werden:

Bezeichnung Bedeutung


5.5. Applikationsregeln 75

Programm Definiert eine Liste von Anwendungen, für die der Regelblockgelten soll. Es kann mehr als eine Anwendung zu der Liste hin-zugefügt werden. Wurde keine Anwendung angegeben, so giltautomatisch der Wert any, das bedeutet, dass dieser Block ge-nau dann gelten soll, wenn vorher kein passender Regelblockfür eine konkrete Anwendung gefunden wurde.Da SFS-Regeln anwendungsunabhängige Regeln darstellen,können hier keine Anwendungen hinzugefügt werden!

Subject Das Subject definiert die Gültigkeit der Regel in Abhängigkeitzu der Prüfsumme bzw. einer Signatur der dazugehörigen An-wendung. Folgende Einstellungen können hier vorgenommenwerden:

• unabhängig Bei der Auswahl des Regelblocks spielt diePrüfsumme und Signatur keine Rolle.

• Prüfsumme Die Prüfsumme der Anwendung muss mit derim SFS-Browser hinterlegen übereinstimmen.

• Selbst signiert Die Signatur der Anwendung mussmit der Signatur, die der aktuelle Benutzer im SFS-Browser hinterlegt hat, übereinstimmen.

• Uid Die Prüsumme der Anwendung muss mit der, die derBenutzer mit der angegebenen UID im SFS-Browser hin-terlegt hat, übereinstimmen.

• SchlüsselDie Signatur der Anwendung muss mit der Si-gnatur, die der Benutzer mit der angegebenen Schlüssel-ID im SFS-Browser hinterlegt hat, übereinstimmen.

Im aufklappbaren Details-Bereich können zusätzliche Einstellungen vorgenommen wer-den:

Bezeichnung BedeutungSFS deaktivieren Für diese Anwendung wird eine SFS-Ausnahme definiert. De-

tails dazu kann man im Abschnitt 4.4.2 nachlesen.Diese Einstellung kann man ausschließlich in Kontext-Anwendungsregeln (CTX) vornehmen!

Im Playground star-ten

Für diese Anwendung wird eine Playground-Umgebung er-zwungen (siehe Abschnitt 5.9.3).Diese Einstellung kann man ausschließlich in Kontext-Anwendungsregeln (CTX) vornehmen!

Diese Regel nur fürPlaygroundprozesseanwenden

Der Regelblock ist nur dann gültig, wenn der dazugehörendeKontext bereits in einer Playground-Umgebung läuft (siehe Ab-schnitt 5.9.3).Diese Einstellung kann man nicht in Kontext-Anwendungsregeln (CTX) vornehmen!


76 5. Betrieb

5.5.2 Der Prozessbrowser

Mit Hilfe des Prozessbrowsers kann festgestellt werden, welche Regeln von einem Pro-zess tatsächlich verwendet werden. Dies ist vor Allem nützlich, um die Ursache für fehler-hafte Regeln zu finden. Häufig haben diese Ihre Ursache in falsch konfigurierten Kontext-regeln. Bei Bedarf können Regeln dann direkt im Regeleditor bearbeitet werden.

Um den Prozessbrowser zu öffnen, wählen Sie im Modul „Anoubis” den Karteireiter „Pro-zesse” aus.

Abbildung 5.13: Prozessbrowser

Dieser zeigt im oberen Teil eine Liste aller eigenen Prozesse. Hier wird neben einigenallgemeinen Informationen über die Prozesse eine kurze Übersicht über alle für Anoubisrelevanten Informationen zu diesen Prozessen geben.

Detailliertere Informationen zu einem Prozess können im unteren Teil des Fensters an-gezeigt werden. Dazu muss der Prozess ausgewählt werden, für den Details angezeigtwerden sollen.

Um die Liste der Prozesse zu aktualisieren muss die Schaltfläche�� Neu laden ausgewählt

werden. Eine regelmäßige Aktualisierung der Prozessliste findet nicht statt! Die Bedeutungder Spalten in der Prozessliste ist dabei wie folgt:

Spalte BedeutungProzess ID Die Prozess-ID des ProzessesBenutzer Der Benutzer dem der Prozess zugeordnet ist.


5.5. Applikationsregeln 77

ALF, SB und CTX Hier wird angezeigt, ob für den Prozess ALF-, Sandbox- bzw.Kontextregeln aktiv sind. Für einen Prozess kann es jeweilsdurch den Benutzer konfigurierte Regeln sowie vom Admini-strator vorgegebene Regeln geben.

Playground ID Wenn der Prozess in einem Playground läuft, wird hier diePlayground-ID angezeigt. Ansonsten bleibt die Spalte leer.

Command Das Kommando, das dieser Prozess ausführt.

In der unteren Hälfte des Fensters können verschiedene Tabs ausgewählt werden, umdetaillierter Informationen über den aktuell ausgewählten Prozess anzuzeigen.

Details Hier werden allgemeine Informationen über den Prozess an-gezeigt. Dazu gehörten zum Beispiel Prozess-ID und realeund effektive User-ID. Diese Informationen sind nicht Anoubis-spezifisch und werden nur als ergänzende Information an-gezeigt. Sie können auch mit Hilfe des Kommandozeilepro-gramms ps(1) ermittelt werden.

Pfade Hier werden die Pfade und Prüfsummen angezeigt, die dieAuswahl der Applikationsregeln bestimmen. Es werden dreiunter Umständen verschiedene Pfade und Prüfsummen ange-zeigt:

• Pfad und Prüfsumme der Datei, die aktuell durch den Pro-zess ausgeführt wird. Diese Anzeige hat nur informativenCharakter und wird nicht direkt für die Auswahl von Appli-kationsregeln verwendet. Die beiden anderen Pfade stim-men entweder mit diesem überein, oder sie gehören zu ei-nem Vaterprozess, dessen Policy eine Vererbung der Re-geln auf die Kinder erzwungen hat.

• Pfad und Prüfsumme, die für die Auswahl der Applikati-onsregeln aus dem Regelsatz des Benutzers verwendetwerden.

• Pfad und Prüfsumme, die für die Auswahl der Applikati-onsregeln aus dem vom Administrator vorgegebenen Re-gelsatz verwendet werden.

ALF Regeln Hier werden die ALF-Applikationsregeln, die für den ausge-wählten Prozess gelten angezeigt. Im linken Textfeld werdendie vom Benutzer konfigurierten Regeln, im rechten die vomAdministrator vorgegebenen Regeln angezeigt. Durch einenKlick auf die Schaltfläche

�� Bearbeiten... öffnet sich der Re-geleditor mit der angezeigten Regel, so dass diese bearbeitetwerden kann.

SB Regeln Hier werden, analog zu den ALF-Applikationsregeln, die Appli-kationsregeln der Sandbox angezeigt.


78 5. Betrieb

CTX Regeln Hier werden, analog zu den ALF-Applikationsregeln, die fürdas Programm geltenden Kontextregeln angezeigt.

5.6 ALF

5.6.1 Überblick

Das ALF-Modul verwaltet für jeden Benutzer einen Satz von applikationsabhängigen Fire-wallregeln. Zusätzlich gibt es einen Satz an Administratorregeln, welche Vorrang vor denBenutzerregeln haben.

Die ALF filtert alle ein- und ausgehenden Netzwerkverbindungen von Anwendungen undführt die jeweils in entsprechenden Regeln gesetzten Aktionen aus. Hierbei können Ver-bindung zugelassen oder unterbunden werden. Laufende Verbindungen können durch Än-derungen am Regelsatz abgebrochen werden.

5.6.2 RuleEditor

Der Regeltyp „ALF” im RuleEditor, bietet je nach Filterregel folgende Einstellungen:

Bezeichnung BedeutungAktion / Log Angabe der Aktion, die die ALF im Falle der Übereinstimmung

der Filterregel durchführen soll. Hierbei steht „erlauben” fürdas Zulassen der Netzwerkverbindung, „verbieten” für dasUnterbinden der Verbindung und „nachfragen” für eine Rück-frage an den Benutzer.Angabe der Log-Einstellung für die Aktion. Hierbei steht „kein”für das Unterlassen eines Log-Eintrags, „normal” für einennormalen Log-Eintrag und „kritisch” für Alarme.

Netzwerk Angabe der Richtung der zu filternden Netzwerkverbindung.Die ALF unterscheidet zwischen ein- und ausgehenden Ver-bindungen. Die Einstellung „eingehende” gibt an, dass dieRegel auf eingehende Verbindungen angewendet werden soll,„ausgehende” gibt an, dass sie für ausgehende Verbindungenzutrifft.Sowie Angabe der Adressfamilie der zu filternden Netz-werkverbindung. Die Adressfamilie gibt an, ob nur IPv4-Pakete („inet”), nur IPv6-Pakete („inet6”) oder alle Pakete(„unabhängig”) durch die Regel betroffen sind.Und die Angabe des Protokolls der zu filternden Netzwerk-verbindung. Die ALF unterscheidet bei IP-Verbindungen zwi-schen dem Transmission Control Protocol („tcp”), User Data-gram Protocol („udp”) und dem Stream Control TransmissionProtocol („sctp”).


5.7. SFS 79

Adresse Angabe der Quell- und Zielradresse und Quell- und Zielport derzu filternden Netzwerkverbindung. Die Adresse wird in Formeiner IP-Adresse der gewählten Adressfamilie erwartet. Portswerden dezimal in einem Bereich von 1 bis 65535 angegeben.

Capability Angabe für den Filterregeltyp Capability. ALF-Regeln könnenauf Verbindungseigenschaften oder auf angeforderte Privilegi-en angewendet werden. Hier bedeutet „capability”, dasssich die Regel auf angeforderte Privilegien (wie RAW-Sockets)auswirkt, „andere”, dass die Entscheidungsparameter sich aufandere Verbindungstypen auswirkt und „alle” bezieht sich aufalle Verbindungsarten.

5.7 SFS

5.7.1 Überblick

Das SFS-Modul (siehe Abschnitt 4.4) legt Zugriffsregeln anhand von Prüfsummen bzw.Signaturen fest. Es werden Ist- und Soll-Werte miteinander verglichen. Der Ist-Wert ei-ner Prüfsumme wird von Anoubis aktuell berechnet. Er spiegelt den aktuellen Stand einerDatei wieder. Der Benutzer legt seine Soll-Werte fest, die etwas über die Erwartungshal-tung des jeweiligen Benutzers aussagen. Er kann sie komfortabel über den SFS-Browserverwalten.

Bei Zugriff auf eine Datei wird überprüft, ob eine SFS-Regel für sie definiert ist. Die Re-gel legt eine Aktion fest, die abhängig von der Ist- und Soll-Prüfsumme sein kann. Eswird also überprüft, ob der zugreifende Nutzer oder der Administrator für diese Datei einePrüfsumme hinterlegt hat.

Das SFS-Modul verwaltet für jeden Benutzer einen Bestand an Prüfsummen zu Dateienim System. Eine vom Administrator festgelegte Prüfsumme für eine Datei gilt zusätzlichfür alle Benutzer, die für diese Datei keine eigene Prüfsumme festgelegt haben.

5.7.2 RuleEditor

Der Regeltyp SFS im RuleEditor ist in jedem Regelsatz enthalten. Daher kann eine SFSRegel zur linken Liste im RuleEditor nicht hinzugefügt werden. Durch Verbinden mit demAnoubis-Daemon kann ein Regelsatz geladen werden, der eine Regel vom Typ SFS ent-hält. Wenn noch kein Regelsatz geladen ist, wird durch den Import einer leeren Datei oderdurch das Anlegen einer ALF-, Sandbox- oder Kontext-Regel ebenfalls ein neuer Regel-satz erzeugt, der auch einen SFS-Block enthält.

Der Filtertyp SFS bietet folgende Eingstellungsmöglichkeiten:


80 5. Betrieb

Bezeichnung BedeutungGültig/Ungültig/Unbekannt

Angabe der duchzuführenden Aktion im Falle eines gültigenoder ungültigen Ergebnisses einer Validierung oder wenn derZustand der Datei unbekannt ist. Als mögliche Aktion für jedesErgebnis kommen „erlauben”, „verbieten”, „nachfragen”oder „fortführen” in Betracht. Im Falle von fortführen wirddie nächste passende Regel interpretiert.Zudem sind zu den jeweiligen Ergebnissen noch die Anga-ben der Log-Einstellungen möglich. Hierbei steht kein für dasUnterlassen eines Log-Eintrags, „normal” für einen normalenLog-Eintrag und „kritisch” für Alarme.

Subject Angabe über den Pfad zur Datei und deren Subject. Fürdie „Eigene Prüfsumme” als Subject wird die eigene Prüf-summe zur Überprüfung aus dem SFS-Modul herangezo-gen. Im Falle von „Selbst Signiert” wird die eigene imSFS-Modul hinterlegte Signatur zur Validierung herangezo-gen. Im Falle einer „uid” muss eine gültige UID angege-ben werden, die eine Prüfsumme hinterlegt hat. Diese Prüf-summe wird dann zur Überprüfung herangezogen. Im Fallevon „Schlüssel” wird eine Schlüssel-ID angegeben, die ei-ne Signatur für diese Datei im SFS-Modul hinterlegt hat. EinSubject einer KeyID sollte dann folgender Form entsprechen85326181333deb31f8711b7cd6da563273100812

5.7.3 Einführung in den SFS-Browser

Der Browser (Abbildung 5.14) wird verwendet, um die Soll-Werte von Prüfsummen desangemeldeten Benutzers zu verwalten. Zusätzlich kann ein privater Schlüssel und dasdazugehörige Zertifikat hinterlegt werden, um das Signieren der Prüfsummen aktivierenzu können. Hinweise zur Konfiguration sind im Kapitel 5.7.4 zu finden.

Der Browser zeigt eine Liste von lokalen Dateien an. Im Verzeichnis-Baum kann dasBasisverzeichnis ausgewählt werden.

Unter Ansicht kann eingestellt werden, welche Dateien angezeigt werden. Folgende Aus-wahlmöglichkeiten werden angeboten:

• Standard Dateiansicht Alle lokalen Dateien.

• Dateien mit Prüfsumme Nur Dateien mit registrierten Prüfsummen.

• Veränderte Dateien Ausschließlich Dateien, deren aktuellen Prüfsummen sichvon den registrierten Prüfsummen unterscheiden.

• Verwaiste Prüfsummen Dateien mit registrierten Prüfsummen, die aber lokal nichtmehr existieren.

• Durch ein Upgrade veränderte Dateien Dateien, die durch einBetriebssystem-Upgrade verändert, aber deren Signaturen noch nicht aktuali-siert wurden. Details sind im Abschnitt 5.12.1 zu finden.


5.7. SFS 81

Abbildung 5.14: SFS Browser

Durch das Aktivieren der Option Rekursiv wird die Ansicht zusätzlich auf alle Unterver-zeichnisse ausgeweitet. Um die aufgelisteten Dateien nach einem Namen zu filtern, kanndas Eingabefeld Filter benutzt werden. Mit Invertieren wird die Anzeige invertiert.

5.7.4 Schlüssel

Das Signieren von Prüfsummen und Policies sowie die Client-Autorisierung benötigt einSchlüsselpaar, das im Tab Schlüssel (siehe Abbildung 5.15) konfiguriert wird. Um eineSignatur zu erstellen, wird der private Schlüssel verwendet. Das Zertifikat wird benötigt,um Signaturen zu verifizieren.

Es werden Standard-Pfade für das Schlüsselpaar fest vorgegeben.

• Privater Schlüssel $HOME/.xanoubis/default.key

• Zertifikat $HOME/.xanoubis/default.crt

Der Benutzer hat die Möglichkeit, sich sein Schlüsselpaar über den Button�� Erzeuge Schlüsselpaar zu erzeugen (siehe Abbildung 5.16). Der Dialog erlaubt den Be-nutzer, den Speicherort der Schlüsseldateien und Details des Zertifikatsinhabers anzuge-ben.

Achtung: Das Zertifikat muss zusätzlich dem Anoubis-Daemon bekannt gemacht werden.Details dazu befinden sich im Kapitel 4.7.


82 5. Betrieb

Abbildung 5.15: SFS Schlüssel

5.7.5 Prüfsumme validieren

Die Dateiliste zeigt den Namen der Datei und den Status der Prüfsumme und der Signaturan.??? Es wurde noch keine Validierung durchgeführt.nicht registriert Am Anoubis-Daemon ist keine Prüfsumme/Signatur registriert.verwaist Für die Datei wurde eine Prüfsumme hinterlegt, die Datei existiert

aber nicht (mehr).

ungültig Die Prüfsumme/Signatur ist ungültig.

Die am Anoubis-Daemon registrierte Prüfsumme stimmt nicht mitder lokal berechneten Prüfsumme überein.

Die am Anoubis-Daemon registrierte Prüfsumme stimmt mit derlokal berechneten Prüfsumme überein.

Die Prüfsummen aller angezeigter Dateien werden durch Überprüfen (alle) validiert.Wählt man in der Combobox Aktuelle Auswahl die Option Überprüfen aus, dann führtAnwenden die Operation ausschließlich auf den selektierten Dateien aus. Ist ein gültigesSchlüsselpaar hinterlegt, wird zusätzlich zu den Prüfsummen die Signaturen überprüft.

5.7.6 Prüfsumme anzeigen

Ein Doppelklick auf eine Datei zeigt ausgewählte Details.

• Pfad der Datei


5.7. SFS 83

Abbildung 5.16: Schlüsselpaar erzeugen

• Linkziel, wenn ein symbolischer Link angezeigt wird

• Änderungsdatum und -uhrzeit

• Lokal berechnete Prüfsumme

• Am Anoubis-Daemon registrierte Prüfsumme

• Status der Prüfsumme

• Status der Signatur

Der Dialog ist zusätzlich über das Kontextmenü erreichbar.

5.7.7 Prüfsumme hinzufügen

In der Combobox Aktuelle Auswahl ist die Option Registrieren zu wählen. Anwen-den wird nun für alle selektierten Dateien die Prüfsumme berechnen und am Anounbis-Daemon registrieren.

Ist ein gültiges Schlüsselpaar hinterlegt, wird die Prüfsumme zusätzlich signiert. Die somitentstandene Signatur wird ebenfalls am Anoubis-Daemon registriert.

Ist die ausgewählte Datei ein symbolischer Link, dann wird die Prüfsumme über den Linkberechnet. Soll zusätzlich der Dateiinhalt gesichert werden, dann muss ebenfalls die Prüf-summe über die verlinkte Datei registriert werden. Um sie komfortabel zu erreichen, bietetdas Kontextmenü den Eintrag Springe zu Link-Ziel an.


84 5. Betrieb

5.7.8 Prüfsumme entfernen

In der Combobox Aktuelle Auswahl ist die Option Registrierung aufheben zu wählen.Mit Anwenden werden nun die registrierten Prüfsummen für alle selektieren Dateien amAnoubis-Daemon entfernen.

Ist ein gültiges Schlüsselpaar hinterlegt, dann wird zusätzlich die Signatur, die mit diesemSchlüsselpaar erstellt wurde, entfernt.

5.7.9 Erweiterte Operationen

Der Bereich Details verbirgt eine Reihe von zusätzlichen Operationen.

Die Checkbox Signiere Dateien steuert das Signieren von Prüfsummen. Das Signierenkann ausgeschaltet werden, obwohl ein gültiges Schlüsselpaar hinterlegt ist.

Importieren... importiert Prüfsummen/Signaturen aus einer Datei, Exportieren... schreibtsie in eine Datei zurück. Es ist auf ein korrektes Daten-Format zu achten! Details sind imAnhang C zu finden.

5.8 Sandbox

5.8.1 Überblick

Das Sandbox-Modul verwaltet für jeden Benutzer einen Satz von applikationsabhängigenZugriffsregeln. Zudem existiert ein Satz an Administratorregeln, welche Vorrang vor denBenutzerregeln haben.Die Sandboxregeln verwalten den Zugriff bestimmter Programme auf Dateien.

5.8.2 RuleEditor

Der Regeltyp „SB” bietet für Sandbox-Regeln im RuleEditor folgende Einstellungsmöglich-keiten:

Bezeichnung BedeutungAktion/Log Angaben hinsichtlich der Aktion, die das Sandbox-Modul

im Falle einer Übereinstimmung einer Regel durchführensoll. Hierbei steht „erlauben” für das Zulassen der Aktion,„verbieten” für das Unterlassen der vom Programm ge-wünschten Aktion und „nachfragen” für eine Rückfrage anden Benutzer.


5.9. Playground 85

Subject Angabe über den Pfad zur Datei und deren Subject. Im Text-feld Pfad können Datei- und Verzeichnisnamen angegebenwerden. Über den Button Auswählen kann ein Dateiaus-wahldialog geöffnet werden um den Dateinamen festzulegen.Ein Rechtsklick auf den Auswählen-Button ermöglicht es,stattdessen einen Verzeichnisauswahldialog zu erhalten. Wird„unabhängig” als Subject angegeben, so trifft die Datei, dieim Pfad steht, ohne Berücksichtigung der Prüfsumme zu. Fürdie „Eigene Prüfsumme” als Subject wird die eigene Prüf-summe zur Überprüfung aus dem SFS herangezogen. Im Fal-le von „Selbst Signiert” wird die eigene - im SFS hinter-legte - Signatur zur Validierung herangezogen. Im Falle einer„uid” muss die gültige UID eines Benutzers angegeben wer-den, der eine Prüfsumme für diese Datei hinterlegt hat. Die-se Prüfsumme wird dann zur Überprüfung herangezogen. ImFalle von „Schlüssel” wird eine Schlüssel-ID angegeben, dieeine Signatur für diese Datei im SFS hinterlegt hat. Für die„Prüfsumme” als Subject wird die angegebene Prüfsumme zurÜberprüfung herangezogen.

Zugriffsrechte Angaben zu den Zugriffsrechten, die das Sandbox-Modul imFalle einer Übereinstimmung einer Regel gewähren soll. Hier-bei steht „lesen” für lesenden Zugriff, „schreiben” für schrei-benden Zugriff und „ausführen” erteilt Zugriff zur Ausführung.

5.9 Playground

Ein Playground bietet Ihnen die Möglichkeit eine Applikation in einer Ablaufumgebungmit einem virtuellen Dateisystem auszuführen. Schreibzugriffe in dieses Dateisystem wer-den transparent abgefangen und sind nur für diese Applikation sichtbar. Auf Wunschkönnen nach Beendigung der Applikation einzelne Dateien vom Playground in das rea-le Dateisystem übernommen werden. Dabei kann der Administrator die Verwendung vonInhaltsscannern erzwingen.

Playgrounds bieten Ihnen Schutz vor unerwünschten Veränderungen am Lokalen Datei-system ohne der Applikation das Schreiben komplett zu verbieten. Durch den Einsatz vonInhaltsscannern ist eine kontrollierte Übernahme von Dateien aus einer unsicheren Umge-bung möglich. Dieser Schutzmechanismus eignet sich gut zur Absicherung von Browsern.

5.9.1 Grundlagen

Applikationen können auf verschiedenen Wegen in einem Playground gestartet werden.Neben dem durch Regeln erzwungenen Start existiert die Möglichkeit, beliebige Appli-kationen manuell in einem Playground zu starten. Beide Möglichkeiten werden in dennächsten Abschnitten detailliert vorgestellt.


86 5. Betrieb

Durch das Starten einer Applikation im Playground wird dieser im Daemon angelegt. DerPlayground enthält den ursprünglichen Prozess und gegebenenfalls seine Kindprozes-se. Bei schreibendem Zugriff auf das Dateisystem werden die Änderungen nicht sofort indas eigentliche System (Produktivsystem) übernommen. Stattdessen werden die Ände-rungen separat abgespeichert und über den Playground referenziert. Die vom Playgroundgeschriebenen Dateien bleiben auch nach dem Beenden der Playground-Prozesse beste-hen.

Der Benutzer muß nun manuell entscheiden, ob bzw. welche der Dateien er in das Pro-duktivsystem übernehmen will. Verbleibende Dateien im Playground müssen manuell auf-geräumt werden. Playgrounds ohne Dateien werden automatisch entfernt.

Die zu übernehmenden Dateien werden automatisch von konfigurierten Inhaltsscannernuntersucht. Dadurch kann die Übernahme von Viren oder anderen schädlichen Inhaltenins Produktivsystem verhindert werden.

5.9.2 Manuelles Starten von Applikationen im Playground

Wählen Sie das Modul Playground aus, um eine Applikation manuell in einem Playgroundzu starten. Im oberen Teil des Fensters erlaubt der Bereich Neuer Playground die Einga-be des Kommandos. Durch einen Klick auf den Button Starte Playground starten Sie dasausgewählte Kommando in einem Playground. Zusätzlich zum Kommando können Sieeventuelle Optionen angeben. Wird kein absoluter Pfad angegeben, so gelten die Such-pfade von xanoubis.

Abbildung 5.17: Manuelles Starten einer Applikation im Playground


5.9. Playground 87

Playgroundumgebung für X11 Anwendungen

Wenn Sie eine X11 Anwendung im Playground starten, dann wird empfohlen, die OptionProgramm in einer isolierten X Sitzung starten auszuwählen. In diesem Fall wird für dasProgramm eine eigene X11 Sitzung in einem Fenster gestartet. In dieser läuft dann dasPlayground Programm isoliert von der übrigen X11 Umgebung. Dadurch ist einfach zuerkennen, welche Fenster zu welchem Playground gehören.

Allerdings ist die Größe der X11 Umgebung auf 1024x768 Pixel festgelegt und kann späternicht mehr verändert werden.


88 5. Betrieb

5.9.3 Regelbasiertes Starten von Applikationen im Playground

Neben dem manuellen Start einer Applikation im Playground kann der Start einer Applika-tion im Playground durch eine Kontextregel erzwungen werden. Damit wird die im Kontextangegebene Applikation immer in einem Playground gestartet. Die Regel kann vom Be-nutzer angelegt oder vom Administrator vorgegeben werden.

Starten Sie, um eine ensprechende Regel anzulegen, den Regeleditor. Der folgende Ab-schnitt geht davon aus, daß bereits eine Kontext-Regel für diese Applikation existiert. Istdies nicht der Fall, so nutzen Sie am besten den Regelwizard um einen Satz an Grund-regeln anzulegen. Suchen Sie in der Liste der Regeln die Regel vom Typ CTX für IhrProgramm und selektieren Sie die Regel.

Abbildung 5.18: Regel zum automatischen Starten einer Applikation im Playground


5.9. Playground 89

Im unteren Teil des Fensters wird nun der Inhalt der selektierten Regel dargestellt. Öff-nen Sie den Abschnitt Details und aktivieren Sie den Haken Im Playground starten. Diegewählte Applikation wird nun immer in einem Playground gestartet.

Bei jedem Start der Applikation werden Sie von Anoubis über den automatischen Startdes Playgrounds benachrichtigt. Diese Nachricht wird als Anoubis-Alarm versandt underscheint im Tray-Icon:

Durch öffnen von Anoubis erhalten Sie detaillierte Informationen zu dem Alarm.

Abbildung 5.19: Meldung des Daemons bei automatisch angelegten Playgrounds


90 5. Betrieb

5.9.4 Arbeiten in Playgrounds

Sie können mit einer Applikation im Playground ganz normal arbeiten. Alle Dateien desProduktivsystems sind, sofern von der Sandbox zugelassen, les- und schreibbar. AlleSchreibzugriffe werden von Anoubis in den Playground umgeleitet. Dies ist für die Ap-plikation transparent. Applikationen müssen also nicht an Anoubis angepasst werden, umin einem Playground zu laufen.

Es existiert jedoch ein Spezialfall, in dem Anoubis den Schreibzugriff nicht in den Play-ground umleiten kann. Das Umbennenen von Verzeichnissen muss immer direkt im Pro-duktivsystem stattfinden. Die Entscheidung ob diese Umbenennung durchgeführt werdendarf, wird als Eskalation an Sie weitergegeben.

Abbildung 5.20: Eskalation beim Umbenennen von Verzeichnissen

Im Gegensatz zu anderen Eskalationen kann hierbei keine automatische Regel angelegtwerden. Die Entscheidung muß immer manuell getroffen werden.


5.9. Playground 91

5.9.5 Auflisten von Playgrounds

Sie können zu jeder Zeit die gerade existierenden Playgrounds anzeigen. Wählen Siedazu das Modul Playground. Im unteren Teil des Fensters erscheint nun unter dem PunktPlayground Übersicht die Liste aller im System verfügbaren Playgrounds. Die Liste wirdnicht automatisch aktualisiert. Bei Bedarf können Sie die Liste mit dem Button Ansichtaktualisieren neu erstellen.

Ihre eigenen Playgrounds sind schwarz dargestellt und enthalten vollständige Informatio-nen zu den enthaltenen Dateien. Playgrounds die zusätzlich durch ein kleines Ausrufe-zeichen markiert sind, sind inaktiv und wartet auf Bearbeitung. Das Übernehmen oderLöschen von Dateien ist nur für inaktive Playgrounds möglich. Die Playgrounds andererBenutzer können nicht manipuliert werden und sind grau dargestellt.

Abbildung 5.21: Liste der Playgrounds


92 5. Betrieb

Für alle eigenen Playgrounds können Sie zusätzlich die Liste der geschriebenen Datei-en anzeigen. Wählen Sie dazu den Eintrag aus und aktivieren Sie den Button Dateienübernehmen. Alternativ können Sie die Dateiliste auch durch einen Doppelklick auf denPlayground öffnen.

Abbildung 5.22: Dateiliste eines Playgrounds

Die Dateiliste zeigt alle von einem Playground geschriebenen Dateien und Verzeichnisse.Einträge mit mehreren Dateien in einer Zeile stehen dabei für Hardlinks.


5.9. Playground 93

5.9.6 Übernehmen von Dateien aus einem Playground

Sind alle Prozesse eines Playgrounds beendet, so müssen die Dateien dieses Play-grounds entweder übernommen oder gelöscht werden.

Wechseln Sie zum Übernehmen von Dateien in die Dateiliste des Playgrounds. WählenSie die zu übernehmenden Dateien aus und drücken Sie Dateien übernehmen. Die ausge-wählten Dateien werden nun von den Inhaltsscannern überprüft und ins Produktivsystemübernommen. Inhaltsscanner werden systemweit vom Administrator vorgegeben und kön-nen entweder empfohlen oder erforderlich sein.

Stuft ein Scanner eine der zu übernehmenden Dateien als gefährlich ein, so hängt dasweitere Vorgehen von der Art des Scanners ab. Ist der Scanner als erforderlich (requi-red) konfiguriert, so ist ein Übernehmen der Datei nicht möglich. Ein Dialog informiert Sieentsprechend.

Ist der Scanner jedoch nur empfohlen, so bietet Ihnen Anoubis in einem Dialogfenster an,das Ergebnis des Inhaltsscanners zu ignorieren. Sie können die Datei also trotz Warnungübernehmen.

Abbildung 5.23: Ergebnismeldung zu Inhaltsscannern

Sollte die zu übernehmende Datei im Produktivsystem bereits existieren, werden Sie vonAnoubis gefragt, ob die Datei überschrieben werden soll.


94 5. Betrieb

5.9.7 Löschen von Dateien aus einem Playground

Dateien die nicht übernommen werden sollen, müssen gelöscht werden. In der Dateilistekönnen Sie dazu, analog zum übernehmen von Dateien, den Button Löschen verwenden.

Alternativ können Sie alle Dateien eines Playgrounds komplett löschen. Wählen Sie dazuin der Liste der Playgrounds den zu löschenden Playground und drücken Sie Löschen.

Gelöschte Dateien werden dabei natürlich nur aus dem Playground entfernt. Das Produk-tivsystem bleibt erhalten. Sobald alle Dateien übernommen oder gelöscht sind, wird derPlayground automatisch entfernt.

5.10 Profile

Regelsätze können in verschiedene Profile abgelegt werden. Somit ist es möglich, dieAnoubis-Sicherheitseinstellungen flexibel zu wechseln.

Beispiele:

1. Ein Laptop steht an einem Arbeitsplatz in einer gesicherten Netzwerkumgebung. DieDienste des Netzwerkes sind alle vertrauenswürdig.

2. Der Mitarbeiter unternimmt eine Dienstreise und möchte am Flughafen über ein offe-nes WLAN seine E-Mails abrufen. Das Netzwerk ist nicht gesichert und angeboteneDienste sind als nicht vertrauenswürdig einzustufen.

Die Anforderungen an die Anoubis-Regelsätze sind in beiden Beispielen sehr unterschied-lich. Der Anoubis-Benutzer oder -Administrator kann Regelsätze für unterschiedliche Ein-satzszenarien definieren und jeweils in ein Profil ablegen. Später, wenn ein Wechsel derRegelsätze nötig ist (in diesem Beispiel: der Mitarbeiter verlässt sein Büro und erreicht denFlughafen), sollte der Nutzer das entsprechende Profil manuell wechseln. Die Anoubis-Sicherheitseinstellungen ändern sich dementsprechend.

5.10.1 Einführung in den Profil Editor

Abbildung 5.24 zeigt den Profil Editor. Hier können Profile verwaltet und aktiviert werden.Es wird eine Liste mit allen bekannten Profilen angezeigt.

Es existieren zwei Arten von Profilen:

1. Systemweit sichtbare Profile. Sie sind schreibgeschützt und demnach alsschreibgeschützt gekennzeichnet. Ein Administrator hat damit die MöglichkeitProfile vorzugeben und sie den Benutzern zur Verfügung zu stellen.

2. Benutzerspezifische Profile. Sie dürfen von dem Benutzer beliebig editiert werdenund sind nur für ihn sichtbar.

Anoubis stellt eine Reihe von Standard-Profilen zur Verfügung:

• medium Versucht ein Mittelmaß zwischen Benutzbarkeit und Sicherheit herzustellen.

• high Gegenüber dem medium-Profil besteht ein verstärkter Fokus auf der Sicherheit.


5.10. Profile 95

Abbildung 5.24: Profil Editor

• admin Es werden keine zusätzlichen Einschränkungen gegenüber den Admin-Regeln getroffen.

Achtung: Die ausgelieferten Standard-Profile dienen ausschließlich als Vorlage! Sie müs-sen auf jeden Fall für den konkreten Einsatz angepasst werden.

5.10.2 Laden eines Profils

Das selektierte Profil wird durch Aktivieren am Anoubis-Daemon aktiviert und ist damitsofort wirksam.

5.10.3 Erzeugen und Aktualisieren eines Profils

Ein bereits vorhandenes Profil wird mittels Laden in den Regeleditor geladen. Dort kannes beliebig editiert werden (siehe Abschnitt 5.4). Später kann der so modifizierte Regelsatzmit Speichern wieder in ein Profil abgelegt werden. Wird dabei ein bereits existierendesProfil ausgewählt, so wird es überschrieben. Ansonsten wird es neu angelegt, und eserscheint in der Profil-Liste.

Achtung: Ein schreibgeschütztes Profil kann nicht überschrieben werden!


96 5. Betrieb

5.10.4 Löschen eines Profils

Löschen löscht das selektierte Profil. Die Lösch-Operation hat keinerlei Auswirkungen aufdie am Anoubis-Daemon aktiven Regeln!Achtung: Ein schreibgeschütztes Profil kann nicht gelöscht werden!

5.11 Versionskontrolle

Abbildung 5.25: Versionskontrolle

Änderungen an Regelsätzen gehen nicht verloren. Sie werden automatisch in einemBackup archiviert. Eine neue Version wird erstellt, wenn:

• ein Regelsatz zum Anoubis-Daemon gesendet bzw.

• ein Regelsatz in einem Profil gesichert wurde.

Um die Historie des aktiven Regelsatzes einzusehen, ist der Radiobutton Aktive Regelauszuwählen. Regel aus Profil zeigt die Versionen des ausgewählten Profils.

5.11.1 Version wiederherstellen

Die Version, die wiederhergestellt werden soll, wird in der Liste selektiert. Mit Wiederher-stellen wird diese Version im Regeleditor angezeigt.Achtung: Die so wiederhergestellte Version wird nicht automatisch am Anoubis-Daemonaktiviert! Dies muss manuell erfolgen.


5.12. Upgrade 97

5.11.2 Version exportieren

Die selektierte Version kann in eine Datei exportiert werden, indem Exportieren ... aus-gewählt wird.

5.11.3 Version löschen

Es ist möglich, eine Version zu löschen. Sie wird selektiert und anschließend mit Löschengelöscht.

Achtung: Die letzte Version kann nicht gelöscht werden!

5.12 Upgrade

Ein Upgrade ist als Aktualisierung von Paketen des darunterliegenden Betriebssystemsdefiniert.

Das Problem, welches bei einem solchen Upgrade entsteht ist folgendes.

Anoubis verwaltet Prüfsummen von Dateien. Diese Prüfsummen werden unter anderemin Policy-Entscheidungen miteinbezogen. So kann man sogar den Zugriff auf eine Dateikomplett sperren, wenn die aktuelle Prüfsumme nicht mit der im Anoubis- Hintergrundsy-stem hinterlegten Prüfsumme übereinstimmt. Wird nun eine Datei durch die Aktualisierungeines Paketes geändert, so ändert sich dadurch nicht automatisch die von Anoubis ge-speicherte Prüfsumme. Somit kann Anoubis den Zugriff auf ganze Applikationen sperren,obwohl das durch den Benutzer gar nicht gewollt ist. Er hat nämlich wissentlich eine neue,verifizierte Programmversion eingespielt, deren Prüfsumme Anoubis zu diesem Zeitpunktnoch nicht bekannt ist. Das erwartete Ergebnis solch einer Installation ist dagegen, dassdas Betriebssystem mit all seinen installierten Applikationen weiterhin funktioniert. DerAnoubis- Prüfsummenbestand muss demnach automatisch nach einer Paket-Installationangepasst werden.

Dieses Problem wird mit Hilfe des folgenden Vorgangs behoben:

Der Daemon des Anoubis-Systems erkennt selbstständig den Beginn und das Ende einesInstallationsvorgangs. Das kann das Sperren bzw. Entsperren einer Datei oder auch dasStarten bzw. Beenden eines Prozesses sein. In dieser Zeitspanne werden alle Schreibzu-griffe des ausführenden Prozesses und seiner Kinder abgefangen, und die modifiziertenDateien werden in einer Liste einsortiert. Ist der Installationsprozess abgeschlossen, wirddie Datei-Liste mit dem Anoubis-Prüfsummenbestand abgeglichen. Für jede dieser Datei-en, die vor dem Upgrade eine Prüfsumme hatte, wird abschließend eine neue Prüfsummeberechnet und in den Anoubis-Prüfsummenbestand übernommen.

Start und Ende des Upgrade-Vorgangs sind sehr stark von der Distribution abhängig. DieFrage ist, welchen Paketmanager eine Distribution verwendet. Deshalb müssen die Ereig-nisse, welche ein Upgrade auslösen, möglichst genau konfiguriert und mit dem Paketma-nager abgestimmt werden. Details dazu finden Sie im Abschnitt 4.9.


98 5. Betrieb

5.12.1 Benutzer-Signaturen

Nach einem Upgrade kann Anoubis die signierten Prüfsummen eines Benutzers nichtanpassen, da hierfür der private Schlüssel benötigt wird. Der Benutzer wird allerdingsvon Xanoubis darauf hingewiesen, welche von ihm signierten Dateien von dem Upgrade-Prozess verändert wurden (siehe Abbildung 3.9). Er kann im SFS-Browser die veränder-ten Dateien mit der Ansicht Durch ein Upgrade veränderte Dateien auswählen und ak-tualisieren. Details sind im Abschnitt 5.14 zu finden. Darüber hinaus ist sfssig ebenfalls inder Lage, vom Upgrade veränderte Dateien aufzulisten und die Prüfsummen anzupassen(siehe Abschnitt 4.1.2).

5.12.2 Administrator-Signaturen

Anoubis unterstützt ein automatisches Aktualisieren von root-Signaturen. Dazu muss derprivate Schlüssel von root über den rootkey-Parameter konfiguriert werden (siehe Ab-schnitt 4.9.2). Ist der Schlüssel mit einer Passphrase geschützt, dann muss sie vor demUpgrade mittels anoubisctl passphrase zur Verfügung gestellt werden. anoubisdverwendet den entschlüsselten, privaten Schlüssel, um existiernde root-Signaturen auto-matisch zu aktualisieren. Nach Beendigung der Upgrade-Prozedur werden Schlüssel undPassphrase wieder aus dem Speicher entfernt.

5.13 Authorisierung

Der Anoubis-Daemon kann verlangen, dass sich die Clients mit einem kryptografischenChallenge-Response-Verfahren gegenüber dem Daemon authorisieren. Nur wenn sichder Client mit dem korrekten Schlüssel ausweisen kann, wird der Daemon die Verbin-dung akzeptieren. Ob der Daemon eine Client-Authorisierung verlangt, wird global für denDaemon-Prozess konfiguriert. Details sind im Abschnitt 4.9.3 zu finden.

Das für die Verbindung benutzte Schlüsselpaar wird in den SFS-Optionen (Abschnitt 5.7.4)eingestellt.

Die Kommandozeilentools anoubisctl und sfssig lesen standardmäßig$HOME/.xanoubis/default.crt (Zertifikat) und $HOME/.xanoubis/default.key

(privater Schlüssel). Ein anderes Schlüsselpaar läßt sich mit den Optionen -c und -k

einstellen.

Der Anoubis-Daemon lehnt die Verbindung ab, wenn er eine Client-Authorisierung verlangtund der Client kein oder ein falsches Zertifikat verwendet.


LOGGING

• Ereignisarten

• Logviewer

• Application Level Firewall /ALF

• Sandbox / SB

• Sicheres Filesystem / SFS

Kapitel 6

Logging

Dieses Kapitel befasst sich mit Ereignissen, die während des Betriebs von Anoubis auftre-ten können. Diese Ereignisse werden im GUI dargestellt. Falls ein Ereignis eine Entschei-dung des Anwenders erfordert (z.B. zulassen oder verbieten), erfolgt dies ebenfalls überdas GUI.

6.1 Übersicht über die Ereignisarten

Es gibt verschiedene Arten von Ereignissen, die unterschiedlich dargestellt und bearbeitetwerden können.

Eskalation Bei einer Eskalation, kann eine Aktion eines Programms, wie etwa ein Zu-griff auf das Netzwerk, zugelassen oder verhindert werden. Das betroffene Programmwird blockiert, bis die Eskalation entschieden wurde.

Beispiel: Die Anwendung Firefox möchte eine Verbindung zu www.example.com auf-bauen.

Alarmmeldung Eine Alarmmeldung informiert über wichtige Ereignisse, die mögli-cherweise eine ordnungsgemäße Funktion des Systems gefährden können. Wennneue Alarmmeldungen vorliegen, erscheint das Anoubis-Icon mit einem Ausrufezei-chen.

Beispiel: Das GUI konnte sich nicht mit dem Anoubis-Daemon verbinden.

Logmeldung Eine Logmeldung enthält Informationen von untergeordneter Bedeu-tung, die keine unmittelbare Aufmerksamkeit erfordern. Solche Meldungen werdenprotokolliert und können vor allem bei der Diagnose von fehlerhaftem oder unerwar-tetem Verhalten des Systems hilfreich sein.

Beispiel: Der Aufbau einer Netzwerkverbindung wurde auf Grund einer entsprechen-den Regel ohne Nachfrage zugelassen.

Die angezeigten Icons für die einzelnen Arten von Ereignissen werden auch im Logviewerzur Unterscheidung verwendet.

102 6. Logging

Abbildung 6.1: Log Viewer

6.2 Logviewer

Der Logviewer zeigt Eskalationen, Alarmmeldungen und Logmeldungen an.

6.2.1 Öffnen des Logviewers

Der Logviewer kann mit Hilfe des entsprechenden Buttons rechts unten in der Fußleistedes Hauptfensters geöffnet und geschlossen werden.Alternativ kann auch aus dem Menü Werkzeuge der Eintrag LogViewer zum Öffnen undSchließen des Logviewers verwendet werden.Wird der Logviewer geöffnet erscheint das in Abbildung 6.1 dargestellte Fenster. JedeZeile repräsentiert eine Logmeldung. Die Bedeutung der einzelnen Spalten ist wie folgt:

• In der ersten Spalte wird ein Icon angezeigt, das den Typ der Meldung symbolisiert.

• Die zweite Spalte gibt an, wann das Ereignis eintrat.

• Die dritte Spalte zeigt an, welches Modul das Ereignis ausgelöst hat.

• Die letzte Spalte enthält Details über das Ereignis. Die hier angezeigten Informationenhängen in weiten Teilen vom Modul ab, das das Ereignis ausgelöst hat.

Klickt man auf eine Meldung im Logviewer, wird automatisch der Regeleditor geöffnet unddie Regel selektiert, die diese Meldung ausgelöst hat.

6.2.2 Ergebnis eines Ereignisses

Die Details eines Ereignisses enthalten unabhängig vom konkreten Modul eine Informationdarüber, wie das Ereignis entschieden wurde. Die Möglichkeiten sind:


6.3. ALF 103

• Das Ereignis wurde erlaubt.

• Das Ereignis wurde verboten.

• Es wurde beim Benutzer nachgefragt. In diesem Fall wird nach der Beantwortungdurch den Nutzer eine weiterer Eintrag im Logviewer erzeugt, der das endgültigeErgebnis enthält.

Achtung: Ein Ereignis, das von Anoubis erlaubt wurde, kann immer noch aus anderenGründen fehlschlagen, z.B. weil der Zielrechner einer Netzwerkverbindung nicht erreich-bar ist.

6.2.3 Konfiguration

Viele Ereignisse erzeugen nur dann Meldungen, wenn für das Ereignis eine Regel konfi-guriert ist, die das Erzeugen von Meldungen vorschreibt. Die Regel kontrolliert dann, dieArt des Ereignisses, das erzeugt wird.

• Eine Regel, die mit ASK markiert ist, erzeugt eine Eskalation. Ob das zugehörigeEreignis zugelassen wird hängt dann von der Beantwortung dieser Eskalation ab.Die Eigenschaft ASK kann im Regeleditor eingestellt werden.

• Eine Regel kann unabhängig von ihrer Aktion auch noch mit LOG oder ALERT mar-kiert werden. Wenn eine solche Regel Anwendung findet, dann wird (unabhängig voneiner eventuell zusätzlich erzeugten Eskalation) eine Log- oder Alertmeldung erzeugt.

Die Loggingeigenschaften einer Regel können im Regeleditor im rechten Fenster imKarteireiter Aktion/Log verändert werden.

6.2.4 Speicherung von Log-Meldungen

Alle durch eine Regel mit dem Attribut LOG oder ALERT ausgelösten Log-Meldungenwerden auch über den syslog Mechanismus des Betriebssystems protokolliert und inden dort konfigurierten Log-Dateien gespeichert. Die Konfiguration dieses Mechanismuserfolgt über syslog.conf(5). Dabei wird die facitility LOG_DAEMON verwendet.Meldungen mit dem Attribut LOG verwenden die Priorität LOG_INFO, Meldungen mit demAttribut ALERT verwenden LOG_ALERT.

6.3 ALF

6.3.1 Typen von ALF-Meldungen

Meldungen der ALF teilen sich in die folgenden Kategorien auf:

connect Meldungen über Netzwerkverbindungen, die vom lokalen System ausgehend zueinem anderen System aufgebaut werden.

Beispiel: Die Anwendung Firefox versucht www.example.com mit der IP-Adresse1.2.3.4 zu kontaktieren. Dies führt bei entsprechender Konfiguration zu einer Log-oder Alertmeldung vom Typ CONNECT.


104 6. Logging

accept Meldungen über Netzwerkverbindungen, die von einem anderen Rechner zum lo-kalen System aufgebaut werden. Solche Verbindungen entstehen, wenn ein andererRechner Dienste nutzt, die vom eigenen System angeboten werden.

Beispiel: Ein Nutzer des Systems meldet sich zum Beispiel mit Hilfe des Programmsssh über das Netzwerk auf dem lokalen System an.

send message Meldungen über einzelne vom lokalen System versendete Netzwerkpa-kete.

receive message Meldungen über einzelne vom lokalen System empfangene Netzwerk-pakete.

Ereignisse, die zu send message oder receive message Ereignissen führen können,treten in sehr großer Zahl auf. Es ist daher im Allgemeinen nicht empfehlenswert, fürdiese Ereignisse Log- oder Alertmeldungen zu erzeugen, weil durch die große Anzahl anLogmeldungen die Übersicht verloren geht.

6.3.2 Detailinformationen in ALF-Meldungen

Meldungen der ALF enthalten zusätzliche Informationen zur Art des Ereignisses:

• Das verwendet Protokoll (TCP, UDP, SCTP, etc.)

• Die lokale IP-Adresse und der zugehörige Port.

• Die IP-Adresse und der Port des Kommunikationspartners.

6.4 Sandbox

Logmeldungen der Sandbox enthalten Informationen über den Dateisystemzugriff. Dieenthaltenen Information sind im einzelnen:

Zugriffsart Die Art des Zugriffs. Das kann eine beliebige Kombination aus read (lesen),write (schreiben) und exec (ausführen) sein.

Pfad Der Pfad der Datei auf die zugegriffen werden soll.

Prüfsumme Die Prüfsumme der Datei. Diese Information ist nicht immer vorhanden, ins-besondere dann, wenn die Datei gerade verändert wird.

6.5 SFS

Logmeldungen des Moduls SFS enthalten die selben Detailinformationen, wie sie auchin Meldungen der Sandbox enthalten sind, also die Art des Zugriffs, den Pfad auf denzugegriffen wird und, falls verfügbar, die Prüfsumme der Datei.


6.6. Playground 105

6.6 Playground

Der Playground erzeugt in mehrere Situationen Log-Meldungen:

Playground erzwungen Wenn auf Grund einer Administrator- oder einer Benutzerregelein Programm automatisch in einem Playground gestartet wurde, wird dies im Log-Viewer durch eine entsprechende Meldung dokumentiert. Diese enthält den Namendes Programms und die Regel, die den Playground erzwungen hat.

Übernahme aus dem Playground Wenn der Benutzer die Übernahme einer Datei ausdem Playground ins Produktivsystem veranlaßt, wird eine entsprechende Log-Meldung erzeugt. Diese enthält den Namen der übernommenen Datei.

Andere Änderungen am Produktivsystem Einige wenige Operationen können inner-halb eines Playgrounds nicht durchgeführt werden. Dies betrifft zum Beispiel dasVerschieben eines Verzeichnisses. Statt dessen muss der Nutzer direkt durch Be-antworten einer Eskalation entscheiden, ob er zulassen will, dass die fragliche Ope-ration aus einem Playground heraus direkt im Produktivsystem durchgeführt werdensoll. Diese Rückfrage und die zugehörige Entscheidung des Benutzers erzeugen eineLog-Meldung. Diese enthält eine detaillierte Beschreibung der versuchten Operationund ob diese zugelassen oder verboten wurde.


106 6. Logging


FEHLERBEHANDLUNG

• Allgemein

• Application Level Firewall

• Sandbox und SicheresFilesystem

Kapitel 7

Fehlerbehandlung

7.1 Allgemein

Der Status der Module im GUI wird nicht korrekt angezeigt

• Überprüfen Sie in der Statusanzeige links oben im Hauptfenster, ob eine Verbin-dung zum Anoubis-Daemon besteht. Solange keine Verbindung besteht wird auchdie Status-Anzeige der Module nicht aktualisiert.

• Nachdem eine Verbindung zum Anoubis-Daemon hergestellt ist, erfolgt eine Aktuali-sierung der Anzeige innerhalb einiger Sekunden.

• Überprüfen Sie, ob das ALF-Kernelmodul aktiviert ist, indem Sie das folgende Kom-mando auf der Kommandozeile eingeben:

$ lsmod | grep "^alf\>" | wc -l

Wenn dieses Kommando die Ausgabe 0 liefert, wurde das ALF-Kernelmodul vomSystemadministrator nicht aktiviert. Dieses Problem muss vom Systemadministratorbehoben werden. Bis dahin können die Filtermöglichkeiten der ALF nicht genutzt wer-den.

• Überprüfen Sie, ob das SFS-Kernelmodul aktiviert ist, indem Sie das folgende Kom-mando auf der Kommandozeile eingeben:

$ lsmod | grep "^sfs\>" | wc -l

Wenn dieses Kommando die Ausgabe 0 liefert, wurde das SFS-Kernelmodul vomSystemadministrator nicht aktiviert. Dieses Problem muss vom Systemadministratorbehoben werden. Bis dahin können die Filtermöglichkeiten von SFS und Sandboxnicht genutzt werden.

• Als Systemadministrator können Sie das Problem durch Eingabe der folgenden Kom-mandos auf der Kommandozeile beheben:

$ su -

Password:

# modprobe alf

# modprobe sfs

# exit

110 7. Fehlerbehandlung

7.1.1 Beim Klick auf eine Eskalationsmeldung bekommt die Anwen-dung keinen Fokus

Der Wechsel des Fokus von einer Anwendung zu einer anderen wird vom Windowma-nager kontrolliert. Wenn der Windowmanager xanoubis nicht sofort in den Vordergrundbringt, können Sie dies in der Regel durch einen Klick auf den Eintrag von xanoubis in derTaskleiste erreichen.

Unter KDE können Sie auch folgendermaßen vorgehen, um einen Fokuswechsel zu xa-noubis zu erzwingen:

• Wählen Sie im Hauptmenü den Punkt Settings

• Wählen Sie den Menüeintrag Desktop

• Wählen Sie den Menüeintrag Window-Specific Settings

• In dem sich öffnenden Fenster wählen Sie den Tab Advanced

• Wählen Sie die Schaltfläche New

• Wählen Sie den Tab Window

• Wählen Sie bei Window class statt Unimporant den Typ Exact Match aus.

• Geben Sie als Window class den Text xanoubis ein.

• Wählen Sie den Tab Workarounds aus.

• Selektieren Sie Focus steeling prevention

• Wählen Sie als Werte Force und None.

• Klicken Sie auf OK

• Klicken Sie nochmals of OK

7.1.2 Bei aktiviertem Autostart von xanoubis werden mehrere Instan-zen erzeugt

Bei Verwendung der Option Autostart von xanoubis kann es zu Konflikten mit der Auto-startfunktionalität des jeweilig verwendeten Windowmanagers kommen. Hierbei speichertder Windowmanager die laufenden Anwendungen einer Benutzersitzung ab, um sie beimwiederholten bzw. erneuten Einloggen in das System wiederherzustellen und die gewohn-te Arbeitsumgebung zur Verfügung zu stellen. In der Regel können Anwendungen vondiesem Mechanismus innerhalb der Sessionverwaltung des Windowmanagers ausgenom-men werden. Sollte es bei der Verwendung von xanoubis und der Autostartfunktionalitätzu diesem Verhalten kommen, so muss diese von der Sessionverwaltung ausgenommenwerden, um die Erzeugung mehrerer Instanzen zu vermeiden.

Unter KDE können Sie wie folgt vorgehen, um xanoubis von der Sessionverwaltung aus-zunehmen:

• Wählen Sie im Hauptmenü den Punkt Control Center

• Wählen Sie den Menüeintrag KDE Components


7.1. Allgemein 111

• Wählen Sie den Menüeintrag Session Manager

• Selektieren Sie das Eingabefeld im Bereich Advanced mit der Beschreibung Applica-tions to be excluded from sessions: aus und tragen Sie den Text xanoubis ein.

7.1.3 Bei Aktivieren einer Policy wird ein Fehler gemeldet

• Überprüfen Sie, im Regeleditor, ob die aktuell dort angezeigte Policy tatsächlich feh-lerfrei ist.

• Wenn Sie beim Anoubis-Daemon einen Schlüssel hinterlegt haben, überprüfen Sie,ob der selbe Schlüssel auch im GUI konfiguriert ist. Wenn beim Daemon ein Schlüs-sel hinterlegt ist, dann müssen alle Policies beim Aktivieren signiert sein.

• Wenn sich der aktuelle Schlüssel geändert hat, muss der neue Schlüsssel durch denAdministrator dem Daemon bekannt gegeben werden. Siehe dazu Kapitel 4.7.

7.1.4 Nach Hinterlegen des Zertifikates wird Policy nicht geladen

• Nachdem ein Zertifikat vom Administrator hinterlegt wurde ist es notwendig, dassdie eigene Policy nochmals zum Anoubis-Daemon gesendet wird, um eine signiertePolicy zu hinterlegen.

• Öffnen Sie nun den Regel-Editor. Veränderen Sie eine beliebige Regel und setzenSie die Änderung zurück, um den Regel-Satz in einen veränderten Zustand im Regel-Editor zu setzen.

• Schicken sie nun die Regel an den Anoubis-Daemon in dem sie die SchaltflächeAktivieren drücken.

7.1.5 Beim Editieren von Sandbox-/SFS-Regeln kann ich keinen Pfadauswählen

Durch Betätigung der rechten Maustatste über oder auf dem Knopf öffnet sich ein Kon-textmenü. Mit diesem wird das Verhalten des Knopfes beeinflusst. Das aktuelle Verhaltenwird durch eine Markierung vor dem zugehörigen Eintrag angezeigt. Ist ein Eintrag in die-sem Menü inaktiv, so steht das zugehörige Verhalten im gegenwärtigen Kontext nicht zurVerfügung.

7.1.6 Auswahldialog für Datei oder Verzeichnis zeigt keine versteck-ten Objekte

Jeder Auswahldialog, ob für Dateien oder Verzeichnisse, zeigt auf der rechten Hälfte eineListe mit Namen und Attributen von Verzeichnissen und Dateien. Bewegen Sie die Mausüber diese Liste. Mit der rechten Maustaste wird ein Kontextmenü geöffnet. Wählen Sieden untersten Eintrag: „Verborgene Dateien anzeigen“.



7.1.7 Neu einlesen der Konfiguration funktioniert nicht

Der Daemon kann mit einem Signal SIGHUP dazu veranlasst werden, seine Konfigura-tion neu einzulesen. Aufgrund der praktizierten Rechteabgabe können jedoch nicht alleAspekte einer neuen Konfiguration in betracht gezogen werden.Beispielsweise wird das Daemonsocket vom main geöffnet und an session vererbt. Da die-ser seine Rechte abgibt und ein chroot aufruft, hat er keine Möglichkeit, ein neues Socketzu öffnen.Der Daemon muss hier leider komplett neu gestartet werden.

7.1.8 Xanoubis meldet, dass ein neuer Kernel installiert wurde

Xanoubis überwacht, ob durch ein Update ein neuer Kernel installiert wurde. Sollte einneuer Kernel installiert worden sein, wird durch Xanoubis davor gewarnt, dass nur mit ei-nem Anoubis-Kernel das betreiben von Anoubis möglich ist. Um sicher zu stellen, dass derAnoubis-Kernel gebootet wird, überprüfen Sie bitte Ihre grub-Konfiguration. Wird das Sy-stem mit einem nicht Anoubis-Kernel gebootet, kann der Anoubis-Daemon keine Policiesdurchsetzen.

7.1.9 Xanoubis meldet: Falsche APN-Version

Nach dem Verbinden mit dem Anoubis-Daemon erscheint die Meldung: „Der APN-Parserist neuer als der Parser des Anoubis Daemons. Bitte aktualisieren Sie das Daemon-Paket.“Dies bedeutet, dass der Daemon die Syntax der von Xanoubis generierten Poli-cies nicht auswerten kann. In diesem Fall installieren Sie bitte die aktuellste Version desDaemons.

7.1.10 Xanoubis meldet: Falsche Anoubis-Protokoll-Version

Nach dem Verbinden mit dem Anoubis-Daemon erscheint die Meldung: „Die Verbindungkonnte wegen einer Inkompabilität im Anoubis-Protokoll nicht aufgebaut werden.“BeimVerbindungsaufbau konnten sich Anoubis-Daemon und xanoubis nicht auf eine gemein-same Protokoll-Version einigen. In diesem Fall installieren Sie bitte die aktuellste Versionvon xanoubis und des Anoubis-Daemons.

7.1.11 Xanoubis meldet: Falsche .xanoubis-Version

Beim Versuch xanoubis zu starten erscheint die Meldung: „Es wurde eine nicht unter-stützte Version () von HOME/.xanoubis gefunden. Xanoubis wird sich nun beenden.„Diesbedeutet, dass die Version der Konfiguration in .xanoubis Xanoubis nicht bekannt ist. Indiesem Fall installieren Sie bitte die aktuellste Version von xanoubis. Alternativ könnenSie das Verzeichnis HOME/.xanoubis auch umbenennen. Xanoubis erstellt dann automa-tisch ein neues Verzeichnis mit diesem Namen. Hiervon wird jedoch abgeraten, da allegespeicherten Profile nicht mehr zur Verfügung stehen, inklusive aller alten Versionen derPolicies.


7.1. Allgemein 113

7.1.12 Xanoubis meldet: Fehlender Schlüssel

Nach dem Verbinden mit dem Anoubis-Daemon erscheint die Meldung: „Die Verbindungwurde abgebrochen, weil der Schlüssel nicht geladen werden konnten. Bitte überprüfenSie Ihre Schlüssel-Konfiguration (Zertifikat, privater Schlüssel).“

Zum einen können Sie die Passphrase falsch eingegeben haben. Deshalb konnte Ihr pri-vater Schlüssel nicht korrekt gelesen werden. Zum anderen besteht die Möglichkeit, dassSie kein Schlüsselpaar konfiguriert haben. In diesem Fall überprüfen Sie bitte die SFS-Optionen (siehe Abschnitt 5.7.4).

7.1.13 Xanoubis meldet: Falsches Zertifikat

Nach dem Verbinden mit dem Anoubis-Daemon erscheint die Meldung: „Der Daemon fragtnach einem Zertifikat, das Sie nicht konfiguriert haben. Bitte überprüfen Sie Ihre Schlüssel-Konfiguration oder bitten Sie Ihren System-Administrator, Ihr Zertifikat am Daemon zuhinterlegen.“

Beim Verbindungsaufbau fragt der Anoubis-Daemon nach einem Zertifikat, das Sie nichtkonfiguiert haben. Sie müssen es entweder korrekt in den SFS-Optionen (siehe Abschnitt5.7.4) einstellen, oder Ihr System-Administrator muss Ihr Zertifikat am Daemon für Siehinterlegen (Abschnitt 4.7).

7.1.14 Der Anoubis-Kern bootet nicht in einer VirtualBox

Überprüfen Sie, ob in der VirtualBox Konfiguration die Option PAE aktiviert ist:

• Wählen Sie in der VirtualBox Bedienoberfläche die betroffene Maschine aus undKlicken Sie auf den Button Ändern.

• Wählen Sie den Karteireiter Erweitert.

• Stellen Sie sicher, dass im Bereich Erweiterte Einstellungen die OptionPAE/NX aktivieren ausgewählt ist.

7.1.15 Aus einer Eskalation kann keine Regel erzeugt werden

Problem: Bei der Beantworung einer Eskalation sind die Felder zum Erzeugen einer neu-en Regel nicht selektierbar, oder die Erzeugung der Regel schlägt fehl.

Lösung: Dies kann auftreten, wenn der Regelsatz im xanoubis gegenüber dem aktivenRegelsatz im anoubisd so weit geändert wurde, dass anhand der Eskalation nicht mehrentschieden werden kann, wo die Regel eingefügt werden müsste. In diesem Fall hilft es,im Regel-Editor entweder den modifizierten Regelsatz zu aktivieren oder die Änderungendurch die Auswahl von Neuladen vom Daemon zu verwerfen.



7.2 ALF

7.2.1 Nach einiger Zeit ist keine Netzwerkverbindung mehr möglich

Überprüfen Sie die aktiven ALF-Regeln für den Nutzer Root. Der Regelsatz muss gewähr-leisten, dass der Netzwerkkonfigurationsprozess (DHCP) Zugriff auf raw-Sockets hat.

Bei den Regeln, die unmittelbar nach einer Installation aktiv sind, ist dies automatischgewährleistet.

7.2.2 Das automatische Update funktioniert nicht mehr

Überprüfen Sie die aktiven ALF-Regeln für den Nutzer Root. Der Regelsatz muss gewähr-leisten, dass der Update-Prozess Zugriff auf die Ports 53 (dns) und 80 (www) hat.

Bei den Regeln, die unmittelbar nach einer Installation aktiv sind, ist dies automatischgewährleistet.

7.3 Sandbox und SFS

Achtung: Bei allen Prüfsummenoperationen muss der Dateiname immer mit einem Ab-soluten Pfad angegeben werden.

7.3.1 Zugriff auf eine Datei wird verweigert

• Überprüfen Sie die SFS- und Sandbox-Regeln für die entsprechende Datei.

• Überprüfen Sie mit Hilfe des SFS-Browsers, ob für die Datei eine Prüfsumme hinter-legt ist und ob sich diese möglicherweise geändert hat.

• Wenn Sie sich die Änderungen erklären können, verwenden Sie die Update-Funktiondes SFS-Browsers, um die Prüfsumme zu aktualisieren. Versuchen Sie dann denZugriff erneut.

• Achtung: Bitte aktualisieren Sie niemals eine Prüfsumme, wenn die Änderungen aneiner Datei unerwartet sind.

• Zur weiteren Fehlersuche konfigurieren Sie alle Regeln, deren Aktion deny ist, so-dass Logmeldungen erzeugt werden. Der verweigerte Zugriff wird dann im Logviewerangezeigt.

• Wenn nicht die erwartete Regel zutrifft, passen Sie ihren Regelsatz entsprechend an.

7.3.2 Nach einer Regeländerung hängt das System

Es ist grundsätzlich möglich, Regeln so zu konfigurieren, dass Sie sich selbst den Zugriffauf Dateien, die für den Betrieb wichtig sind, entziehen. In diesem Fall kann es dazukommen, dass das System nicht mehr bedienbar ist.


7.3. Sandbox und SFS 115

Kontaktieren Sie in einem solchen Fall den Administrator damit dieser die Regeln entfernt.Als Administrator können Sie dazu wie folgt vorgehen:

• Aktive Regeln in eine Datei speichern:

/sbin/anoubisctl -u userid -p user dump policy

Dabei ist userid die numerische oder symbolische User-ID des betreffenden Nut-zers. Die aktiven Regeln werden in die Datei policy gespeichert.

• Editieren der Regeln: Modifizieren Sie die Regeln in der Datei policy mit einembeliebigen Editor oder mit Hilfe des Regeleditors in xanoubis so, dass das Problembehoben wird.

• Aktivieren Sie modifizierten Regeln:

/sbin/anoubisctl -u userid -p user load policy

Wenn signierte Policies verwendet werden, dann ist dieses Vorgehen nicht ohne Weiteresmöglich, weil zum signieren der Policy der private Schlüssel des Nutzers benötigt wird. Indiesem Fall kann die Policy wie folgt ganz entfernt werden:

rm /var/lib/anoubis/policy/user/<userid>

pkill -HUP anoubisd

Dabei ist <userid> die numerische User-ID des betroffenen Nutzers.

Bei Sandbox-Regeln empfehlen wir, die folgenden Zugriffe im any Block ohne Rückfragezu erlauben, bevor eine ASK-Regel zum Zuge kommt:

Verzeichnis Berechtigung/etc read/lib read/var read/tmp read write/home read write/bin read execute/sbin read execute/usr read execute/var/run/anoubisd.sock read write/dev read write

7.3.3 Es kann kein neuer SFS-Block erstellt werden

• Da SFS-Regeln anwendungsunabhängige Regeln darstellen, wird für jeden Regel-satz nur ein SFS-Block erstellt. Daher wird bei der Erstellung eines neuen Regelsat-zes ein SFS-Block automatisch erstellt.

• Zudem ist der Applikationsreiter für den SFS-Block deaktiviert.



7.3.4 Im Schlüssel-Tab wird eine Warnung angezeigt

• Die Warnung besagt, dass der ausgewählte private Schlüssel und das ausgewählteZertifikat nicht zusammenpassen.

• Dies passiert meistens dann, wenn Sie gerade dabei sind, manuell von einem Schlüs-selpaar zum anderen zu wechseln.

• Sorgen Sie dafür, dass zwei zueinander passende Schlüsselteile ausgewählt sind,um diesen Fehler zu beheben!

7.3.5 Beim Erstellen einer Prüfsumme wird ein Fehler gemeldet

• Prüfen Sie, ob eine Verbindung mit dem Anoubis-Daemon besteht.

• Für das Erstellen von signierten Prüfsummen, muss im GUI ein öffentlicher und einprivater Schlüssel konfiguriert sein. Der öffentliche Schlüssel muss zusätzlich demAnoubis-Daemon bekanntgegegben werden.

• Prüfen Sie, ob der im Anoubis-Daemon konfigurierte öffentliche Schlüssel zu dem imGUI konfigurierten Schlüssel passt. Wie Schlüssel erzeugt und konfiguriert werden,wird in Kapitel 4.7 erklärt.

• Die Fehlermeldung kann unterdrückt werden, indem das Erstellen von signierten Prüf-summen im Abschnitt Details des SFS-Browsers deaktiviert wird.

7.3.6 Im Sandbox-Modul wird eine Regel angezeigt, diese wirkt abernicht

Die Sandboxregeln einer Applikation werden von oben nach unten abgearbeitet, die ersteRegel, die zutrifft, wird angewendet. Wenn keine Regel zutrifft, wird der Zugriff erlaubt.

Damit eine Regel zutrifft, muss die Datei auf die zugegriffen werden soll unterhalb desin der Regel angegebenen Pfads liegen. Wenn in der Sandboxregel ein Subject ange-geben ist, dann muss zusätzlich die von dieser Person hinterlegte Prüfsumme mit demtatsächlichen Inhalt der Datei übereinstimmen, damit die Regel zutrifft.

• Prüfen Sie, ob die Regel auf das fragliche Ereignis tatsächlich zutrifft.

• Fügen Sie grundsätzlich eine default-Regel hinzu, sodass immer mindestens eineRegel zutrifft.

• Prüfen Sie gegebenenfalls durch aktivieren von Logmeldungen für die fraglichen Re-geln, ob tatsächlich die gewünschte Regel zutrifft.

7.3.7 Nach dem Hinzufügen vieler Prüfsummen treten Fehler auf

Das Hinzufügen von Prüfsummen und Signaturen erzeugt unter Umständen sehr vieleDateien im Verzeichnis /var/lib/anoubis/sfs/. Wenn dadurch die Partition voll oderdie maximale Zahl an Dateien erreicht wird, kann es zu Problemen kommen.


7.4. Playground 117

Löschen Sie zunächst (als Administrator) einige Dateien unterhalb von/var/lib/anoubis/sfs/. Dabei gehen registrierte Prüfsummen und Signatu-ren verloren!

Sorgen Sie dann dafür, dass für das Verzeichnis /var/lib/anoubis/sfs eine eigenePartition verwendet wird. Gehen Sie dazu wie im Kapitel 2.1.1 vor.

7.4 Playground

7.4.1 Firefox startet, aber nicht im Playground

Problem: Bei Versuch, die Browser firefox oder iceweasel im Playground zu starten, wirdzwar ein neues Browserfenster geöffnet, dieses läuft dann aber nicht im Playground.

Lösung: Dieses Problem tritt dann auf, wenn der Browser bereits geöffnet ist. In diesemFall wird beim Starten von firefox kein neuer Browser gestartet sondern der bereits laufen-de Browser öffnet ein neues Fenster.

Die einfachste Möglichkeit, dies zu vermeiden, ist, zuerst den existierenden Browser zuschließen und ihn dann neu im Playground zu starten.

Wenn sie tatsächlich zwei Browser gleichzeitig geöffnet haben möchten, von denen einerim Playground läuft und einer nicht, dann muss der zweite Browser mit den Optionen-no-remote und -P gestartet werden:

firefox -no-remote -P

Vor dem eigentlichen Start erscheint dann der Profilmanager von firefox. Sie müssen dortein neues Profil anlegen oder ein gerade nicht benutztes Profil auswählen, weil immer nurein Browser pro existierendem Profil laufen kann.

7.4.2 Eine Applikation startet, aber nicht im Playground

Problem: Bei Versuch, eine Applikation im Playground zu starten, wird zwar ein neuesFenster geöffnet, dieses läuft dann aber nicht im Playground.

Lösung: Das Problem ist analog zu dem im oben beschriebenen Problem mit Firefox. DieLösung besteht darin, die Applikation so zu starten, dass tatsächlich ein neuer Prozessgestartet wird. Ob und wie das möglich ist, hängt von der Applikation ab und muss inderen Dokumentation nachgeschlagen werden. Eine alternative Lösung ist, die außerhalbdes Playgrounds laufende Applikation zu beenden bevor die Applikation im Playgroundgestartet wird.

7.4.3 Playground kann nicht gelöscht werden

Problem: Beim Versuch, einen Playground zu löschen, erscheint die Fehlermeldung Das

Gerät oder die Ressource ist belegt.



Möglicherweise referenziert der Playground Dateien oder Verzeichnisse, die physika-lisch nicht mehr existieren. Diese Situation kann entstehen, wenn sie auf einem nicht-persistenten Dateisystem (wie tmpfs) gespeichert sind. Nach einem Reboot gehen sieverloren.

Lösung: Der Playground kann mit dem folgenden Kommando gelöscht werden:

$ playground -f remove <Playground ID>


FREMDSOFTWARE

• Virenscanner

• Festplattenverschlüsselung

• X-Server (Xorg)

Kapitel 8

Fremdsoftware

8.1 Virenscanner

8.1.1 Avira Antivirus

Die Benutzung der Antivirus Software der Firma Avira ist auch mit Anoubis weiterhin mög-lich. In diesem Abschnitt wird erklärt, welche Schritte unternommen werden müssen, umeine reibungslose Zusammenarbeit zu garantieren.

Installation

Generell muss an dieser Stelle betont werden, dass bei den Installationsanweisungen dieHerstellerangaben der Firma Avira maßgeblich sind.

Unabhängig von der verwendeten Distribution kann die tar-Datei entpackt werden. Eswird hierbei ein Ordner erstellt, in dem sich ein Shellscript zur Installation befindet. Es istauszuführen, und die Anweisungen sollten befolgt werden. Dies könnte wie folgt ausse-hen:

tar xzf antivir....tar.gz

cd antivir.../

sh install

Konfiguration

Die Anoubis Security-Suite liefert bereits rudimentäre Policies für die Antivirus Softwarevon Avira mit. Dies umfasst sowohl den eigentlichen Scanner, der die Dateien durchsucht,als auch das Update-Programm, welches für die Aktualisierung der Virenmuster zuständigist. In den default-Regeln des Administrators für alle Benutzer werden alle Aktionenerlaubt. Die bereitgestellten Profile für die Benutzer sind mit default ask Regeln versehen.Hierdurch werden zur Laufzeit Nachfragen zu Ereignissen erzeugt (siehe Abschnitt 5), dieder Benutzer beantworten muss.

Für die On-Access-Funktionalität verwendet Avira DazukoFS. Dabei handelt es sich umein Modul für den Linux-Kernel. Es ist bereits im Anoubis-Kernel-Paket enthalten. Zu be-achten ist, dass die Playground-Funktion von Anoubis nur zusammen mit DazukoFS ver-

122 8. Fremdsoftware

wendet werden kann, wenn der DazukoFS Mount-Point mit dem Mount-Point des darun-terliegenden Dateisystems übereinstimmt.

Damit der Virenscanner auf alle Dateien zugreifen darf, ist es notwendig, ihn aus denBeschränkungen des SFS auszunehmen. Die Policies wurden bereits, wie im Kapitel 4.4.2beschrieben, vorbereitet.

Nachdem die Binaries und Policies angepasst wurden, muss das Avira Hintergrundmodulneu gestartet werden.

/etc/init.d/avguard stop && /etc/init.d/avguard start

Um Avira als Scanner bei der Übernahme von Dateien aus Playgrounds zu verwenden,muss in der Datei anoubisd.conf das Kommentarzeichen vor folgender Zeile entferntwerden:

commit = required /usr/share/anoubisd/avira_glue.sh Avira AntiVir scanner

Danach muss als Benutzer Root die Konfiguration mittels anoubisctl reload neu ge-laden werden.

8.1.2 ClamAV

Die Benutzung der freien Antivirus Software ClamAV ist auch mit Anoubis weiterhin mög-lich. In diesem Abschnitt wird erklärt, welche Schritte unternommen werden müssen, umeine reibungslose Zusammenarbeit zu garantieren.

Installation

Generell muss an dieser Stelle betont werden, dass bei den Installationsanweisungen dieAngaben des Projekts ClamAV maßgeblich sind.

Debian und Ubuntu stellen bereits fertige Pakete für ClamAV zur Verfügung. Der Auf-ruf eines Paketverwalters wie apt-get oder aptitude mit den notwendigen Paketenclamav-base, clamav-daemon, clamav-freshclam, libclamav6 genügt. DieInstallation des Virenscanners und des Programms zur Aktualisierung der Virensignaturenkönnte wie folgt aussehen:

apt-get install libclamav6 clamav-base clamav-daemon clamav-freshclam

Fedora stellt ebenfalls fertige Pakete für ClamAV zur Verfügung. Der Aufruf eines Paket-verwalters wie yum mit den notwendigen Pakete clamav, clamav-update genügt. Einpassender Aufruf für die Installation des Virenscanners und des Programms zur Aktuali-sierung der Virensignaturen könnte wie folgt aussehen:

yum install clamav clamav-update


8.1. Virenscanner 123

OpenSuse stellt auch fertige Pakete für ClamAV zur Verfügung. Der Aufruf eines Pa-ketverwalters wie yast mit den notwendigen Pakete clamav, clamav-db genügt. Einpassender Aufruf für die Installation des Virenscanners und des Programms zur Aktuali-sierung der Virensignaturen könnte wie folgt aussehen:

yast2 -i clamav clamav-db

OpenBSD stellt ebenso fertige Pakete für ClamAV zur Verfügung. Der Aufruf eines Pa-ketverwalters pkg_add mit den notwendigen Paket clamav genügt. Ein passender Aufruffür die Installation des Virenscanners und des Programms zur Aktualisierung der Virensi-gnaturen könnte wie folgt aussehen:

pkg_add -i clamav

Konfiguration

Die Anoubis Security-Suite liefert bereits rudimentäre Policies für die Antivirus SoftwareClamAV mit. Dies umfasst sowohl den eigentlichen Scanner, der die Dateien durchsucht,als auch das Update-Programm, welches für die Aktualisierung der Virenmuster zuständigist. In den default-Regeln des Administrators für alle Benutzer werden alle Aktionenerlaubt. Die bereitgestellten Profile für die Benutzer sind mit default ask Regeln versehen.Hierdurch werden zur Laufzeit Nachfragen zu Ereignissen erzeugt (siehe Abschnitt 5), dieder Benutzer beantworten muss.

Für die On-Access-Funktionalität verwendet ClamAV in zukünftigen Versionen DazukoFS.Bei DazukoFS handelt es sich um ein Modul für den Linux-Kernel. Es ist bereits imAnoubis-Kernel-Paket enthalten. In der aktuellen Version kann es durch einen Patch hin-zugefügt werden. Zu beachten ist, dass die Playground-Funktion von Anoubis nur zusam-men mit DazukoFS verwendet werden kann, wenn der DazukoFS Mount-Point mit demMount-Point des darunterliegenden Dateisystems übereinstimmt.

Damit der Virenscanner auf alle Dateien zugreifen darf, ist es notwendig, ihn aus denBeschränkungen des SFS auszunehmen. Die Policies wurden bereits, wie im Kapitel 4.4.2beschrieben, vorbereitet.

Um ClamAV als Scanner bei der Übernahme von Dateien aus Playgrounds zu verwenden,muss in der Datei anoubisd.conf das Kommentarzeichen vor einer der beiden folgenderZeile entfernt werden:

commit = required /usr/share/anoubisd/clamscan_glue.sh Clam scanner

commit = required /usr/share/anoubisd/clamdscan_glue.sh Clamd scanner

Dabei verwendet die erste Zeile den normalen Kommandozeilenscanner clamscan. Diezweite Zeile verwendet dagegen clamdscan, welcher die zu scannenden Dateien anden ClamAV-Daemon übergibt. Die zweite Variante ist schneller, erfordert aber dass derClamAV-Daemon läuft.

Nach der Änderung muss als Benutzer Root die Konfiguration mittels anoubisctl

reload neu geladen werden.



8.1.3 Sophos

Die Benutzung der Antivirus Software der Firma Sophos ist mit Anoubis leider nur einge-schränkt möglich. In diesem Abschnitt wird erklärt, welche Schritte unternommen werdensollten und wie die Zusammenarbeit aussieht.

Die von Sophos genutzte Technik für On-Access-Scanning (Talpa) ist nicht geeignet,um von Anoubis unterstützt zu werden. Die von Anoubis bedienten Linux-Kernel undLinux-Distributionen ist komplett disjunkt mit jenen von Sophos und Talpa.

Installation

Generell muss an dieser Stelle betont werden, dass bei den Installationsanweisungen dieHerstellerangaben der Firma Sophos maßgeblich sind.

Unabhängig von der verwendeten Distribution muss ein Ordner angelegt werden. In die-sem ist die tar-Datei zu entpacken. Das Verzeichnis enthält nun unter anderem dasShellscript zur Installation, dass ausgeführt werden muss. Dies könnte wie folgt ausse-hen:

mkdir sophos

cd sophos

tar xzf linux-....tar.Z

sh install.sh

Konfiguration

Die Anoubis Security-Suite liefert keine Policies für die Antivirus Software von Sophosmit. Damit der Virenscanner auf alle Dateien zugreifen darf, ist es notwendig, ihn ausden Beschränkungen des SFS auszunehmen. Dies wird durch context-Regeln erreicht,welche ein nosfs-Flag tragen. Im Kapitel 4.4.2 ist dies genau beschrieben und könnte fürSophos wie folgt aussehen:

context {

/usr/local/bin/sweep nosfs {

context new any

}

}

8.2 Festplattenverschlüsselung

8.2.1 TrueCrypt

Die Benutzung der freien Verschlüsselungssoftware TrueCrypt ist auch mit Anoubis wei-terhin möglich. In diesem Abschnitt wird erklärt, welche Schritte unternommen werdenmüssen, um eine reibungslose Zusammenarbeit zu garantieren.


8.2. Festplattenverschlüsselung 125

Installation

Die Installationsanweisungen des Projekts müssen befolgt werden. Es sind keine Modifi-kationen notwendig, um eine Interoperabilität mit Anoubis zu gewährleisten.

Konfiguration

Die Anoubis Security-Suite liefert bereits rudimentäre Policies für TrueCrypt mit. In dendefault-Regeln des Administrators für alle Benutzer werden alle Aktionen erlaubt. Diebereitgestellten Profile für die Benutzer sind mit default ask Regeln versehen. Hierdurchwerden zur Laufzeit Nachfragen zu Ereignissen erzeugt (siehe Abschnitt 5), die der Be-nutzer beantworten muss.

Natürlich können in den Anoubis Policies auch Pfade, die auf Dateien innerhalb derTrueCrypt-Container zeigen, verwendet werden. Es können auch auf Dateien in den Con-tainern Prüfsummen und Signaturen erstellt werden. Nur muss beachtet werden, dass derMount-Point der Container durch den Benutzer individuell festgelegt und geändert werdenkann. Das kann zur Folge haben, dass Policies nicht mehr gültig sind, da sich die Pfadezu den Dateien im TrueCrypt-Container ändern können.

8.2.2 eCryptfs

Das freie Crypto-Dateisystem eCryptfs kann zusammen mit Anoubis unter Linux verwen-det werden. OpenBSD wird nicht unterstützt, da eCryptfs ein reines Linux-Projekt ist.

Installation

Die durch Anoubis unterstützten Linux-Distributionen liefern bereits Pakete für eCryptfs.

Debian und Ubuntu

apt-get install ecryptfs-utils

Fedora

yum install ecryptfs-utils

OpenSuse

yast2 -i ecryptfs-utils

Die Dokumentation von eCryptfs muss befolgt werden, um eCryptfs zu konfigurieren undzu benutzen.



Konfiguration

Aus Nutzersicht gibt es keine nennenswerte Berührungspunkte zwischen Anoubis undeCryptfs. Es ist daher keine Konfiguration notwendig, um eine Interoperabilität mit Anoubiszu gewährleisten.

8.3 X-Server (Xorg)

Die X-Server Software des Xorg-Projekts beinhaltet seit Version X11R6 eine Erweiterungnamens XTest, die u.a. Funktionalität zur Verfügung stellt, die es ermöglicht Eingabe-Ereignisse von Tastatur und Maus zu simulieren. Diese Ereignisse können von einerbeliebigen Applikation nicht von denen der realen Hardware unterschieden werden. DieBibilotheksfunktionen der Erweiterung XTest erlauben das Generieren bzw. Senden vonTastatur- und Mauseingaben. Damit lässt sich eine Applikation nahezu völlig automatischsteuern. Das hieraus resultierende potentielle Sicherheitsrisiko, dass Eingaben am Nutzerdes Systems vorbei vorgenommen werden, lässt sich nur durch die Deaktivierung dieserX-Erweiterung sicherstellen.

8.3.1 Deaktivieren von Xtest

Um die Erweiterung XTest des X-Servers dauerhaft zu deaktivieren, fügen Sie bitte denfolgenden Abschnitt in die xorg.conf(5) ihres Systems ein.

Section "Extensions"

Option "XTEST" "disable"

EndSection


Anhang A

Abstract Policy Notation

Für die Beschreibung von →Policies, die von den einzelnen Anoubis Komponenten um-gesetzt werden, wird eine einheitliche Sprache verwendet, die →Abstract Policy Notation(APN). Im Folgenden werden zuerst die allgemeinen Elemente der APN beschrieben, diefür alle →Policies gelten. Anschließend werden die speziellen Elemente für die Notationvon ALF, Sandbox, SFS und Kontextregeln genauer erläutert.

A.1 Grundlagen

A.1.1 Administrator- und Benutzerregeln

In diesem Abschnitt werden allgemeine Eigenschaften des Policy-Frameworks zusam-mengefasst.Anoubis unterscheidet Administrator- und Benutzerregeln. Die Administratorregeln gebenden Rahmen vor, der vom Anwender nur weiter eingeschränkt werden kann. Diese Be-ziehung zwischen Administrator- und Benutzerregeln wird im Folgenden als Monotoniebezeichnet.Die Unterscheidung zwischen Administrator- und Benutzerregeln wird nicht auf der Ebeneder Notation getroffen. Das heißt: es ist kein Sprachelement vorgesehen, das Administra-torregeln von Benutzerregeln unterscheidet. Die Unterscheidung von Regeln wird statt-dessen vom Anoubis Backend-Daemon vorgenommen, der die Regeln nach Benutzernsortiert und speichert.Zur Wahrung der Monotonie zwischen Administrator- und Benutzerregeln, wertet der Dae-mon diese Regelsätze unabhängig voneinander aus und bildet aus den Teilergebnissenein Gesamtergebnis.Erlaubt der Administrator zum Beispiel einem Benutzer, mit ssh(1) Verbindungen aufbeliebige Maschine vorzunehmen, kann der Benutzer selbst die Menge der Maschineneinschränken. Beschränkt aber der Administrator die Menge der Maschinen, kann derBenutzer diese nicht erweitern.

A.1.2 Vererbung von Regeln (Kontext-Modul)

Applikationen bestehen oft aus einem komplexen Verbund von verschiedenen Prozes-sen, die unter Umständen weitere Applikationen starten. Ein typisches Beispiel ist ein

128 A. Abstract Policy Notation

Dokumenten-Viewer wie xpdf(1), der von einem Browser aus gestartet wird, um einzuvor heruntergeladenes Dokument anzuzeigen. Es stellt sich nun die Frage, welche Re-geln für xpdf(1) gelten sollen, die des Browsers oder die von xpdf(1). Es gilt also zudefinieren, wie Regeln zwischen Applikationen vererbt werden sollen.

Anoubis verwendet Kontexte, die festlegen, welche Regeln für eine Anwendung gelten.Für Applikationen, die weitere Programme starten (im Sinne von execve(2)), muss ex-plizit spezifiziert werden, ob für das erzeugte Programm ein neuer Kontext und somit einneuer Regelsatz verwendet werden soll oder nicht. Werden keine weiteren Angaben zurVererbung gemacht, gelten bei execve(2) die Regeln des Vaterprozesses weiter.

Diese Vorgehensweise ist konservativ, da die für eine Applikation definierten Einschrän-kungen für alle von dieser Applikation erzeugten Prozesse gelten, wenn nicht ein Wechseldes Kontextes explizit erlaubt wurde.

A.1.3 Standardvorgaben für Ereignisse

Bei Ereignissen, auf die keine existierende Regel passt, werden Standardvorgaben an-gewendet. Diese können definiert werden, wobei auch hier die Monotonie zwischenAdministrator- und Benutzerregeln beachtet wird.

Der Backend-Daemon verwendet für jedes Modul implizit die folgenden Standardvorga-ben:

• ALF: Zugriffe werden verweigert.

• SFS: Zugriffe werden erlaubt.

• Sandbox: Zugriffe werden erlaubt.

• Vererbung: Regelsatz wird beibehalten, der Kontext nicht gewechselt.

A.2 Allgemeine Elemente

In diesem Abschnitt werden allgemeine Sprachelemente der →Abstract Policy Notationspezifiziert. Diese umfassen die folgenden Aspekte:

• Allgemeine Grammatik

• Identifikation von Applikationen

• Regel-IDs

• Gültigkeitsbereich von Regeln

• Kommentare

• Version


A.2. Allgemeine Elemente 129

A.2.1 Allgemeine Grammatik

Mit der APN wird beschrieben, welche→Policies für eine bestimmte Applikation gelten.Ein Regelsatz ist unterteilt in Blöcke. Je ein Block für jedes der Module ALF, Sandbox undSFS sowie ein Block Context, der die Regeln für einen Kontextwechsel beschreibt. Nichtjeder dieser Blöcke muss tatsächlich vorkommen.Die Grammatik für einen einzelnen Block kann mit Hilfe der →Extended-Backus-Naur-From (EBNF) wie folgt beschrieben werden.

<module> = <type> "{" { <rule> } "}" | <sfsmodule>

<type> = "alf" | "sandbox" | "context"

<sfsmodule> = "sfs" "{" { <id> <accessrule> <scope> } "}"

Die innerhalb eines Modulblocks erlaubten Regeln unterscheiden sich je nach Modul.In den Modulen ALF, Sandbox und Context sind innerhalb des Moduls Applikationsblöckemöglich, im Modul SFS können direkt SFS-Regeln angegeben werden.Ein Applikationsblock ist dabei immer wie folgt aufgebaut (ein Kontext-Applikationsblockwird hierbei durch <ctxappblock> repräsentiert):

<appblock> = <id> <apps> <pgonly> { <id> <accessrule> <scope> }

<ctxappblock> = <id> <apps> <nosfs> <pgforce>

{ <id> <accessrule> <scope> }

<apps> = "any" | <app> | "{" <app> { "," <app> } "}"

<app> = <path> <checksum>

<id> = <empty> | <number> ":"

<scope> = [ "task" <number> ] [ "until" <number> ]

<path> = Der Pfad einer Anwendung

<checksum> = <empty> | "self" | uid <number> | "signed-self" |

"key" <keyid>

<nosfs> = <empty> | "nosfs"

<pgonly> = <empty> | "pgonly"

<pgforce> = <empty> | "pgforce"

<number> = Eine Dezimalzahl

<keyid> = Die ID eines SSL-Schluessels

Die Liste der Applikationen gibt jeweils an, für welche Programme dieser Regelblockgelten soll. Dabei kann optional eine im Prüfsummenbestand unter dem angegebenenNamen gespeicherte Prüfsumme statt des Pfadnames verwendet werden. Der Kontext-Applikationsblock kann zusätzlich die Schlüsselwörter nosfs und pgforce beinhalten.Der Schalter nosfs definiert, ob für diesen Kontext SFS-Regeln gelten sollen. Das Schlüs-selwort pgforce erzwingt für den angegebenen Kontext einen Playground. Die in einemBlock zulässigen Zugriffsregeln (in der Grammatik beschrieben durch <accessrule>)hängen wiederum vom konkreten Modul ab. Das Flag pgonly legt fest, dass diese Regelnur dann gelten darf, wenn der dazugehörende Kontext in einem Playground läuft.

A.2.2 Identifikation von Applikationen

Policies adressieren Applikationen. Eine Applikation ist definiert als ein oder mehrereUNIX-Prozesse, die unter Umständen verschiedene Programme (Executables) ausführen.



Beispielsweise besteht die Applikation Firefox zur Laufzeit aus den folgenden Prozessen:

> pstree -c 12805

firefox---run-mozilla.sh---firefox-bin-+-{firefox-bin}

|-{firefox-bin}

|-{firefox-bin}

|-{firefox-bin}

|-{firefox-bin}

`-{firefox-bin}

Es laufen somit neun Prozesse, die verschiedene Binaries ausführen, die zusammen dieApplikation Firefox ergeben. Applikationen werden durch Angabe ihres absoluten Pfadesoder durch eine zu dem angegebenen Pfad im Prüfsummenbestand hinterlegte Prüfsum-me identifiziert.

Applikationen können in einer Liste zusammengefasst werden. Dies erlaubt es, komplexeApplikationen, die aus mehreren Prozessen bestehen, die unterschiedliche Programmeausführen, durch gemeinsame Regeln zu adressieren. Dies wird in der oben angegebenenGrammatik durch das Symbol <apps> beschrieben, während eine einzelne Anwendungdem Symbol <app> entspricht.

A.2.3 Regel-Identifikation

Sowohl die Applikationsblöcke als auch die einzelnen Filterregeln können optional mit ei-ner innerhalb des Regelsatzes eindeutigen ID versehen sein. Falls keine ID im Regelsatzselbst vorgegeben ist, wird von Anoubis selbständig eine neue eindeutige ID vergeben.Diese IDs dienen zur Identifikation von Regeln, zum Beispiel bei der Kommunikation zwi-schen Anoubis-Daemon und den Benutzerinterfaces. Dies wird in der oben angegebenenGrammatik durch das Symbol <id> beschrieben.

A.2.4 Scope – Regeln mit eingeschränkter Gültigkeit

Gelegentlich ist es notwendig, die Gültigkeit einer Regel auf bestimmte Prozesse oder füreine bestimmte Zeitdauer einzuschränken. Das Erstellen von Regeln mit Scope wird vomRuleEditor nicht unterstützt.

Die Einschänkung erfolgt mit Hilfe des „<scope>”. Mögliche Elemente des Scopes sind:

Prozess Mit Hilfe von „task” kann die Regel auf einen bestimmten Prozess beschränktwerden. Der Prozess wird identifiziert durch eine Zahl, die unabhängig von derProzess-ID durch Anoubis vergeben wird.

Endzeitpunkt Mit Hilfe von „until” kann ein Endzeitpunkt in Sekunden seit dem1.1.1970 0:00:00 GMT vorgegeben werden.

Regeln mit Scope werden in der GUI durch das Beantworten von Eskalationen erstellt.Regeln mit Scope werden beim Neuladen von Regeln oder Neustarten des Anoubis-Daemons vom Regelsatz entfernt, wenn der Scope keine Bedeutung mehr hat.


A.3. Vererbung 131

A.2.5 Kommentare

Jeglicher Text, der dem Zeichen “#” bis zum Ende der Zeile folgt, wird nicht weiter inter-pretiert und als Kommentar behandelt.

A.2.6 Version

Die APN-Notation ist versioniert, um bei Änderungen der Syntax die Policies entsprechendihrer Version interpretieren zu können. Die Version sollte am Anfang einer Policy stehenund die folgende Notation aufweisen:

apnversion 1.0

A.3 Vererbung

Die APN verwendet zur Definition der Vererbung Kontext-Regeln. Diese sind nur als<accessrule> innerhalb eines Blocks im Context-Modul zulässig:

<accessrule> = context new <apps>

Hier ist <apps> wie in der Grammatikbeschreibung definiert und gibt die Applikationenan, bei deren Ausführung ein neuer Kontext eröffnet werden soll. Durch Angabe von any

kann festgelegt werden, dass alle gestarteten Applikationen einen neuen Kontext bekom-men sollen. Eine solche Definition ist als Standardvorgabe für Applikationen, die keineeigenen Kontextregeln haben, sinnvoll. Darüber hinaus ist dies typischerweise der Fall fürApplikationen, deren Aufgabe es ist, andere unabhängige Programme zu starten (Shells,Window-Manager, etc.).

Wird keine Vererbungsregel angegeben, bleiben alle Kindprozesse im Kontext des Vater-prozesses.

A.4 Application Level Firewall

Die→Application Level Firewall behandelt zwei Arten von Netzwerkzugriffen:

• Initiierung einer ausgehenden Netzwerkverbindung.

• Annehmen einer eingehenden Netzwerkverbindung.

Für die Protokolle UDP, TCP und SCTP der Adressfamilien IPv4 und IPv6 können Netzzu-griffe über Regeln feingranular erlaubt oder verboten werden. Netzwerkzugriffe, die nichtauf UDP und TCP basieren (insbesondere Raw-Sockets) oder anderen Adressfamilien alsIPv4 und IPv6 angehören, werden über Capability-Regeln vollständig erlaubt oder unter-bunden. Eine feingranulare Filterung wie bei UDP und TCP ist nicht möglich.



A.4.1 Filterregeln

ALF Filterregeln sind nur innerhalb eines Applikationsblocks im ALF -Modul zulässig undwie folgt aufgebaut:

<accessrule> = <alffilter> | <alfcapability> | <alfdefault>

<alffilter> = <action> <access> <log> <proto> <hosts>

<alfcapability> = <action> <log> <capability>

<alfdefault> = "default" <log> <action>

<action> = "allow" | "deny" | "ask"

<log> = <empty> | "log" | "alert"

<access> = "connect" | "accept" | "send" | "receive"

<proto> = "tcp" | "udp" | "sctp"

<capability> = "raw" | "other" | "all"

<hosts> = "all" | "from" <host> "to" <host>

<host> = <addrlist> "port" <portlist>

<addrlist> = "any" | <addr> | "{" <addr> { "," <addr> } "}"

<portlist> = "any" | <port> | "{" <port> { "," <port> } "}"

<addr> = IPv4 oder IPv6 Addresse / Netzwerk

<port> = Eine Portnummer oder ein Bereich von Ports

Mit <action> wird festgelegt, ob der von dieser Regel spezifizierte Netzwerkzugriff er-laubt oder verboten werden soll. Darüber hinaus besteht die Möglichkeit, mit Hilfe von askeine interaktive Rückfrage beim Nutzer zu veranlassen.Anschließend wird die Richtung des Zugriffes angegeben, connect oder accept beiTCP oder SCTP und send oder receive bei UDP.Mit dem optionalen Terminalsymbolen log und alert wird bestimmt, dass Zugriffe, dievon dieser Regel gefiltert werden, protokolliert werden.Darauf folgt die Definition des Protokolls. Hier stehen die Terminalsymbole tcp, udp undsctp zur Verfügung und eines muss gegeben sein.Als letztes folgt die Angabe der Quell- und Zieladresse, die ein Paket haben muss, damitdiese Regel angewendet wird. Mit from wird der Absender und mit to der Empfängerfestgelegt. Absender und Empfänger entsprechen dabei der in jedem IP-Paket gegebenenAbsender- und Empfängeradresse.Statt einer einzelnen Adresse oder eines einzelnen Ports kann jeweils eine ganze Listeoder any angegeben werden. Darüber hinaus sind bei Adressen auch Netzmasken inCIDR-Notation zulässig.

A.4.2 Capability-Regeln

Mit Capability-Regeln wird definiert, ob eine Applikation Raw-Sockets verwenden darf.Raw-Sockets werden zum Beispiel für ping(1) oder dhclient(1) benötigt.

A.4.3 Default-Regeln

Mit Default-Regeln wird das Verhalten aller nicht näher spezifizierten Netzwerkzugriffedefiniert. Default-Regeln finden unabhängig von ihrer Position in der Regelliste nur An-


A.5. Sandbox 133

wendung, wenn keine andere Regel auf den fraglichen Zugriff anwendbar ist.

A.5 Sandbox

Die Sandbox bietet die Möglichkeit, die Dateizugriffe einzelner Applikationen abhängig vonPfad und eventuell vorhandenen Prüfsummen einzuschränken. Dazu können Sandbox-Filterregeln verwendet werden, die wie folgt aufgebaut sind:

<accessrule> = <sbfilter> | <sbdefault>

<sbfilter> = <action> <log> <filespec> <permissions>

<sbdefault> = "default" <log> <action>

<filespec> = "any" | <prefix> [ <subject> ]

<prefix> = "path" <path>

<subject> = "self" | "signed-self" | "uid" <number> |

"key" <keyid>

<permissions> = [ "r" ] [ "w" ] [ "x" ]

<action> = "allow" | "deny" | "ask"


<path> = Ein absoluter Pfad- oder Verzeichnisname


<keyid> = Die ID eines kryptographischen Schlüssels

Sandbox-Filterregeln wie oben beschrieben sind nur innerhalb eines Sandbox Applikati-onsblocks zulässig.Analog zu ALF -Regeln wird durch <action> und <log> angegeben, was geschehensoll, wenn die Regel zutrifft. Es kommt immer die erste zutreffende Regel zur Anwendung.Eine weitere Auswertung der Regeln findet nicht statt. Allerdings wird eine Default-Regelunabhängig von ihrer Position in der Liste nur dann angewandt, wenn keine andere Regelfür das fragliche Ereignis zutrifft.Damit eine Regel anwendbar ist, müssen drei Bedingungen erfüllt sein:

• Der Pfad, auf den zugegriffen werden soll, muss unterhalb des durch <prefix> an-gegebenen Pfadpräfix liegen. Ist hier „any” angegeben, dann sind alle Pfade zulässig.

• Wenn mit Hilfe von <subject> auf eine Prüfsumme im Schattenbaum verwiesenwird, muss eine solche Prüfsumme vorhanden sein und die Prüfsumme muss zumaktuellen Inhalt der Datei passen. Ist die Prüfsumme signiert, so muss zusätzlich dieSignatur gültig sein.

• Die Zugriffsart (lesen, schreiben oder ausführen) des Ereignisses muss in den durch<permissions> angegebenen Zugriffsrechten enthalten sein. Bei einem Zugriff, dermehrere Zugriffsarten einschließt (z.B. read/write kombiniert) werden die Regeln se-parat für jeden der beiden Zugriffe ausgewertet, sodass bei jeder Auswertung nurüber einen einzigen Zugriff entschieden wird.

Neben diesen Filterregeln unterstützt auch die Sandbox Default-Regeln, die zur Anwen-dung kommen, wenn keine andere Sandbox-Regel anwendbar ist. Der Aufbau und dasVerhalten von Default-Regeln der Sandbox entspricht genau dem von Default-Regeln derALF.



A.6 SFS

Das Modul SFS bietet die Möglichkeit, unabhängig von einer bestimmten Anwendungfestzulegen, dass auf bestimmte Bereiche des Dateisystems nur zugegriffen werden darf,wenn für die Dateien gewisse Integritätsbedingungen erfüllt sind. Die Integrität wird dabeidurch das Hinterlegen geeigneter Prüfsummen bei Anoubis gewährleistet.

Der Aufbau einer SFS-Regel ist wie folgt:

<accessrule> = <sfsfilter> | <sfsdefault>

<sfsfilter> = <prefix> <subject> <valid> <invalid> <unknown>

<valid> = "valid" <log> <sfsaction>

<invalid> = "invalid" <log> <sfsaction>

<unknown> = "unknown" <log> <sfsaction>

<sfsdefault> = "default" <path> <log> <action>

<prefix> = "path" <path>

<subject> = "self" | "signed-self" | "uid" <number> |

"key" <keyid>

<sfsaction> = "allow" | "deny" | "ask" | "continue"


<path> = Ein absoluter Pfad- oder Verzeichnisname


<keyid> = Die ID eines kryptographischen Schlüssels

SFS-Filterregeln sind nicht an eine bestimmte Applikation gebunden, sondern gelten füralle Aktionen eines Nutzers.

Jede Filterregel wird durch die Angabe eines Pfadpräfix auf bestimmte Bereiche des Datei-systems beschränkt. Für alle Dateien in diesem Bereich wird dann überprüft, ob die durch„<subject>” angegebene Prüfsumme vorhanden ist. Im Falle einer signierten Prüfsum-me gilt diese als nicht vorhanden, wenn die Signatur ungültig ist, da dann die Prüfsummeals manipuliert betrachtet werden muss.

Die Prüfsumme wird mit dem tatsächlichen Inhalt der Datei verglichen. Abhängig vomErgebnis dieses Vergleichs wird eine der drei Aktionen ausgeführt:

valid Diese Aktion wird ausgeführt, wenn eine Prüfsumme vorhanden ist und mit demInhalt der Datei übereinstimmt.

invalid Diese Aktion wird ausgeführt, wenn eine Prüfsumme vorhanden ist, diese abernicht mit dem Inhalt der Datei übereinstimmt. Dieser Fall tritt bei vorhandener Prüf-summe auch dann ein, wenn die Datei zum Schreiben geöffnet wird, weil sich dannkeine zuverlässige Aussage über den Inhalt der Datei treffen lässt.

unknown Diese Aktion wird ausgeführt, wenn keine Prüfsumme vorhanden ist.

Wenn der Pfad einer Datei durch das Pfadpräfix einer SFS-Regel erfasst wird, ist immergenau eine dieser drei Aktionen anwendbar. Um dennoch die Möglichkeit zu haben, dieRegelauswertung mit der nächsten Regel fortzusetzten, gibt es in SFS-Regeln die spezi-elle Aktion „continue”.

Default-Regeln des SFS-Moduls bestehen aus zwei Komponenten:


A.6. SFS 135

Ein Pfadpräfix Dieses schränkt die Gültigkeit der Default-Regel auf Dateien unterhalbdes angegebenen Pfades ein.

Eine Aktion Diese gibt an, was bei Anwendung der Default-Regel passieren soll.

Im Vergleich zu Default-Regeln des ALF- oder des Sandbox-Modul unterscheiden sichDefault-Regeln des SFS-Moduls also durch das zusätzliche Pfadpräfix.




Anhang B

Architektur und Pfade

Anoubis besteht aus einer Kernelkomponente, einem Systemdaemon und einer Reihe vonProgrammen zur Arbeit und Konfiguration.

B.1 Kernelkomponente

Um in der Lage zu sein, Netzwerk- und Dateisystemzugriffe abzufangen und die Zuläs-sigkeit nach eigenen Regeln zu bewerten, wird eine Kernelkomponente benötigt. Diesegibt die einzelnen Ereignisse über ein spezielles Device an den Anoubis-Daemon zur Ent-scheidung weiter.Unter Linux können die meisten Teile einzeln als Modul kompiliert und im Notfall durchden Administrator auch entfernt werden. Dieses Vorgehen kann gelegentlich bei der Feh-lersuche hilfreich sein, wird aber darüber hinaus nicht weiter unterstützt.Unter OpenBSD müssen alle Komponenten in den Betriebssystemkern fest eingebundenwerden.Die einzelenen Komponenten sind:

eventdev Ein spezielles Device, um Ereignisse an den Anoubis-Daemon weiterzugeben.

anoubis_core Der Kern der Anobuis-Infrastruktur im Betriebssystemkern, der von denModulen alf und sfs genutzt wird.

alf-Kernelmodul Dieses Modul ist zuständig für die Kontrolle von Netzwerkzugriffen.

sfs-Kernelmodul Dieses Modul ist zuständig für die Kontrolle von Dateisystemzugriffen.

Das Modul anoubis_core verwendet soweit möglich die auf dem jeweiligen System vor-handenen Schnittstellen, die auch zur Implementierung von Mandatory-Access-Control(MAC) verwendet werden. Unter Linux ist dies die LSM-Schnittstelle, unter OpenBSDwurde die TrustedBSD-Infrastruktur, wie sie in FreeBSD implementiert ist, portiert undverwendet.

B.2 Der Anoubis-Daemon

Der Anoubis-Daemon nimmt Ereignisse vom Kern entgegen und führt sie anhand deraktiven Regeln einer Entscheidung zu. Dabei kann es vorkommen, dass die Entscheidung

138 B. Architektur und Pfade

an ein Userinterface weitergeben wird. Ein Userinterface (in der Regel xanoubis) mussdazu mit dem Anoubis-Daemon verbunden sein.

Die Entscheidung, wie mit dem Ereignis weiter verfahren werden soll, teilt der Anoubis-Daemon dann dem Betriebssystemkern mit.

Der Anoubisd-Daemon selbst besteht aus mehreren Prozessen, die miteinander Kommu-nizieren:

master Der Hauptprozess kommuniziert direkt mit dem Kern.

policy Der Policyprozess verwaltet Policies und wertet sie aus.

session Der Sessionprozess ist für die Kommunikation mit den Userinterfaces zuständig.

logger Das Logging von Meldungen via syslog wird vom Loggerprozess übernommen.

upgrade Der Upgradeprozess veranlaßt die nötigen Prüfsummenänderungen bei einemSystemupgrade.

scanner Ein Scannerprozess startet die Inhaltsscanner für die Playgrounds. Es kannmehrere Scannerprozesse geben, einen je Benutzer.

B.2.1 Pfade

Dieser Abschnitt dokumentiert Pfade, die vom Anoubis-Daemon verwendet werden. In derRegel sollten die darin enthaltenen Daten auch vom Administrator nicht direkt modifiziertwerden. Stattdessen bietet der Anoubis-Daemon Mechanismen, um notwendige Änderun-gen vorzunehmen oder den aktuellen Stand anzuzeigen.

Der Anoubis-Daemon verwendet die folgenden Pfade:

/dev/anoubis Dieses Device wird vom Anoubis-Daemon verwendet,um mit dem Kern zu kommunizieren. Außerdem wird esvon den Userinterfaces verwendet, um durch den Kernberechnete Prüfsummen zu ermitteln.

/dev/eventdev Über dieses Device empfängt der Anoubis-DaemonNachrichten des Kerns und beantwortet diese.

/var/run/anoubisd.pid Diese Datei wird verwendet, um sicherzustellen, dass im-mer nur eine Instanz des Anoubis-Daemon läuft. Sie ent-hält die Prozess-ID des Anoubis-Daemon Masterprozes-ses.


B.3. Anoubis Werkzeuge 139

/var/lib/anoubisd/ In diesem Verzeichnis sind Konfigurations- und Verwal-tungsdaten des Anoubis-Daemon enthalten. Im Einzel-nen existieren die folgenden Unterverzeichnisse:

sfs/ Dieses Verzeichnis enthält Prüfsummen und Signa-turen, die von den Nutzern hinterlegt wurden. EinZugriff sollte mit Hilfe des Kommandos sfssig ge-schehen.

policy/admin/ Dieses Verzeichnis enthält die Admini-stratorpolicies. Der Zugriff auf dieses Verzeichnissollte mit anoubisctl geschehen.

policy/user/ Dieses Verzeichnis enthält die User-Policies. Der Zugriff auf dieses Verzeichnis sollte mitanoubisctl geschehen.

policy/pubkeys/ Dieses Verzeichnis enthält die Zertifi-kate der Nutzer, die dort vom Administrator hinter-legt werden müssen.

playground/ In diesem Verzeichnis speichert derAnoubis-Daemon Informationen zu den Play-grounds, in denen noch Programme laufen oderDateien existieren, die weder gelöscht noch insProduktivsystem übernommen wurden.

/var/run/anoubisd.sock Dieses Socket wird von den Userinterfaces zur Kommu-nikation mit dem Anoubis-Daemon verwendet.

/etc/anoubis/ Konfigurationsdateien des Anoubis-Daemon, die vomAdministrator bei Bedarf modifiziert werden können.

/etc/anoubis/anoubisd.conf Die Konfigurationsdatei beinhaltet verschiedene Optio-nen, die das Laufzeitverhalten des Anoubis Daemons be-einflussen.

/var/spool/anoubis/ Dieses Verzeichnis ist das Heimatverzeichnis des Benut-zers _anoubisscan. Für Playgrounds konfigurierte In-haltsscanner verwenden dieses Verzeichnis als Arbeits-verzeichnis.

Bei einer endgültigen Deinstallation von Anoubis sollte sichergestellt werden, dass allediese Pfade gelöscht werden.

B.3 Anoubis Werkzeuge

Als Bestandteil von Anoubis werden vier Werkzeuge für Konfiguration und Betrieb mitge-liefert:

xanoubis Die graphische Benuzteroberfläche.


140 B. Architektur und Pfade

anoubisctl Kommandozeilentool zur Anzeige und zum Laden von Policies.

sfssig Kommandozeilentool zur Verwaltung von signierten und unsignierten Prüfsum-men.

playground Kommandozeilentool zum Starten von Programmen in einem Playground,sowie zum Verwalten der in Playgrounds geänderten Dateien.

Der genaue Pfad unter dem diese Werkzeuge installiert werden, hängt von den Konventio-nen der einzelnen Distributionen ab. In der Regel finden sich xanoubis und playgroundin /usr/bin, die anderen beiden Werkzeuge in /sbin.

Alle Werkzeuge verwalten ihren Status im Unterverzeichnis .xanoubis des Heimatver-zeichnisses des Benutzers. Diese Verzeichnisse sollten bei einer endgültigen Deinstallati-on von Anoubis ggf. auch gelöscht werden.

Zum dem in .xanoubis verwalteten Status gehören die gespeicherten Einstellungen vonxanoubis und die Daten der Versionsverwaltung und der gespeicherten Profile. Änderun-gen an diesen Daten dürfen nur mit Hilfe der jeweiligen Werkzeuge z.B. dem RuleEditorvorgenommen werden. Das Vornehmen von manuellen Änderungen an diesen Daten wirdnicht unterstützt.


Anhang C

SFS Import/Export

Prüfsummen und Signaturen können von GUI und CLI in Dateien exportiert und aus Da-teien importiert werden. Dabei wird folgendes Dateiformat verwendet: In jeder Zeile stehtein Eintrag. Jeder Eintrag besteht aus dem Dateinamen (mit Pfad), sowie Prüfsummeund/oder Signatur für einen Benutzer:

entry = filename checksumspec sigspec

checksumspec = "-" | uid checksum

sigspec = "-" | keyid signature

uid = number

filename = escaped string

keyid = escaped string

checksum = hexdigits

signature = hexdigits

Dabei werden im Dateinamen filename und im Namen des öffentlichen Schlüsselskeyid folgende Ersetzungsregeln angewendet:

• Vor Leerzeichen und Backslashes (\) wird ein zusätzlicher Backslash gesetzt.

• Zeichen mit ASCII-Code 1 bis 31 (Kontrollzeichen) werden als dreistellige Oktalzahlmit vorangestelltem Backslash dargestellt: \023

Die Prüfsumme checksum und die Signatur signature werden als Hexdump dargestellt.

Das CLI kann gleichzeitig die Prüfsummen/Signaturen von mehreren Benutzern exportie-ren. In diesem Fall werden mehrere Einträge für die gleiche Datei erzeugt.

142 C. SFS Import/Export


Anhang D

Interface für Inhaltsscanner

Dieser Anhang beschreibt das Interface, mit dem die für Playgrounds konfigurierten In-haltsscanner aufgerufen werden. Die Konfiguration der Inhaltsscanner wurde in Abschnitt4.9.4 beschrieben.

Die Scanner werden mit den Rechten des Systembenutzers _anoubisscan aufgerufen.Das aktuelle Arbeitsverzeichnis des Scannerprozesses ist das Heimatverzeichnis diesesSystembenutzers (normalerweise /var/spool/anoubis). Falls dieses Verzeichnis nichtexistiert wird der Scanvorgang fehlschlagen.

Die zu prüfende Datei steht auf dem Filedeskriptor STDIN zur Verfügung. Dabei ist die-ser Filedeskriptor eine direkte Referenz auf den Inode der Datei, d. h. er kann als Argu-ment für Funktionen wie lseek(2) und fstat(2) verwendet werden. Falls ein Scannernur die Übergabe eines Dateinamens unterstützt, oder falls er spezielle Kommandozei-lenoptionen benötigt, muss man ein geeignetes Shell-Skript erstellen, welches die Da-tei in ein Spool-Verzeichnis schreibt und den Scanner aufruft. Es wird empfohlen, dass/var/spool/anoubis als Spool-Verzeichnis verwendet wird. Auf das Verzeichnis solltenur der Benutzer _anoubisscan zugreifen dürfen. Bei Anoubis werden zwei Beispiel-Skripte mitgeliefert, die Avira Antivir bzw. ClamAV aufrufen. Die Verwendung dieser Skrip-te wird in den Abschnitten 8.1.1 bzw. 8.1.2 erläutert.

Falls ein Scanner die Übernahme einer Datei ins Produktivsystem erlauben will, muss erden Fehlercode 0 zurückgeben. Will er dagegen die Übernahme einer Datei verhindern,muss er einen von 0 verschiedenen Fehlercode zurückgeben. In diesem Fall muss erausserdem eine Begründung für die Entscheidung auf STDOUT oder STDERR ausgeben.Diese Begründung wird dem Benutzer angezeigt. Die Ausgabe eines einzelnen Scannersdarf nicht länger als 1 kByte sein. Die Gesamtlänge der Ausgaben aller Scanner inklusiveder konfigurierten Namen der Scanner darf nicht größer als 8 kByte sein.

144 D. Interface für Inhaltsscanner


GLOSSAR

Anhang E

Glossar

APN Abstract Policy Notation. Eine für Anoubis entworfene Sprache zur Beschreibungvon→Policies.

ALF Application Level Firewall. Im Gegensatz zu reinen Paketfiltern1 arbeitet die App-lication Level Firewall auf Applikationsebene (Schicht 7 im ISO-OSI-Modell). Dabeiwird es dem Administrator und Benutzer ermöglicht, den Netzwerkzugriff einzelnerAnwendungen (Applikationen) feingranular zu regeln. Hierbei werden Socket-Zugriffevon Benutzeranwendungen abgefangen und ggf. unterbunden.

BSD Berkley Software Distribution. Eine Version des Betriebssystems UNIX welches un-ter der offenen BSD-Lizenz veröffentlicht wurde. Bekannte Derivate sind FreeBSD,NetBSD und OpenBSD.

DNS Domain Name System. Ein verteiltes Datenbanksystem, das dazu dient, Rechner-namen in IP–Adressen umzusetzen und umgekehrt. Das DNS ist hierarchisch aufge-baut und auf viele DNS–Server verteilt. Jeder Server ist nur für bestimmte Domänenzuständig. Anfragen die nicht direkt beantwortet werden können, werden in der Hier-archie nach oben oder unten weiterdelegiert.

default bedeutet soviel wie Voreinstellung oder Standardwert. Z.B die Vorbelegung be-stimmter Programmparameter. Werden bei einem Programm keine Parameter ange-geben, so wird eine Voreinstellung genommen, sofern diese spezifiziert ist. Allgemei-ner fällt unter default alles das, was “nicht näher spezifiziert” ist. siehe→defaultroute.

defaultroute Beim→Routing die Route, die gewählt wird, wenn es keine explizite Routezu einem Zielnetz oder -rechner gibt, die genauer passen würde. Üblicherweise dieRoute zum Internet.

EBNF Extended-Backus-Naur-Form. Die →Extended-Backus-Naur-Form ist eine kom-pakte, formale Metasprache zur Darstellung kontextfreier Grammatiken. Die vonAnoubis verwendete→Abstract Policy Notation zur Formulierung von→Policies wirdin diesem Buch in→Extended-Backus-Naur-Form beschrieben.

FQDN Fully Qualified Domain Name. Der vollständige Name eines Rechners, der ihn imInternet eindeutig identifiziert. Er setzt sich aus dem Hostnamen und dem Domain-namen – durch einen Punkt getrennt – zusammen. Ein FQDN wird vom →Domain

1Paketfilter untersuchen zumeist reine Verbindungsdaten wie Quelle (IP-Adresse), Ziel (IP-Adresse) undDienst (Port).

148 E. Glossar

Name System verwaltet und in eine →IP–Adresse (oder manchmal auch mehreredavon) umgesetzt.

Grub Ein Bootloader für Linux, der derzeit bei den meisten Linux-Distributionen verwendetwird.

HTML HyperText Markup Language. Beschreibungssprache für das Layout von Doku-menten im WWW.

HTTP hypertext transfer protocol Protokoll, das für die Kommunikation zwischen einemWWW–Server und einem WWW–Client („Browser”) verwendet wird. HTTP arbeitet„verbindungslos”, d.h. auf eine Anfrage wird genau eine Antwort (Daten oder Fehler-meldung) geliefert, danach wird die Verbindung beendet.

HTTPS steht für HTTP Secure und bedeutet HTTP über eine verschlüsselte Verbindung,meist über SSL (Secure Sockets Layer).

IP–Adresse Die numerische Netzwerkadresse des Rechners, die zumindest innerhalbeines Netzes eindeutig sein muss. Sie ist bei IPv4 32 Bit lang und wird normalerweisein der Form: 192.168.23.10 dargestellt.

Lilo Ein Bootloader für Linux, der früher häufig verwendet wurde. Heutzutage wird übli-cherweise→Grub verwendet.

Linux Quelloffenes unixartiges Betriebsystem, das unter der GPL veröffentlicht wird.

Policy Bei Anoubis beschreiben →Policies die Einschränkungen, die für Applikationenbei Ressourcenzugriff gelten. Durchgesetzt werden die →Policies von den Sicher-heitsmodulen der Anoubis Suite.

Route „Wegbeschreibung” für Netzpakete, die allerdings nur aussagt, welches die näch-ste Zwischenstation (hop) für ein Paket mit einer bestimmten Zieladresse ist. (siehe→Routing)

Routing Der Mechanismus des Weiterleitens von Netzpaketen (IP–Paketen) entlang von→Routen.

Schattenbaum ist der Ort im Dateisystem, in dem die entsprechenden Prüf- summen zuden einzelnen Usern und Dateien abgelegt werden.

SCTP Stream Control Transmission Protocol ist ein zuverlässiges, verbindungsorientier-tes Protokoll, das auf einem potenziell unzuverlässigen verbindungslosen Paketdienstaufsetzt.

SFS Secure Filesystem bietet jedem Nutzer die Möglichkeit Prüfsummen zu Dateien ineiner vom System verwalteten Datenbank einzutragen. Diese Prüfsummen könnenoptional signiert werden, wenn der Administator den öffentlichen Schlüssel des Nut-zers im System hinterlegt hat.

SB Sandbox. Bezeichnet die Einschränkung einer Software auf eine eigene - vom Sy-stem getrennte - Laufzeitumgebung. Damit wird u.a. erreicht, dass die Software nurin dieser Umgebung handlungsfähig bleibt und ihr Verhalten analysiert werden kann.

TCP/IP Transmission Control Protocol/Internet Protocol. Bezeichnung für die Protokollfa-milie der im Internet verwendeten Protokolle. Schließt sowohl IP und TCP als auchalle Anwendungsprotokolle mit ein.


149

TCP/IP–Stack Bezeichnung für den Teil des Betriebssystems (Kernels), der für alle An-wendungen das Versenden und Empfangen von TCP–Paketen übernimmt (auchTCP/IP–Subsystem).

URL Uniform Resource Locator Eindeutige Adresse zum Auffinden von Informationen im→WWW. Besteht aus Protokollangabe (HTTP, FTP), Rechnerangabe (Hostname)und Dateipfad auf diesem Rechner.


Date post:	15-May-2015
Category:	Technology
Upload:	gordem
View:	1,663 times
Download:	1 times

Handbuch de

Technology