Handbuch de

Installations- und
Konﬁgurationshandbuch

GeNUA mbH, Kirchheim

0.9.5

• Einführung
• Installation
• GUI Überblick
• Konﬁguration
• 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 Systemkonﬁguration . . . . . . . . . . . . . . . . . . 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 Konﬁguration 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 Anwendung
keinen Fokus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.1.2 Bei aktiviertem Autostart von xanoubis werden mehrere Instanzen
erzeugt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Pfad
auswählen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.1.6 Auswahldialog für Datei oder Verzeichnis zeigt keine versteckten
Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Zertiﬁkat . . . . . . . . . . . . . . . . . 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 Identiﬁkation von Applikationen . . . . . . . . . . . . . . . . . . . . 129


x INHALTSVERZEICHNIS

A.2.3 Regel-Identiﬁkation . . . . . . . . . . . . . . . . . . . . . . . . . . 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


E INFÜHRUNG
• Anoubis
• Über dieses Handbuch

Kapitel 1

Einführung

1.1 Anoubis

1.1.1 Einleitung
Anoubis - die Security-Suite
fü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, eine
erstmalig alle Aspekte des Sicherheitsmanagements von Rechnersystemen umfassende
Lösung zu schaffen, die sowohl die Betriebssysteme der Linux- als auch der BSD-Familie
unterstützt.
Das Kernstück der Security Suite bilden zum Einen eine Application Level Firewall 1 und
eine Sandbox, mit deren Hilfe Prozesse in einer abgeschotteten Umgebung ausgeführt
werden können, die nur die notwendigen Zugriffe auf vorhandende Dateien und Netz-
werkresourcen erlaubt. Zum Anderen bieten Playgrounds die Möglichkeit, Programme so
auszuführen, dass diese keinerlei Änderungen an Dateien im Produktivsystem direkt vor-
nehmen können. Die Programme werden dadurch weder in ihrer Funktion beeinträchtigt
noch müssen die Programme angepaßt oder verändert werden.
Zusammen kann damit sowohl der ungewollte Abﬂuß von Informationen aus dem System
als auch das ungewollte Eindringen von Daten in das System verhindert werden.
Darüber hinaus werden Mechanismen zur Sicherstellung der Authentizität von Dateien
und Verzeichnissen sowie von Applikationen bereitgestellt. Hierbei werden diese mittels
zeitgemäßer Prüfsummen versehen, die darüber hinaus noch signiert werden können.
1
kursiv 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ür
den 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 Applikation
individuell festgelegt werden, welche Netzwerkdienste diese nutzen darf.

Sandbox (SB) Die Sandbox oder kurz SB kontrolliert die Dateisystemzugriffe einzelner
Applikationen. 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 Verwaltung
von Prüfsummen für Dateien im System. Jeder Benutzer kann individuell Prüfsum-
men verwalten. Änderungen an Dateien können dadurch festgestellt werden. Darüber
hinaus 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 Inhalt
nicht mehr mit der registrierten Prüfsumme übereinstimmt.

Playground (PG) Der Playground bietet die Möglichkeit, Programme so zu starten, dass
sie keine Änderungen an existierenden Dateien vornehmen können. Versucht ein
Programm dennoch Änderungen zu machen, dann wird die Datei kopiert und die
Änderungen werden nur auf der Kopie vorgenommen. Das Playground Modul sorgt
dafü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 den
Benutzer 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 laufende
Anwendung 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 Bedeutung
Text ¤
§
Text für Aus- oder Eingaben, Dateinamen
Enter ¥
¦ Einzelne Taste auf der Tastatur
Objekt Name eines Objektes im GUI (z.B. Menü) oder eines Programms
Begriff Kennzeichnet einen Begriff des Glossars
Darüber hinaus finden zahlreiche Abkürzungen aus dem Netzwerk- und Security-Bereich
Verwendung, 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 von
Anoubis 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. Daran
schließt sich eine detaillierte Vorstellung der einzelnen Sicherheitsmodule und de-
ren spezifischen Einstellungsmöglichkeiten an. Die umfassenden Möglichkeiten zur
Konfiguration 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 Beschreibung
des LogViewer und Loggingfunktionen von ALF, SB und SFS.
Fehlerbehandlung Anhand von ausgewählten Szenarien beschreibt dieses Kapitel die
notwendigen 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 Anoubis
gegeben, 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ür
den Playground spezifiziert.
Glossar Ein Großteil der im Handbuch verwendeten Begrifflichkeiten kann im Glossar in
Anhang E nachgeschlagen werden.


6 1. Einführung


I NSTALLATION
• 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 Benutzeroberﬂä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 Anoubis
installiert ist, ist es auch weiterhin möglich, einen Kernel ohne Anoubis-Funktionalität zu
booten.

2.1.1 Empfohlene Systemkonﬁguration

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 das
Speichern von sehr vielen kleinen Dateien optimiert sein. Hier bietet sich zum Beispiel
eine 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 und
mit Hilfe von loopback-Mounts als Partition gemountet werden.

Playground Spool Verzeichnis
Wenn Sie vorhaben, Inhaltsscanner zusammen mit dem Playground einzusetzen, dann
muss 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 freier
Platz zum Zwischenspeichern von Dateien vorhanden sein. Normalerweise liegt dieses
unter /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. 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. Wenn
die default Bootloader-Konfiguration verwendet wird, wird ab dem nächsten Reboot die
Anoubis-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 ihrer
Distribution 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 entsprechend
der Ausgabe des oben genannten Kommandos anzupassen.
Die Komponenten anoubisd und xanoubis greifen auf zusätzliche Dateien und Pfade
zurü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üssen
die 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 aktuelle
Verzeichnis heruntergeladen wurden, können sie mit dem folgenden Kommando installiert
werden.

yum install *.rpm --nogpgcheck

Hierbei kann es zu Konflikten mit Paketen kommen, die auf dem System installiert und
aktueller 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 Reboot
die Anoubis-Security-Suite aktiviert. Ansonsten muss der neue Kernel noch in →Grub
oder →Lilo konfiguriert werden.
schränkt werden:



12 2. Installation

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

zurück, die nicht im Rahmen der Deinstallation der Pakete entfernt werden. Löschen Sie
die Dateien und Verzeichnisse, die unter den Punkten B.2.1 und B.3 genannt werden, um
eine 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 aktuelle
Verzeichnis heruntergeladen wurden, können sie mit folgenden Kommandos installiert
werden.
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-Konﬁguration verwendet wird, wird ab dem nächsten Reboot
die Anoubis-Security-Suite aktiviert. Ansonsten muss der neue Kernel noch in →Grub
oder →Lilo konﬁguriert werden.
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


2.5 OpenBSD
Zur Installation des OpenBSD Release von Anoubis brennen Sie das ISO-Image auf CD
und 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 beispielhaft
durchgefü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 Konﬁguration 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 Sie
am Shell-Prompt das Kommando reboot ein.

# reboot
syncing disks... done

schränkt werden:


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 und
anoubis-gui sowie die zugehörigen Konﬁgurationsdateien 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 Dateien
und 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 entfernt
werden.

2.6 Ubuntu
Die Anweisungen in diesem Abschnitt gelten sowohl für das Release Ubuntu 9.0.4 “Jaunty
Jackalope” 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 drei
Pakete (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. Wenn
die default Bootloader-Konﬁguration verwendet wird, wird ab dem nächsten Reboot die
Anoubis-Security-Suite aktiviert. Ansonsten muss der neue Kernel noch in →Grub oder
→Lilo konﬁguriert 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

schränkt werden:



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-


GUI Ü BERBLICK
• Statusanzeige
• Trayicon
• Navigationsleiste
• Hauptfenster
• Infoleiste
• Werkzeuge
• Benachrichtigungen und
Anfragen
• Einstellungen

Kapitel 3

GUI Überblick

3.1 Statusanzeige

Wichtige Informationen werden in der Statusanzeige, unabhängig von der aktuell aktiven
Ansicht, 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 Benutzeroberﬂäche.
.

22 3. GUI Überblick

3.2 Navigationsleiste
In der links unterhalb der Statusanzeige angeordneten Navigationsleiste befinden sich
Auswahlfelder, 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 hinsichtlich
der zu überwachenden Dateien auf dem Rechner vorgenommen werden. Darüberhinaus
ist die vereinfachte Übersicht der aktiven SFS-Regeln dargestellt. Im Bereich SB befin-
det sich die vereinfachte Übersicht der aktiven Sandbox-Regeln. Der Bereich Anoubis
ermöglicht das Arbeiten mit Benachrichtigungen und Anfragen.

3.3 Hauptfenster
Innerhalb der Module SFS und Anoubis erfolgt die Navigation mittels Reitern, die am
oberen Ende des Hauptfensters dargestellt werden. Beispielsweise werden im Modul SFS
innerhalb des Reiters Browser sowohl die Sicht auf das Dateisystem dargestellt als auch
die 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 das
Ergebnis beim Laden einer Regeldatei hier dargestellt.

3.5 Werkzeuge
Im rechten unteren Teil des Anoubis-Hauptfensters befinden sich Schaltflächen, die den
direkten Zugriff auf den RuleEditor, LogViewer und den Wizard erlauben. Der RuleE-
ditor ermöglicht hierbei sehr feingranulare Einstellungsmöglichkeiten zu den Regelsätzen
der jeweiligen Anoubis-Module. Im LogViewer werden alle Logmeldungen, Alarme und
Eskalationen zugänglich gemacht. Der Wizard stellt eine Alternative zur Regelerstellung
im RuleEditor dar. Hierbei wird der Benutzer bei der Erstellung von Regeln unterstützt und
begleitet. 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 zur
Verfü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 der
Maus auf das Symbol führt in diesem Fall direkt in das Fenster zur Beantwortung der
entsprechenden 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 das
Symbol 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 - das
Kontextmenü der graﬁschen Benutzeroberﬂäche aktiviert werden. Dieses bietet sowohl
eine 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 oder
verhindert werden soll.

3.7.1 Benachrichtigungen

Im Navigationselement Anoubis erscheint unter dem Reiter Benachrichtigungen (siehe
Abbildung 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 beantwortet
werden. Nachdem über die Dauer der Gültigkeit entschieden wurde, kann mittels der
Schaltﬂä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 betrachtet
werden. 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 hinsichtlich
des 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 kann
ebenfalls 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. Hier
kann 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äche
fü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 des
Regelsatzes an den Daemon überprüft.

3.8.5 Verbindung
Beim Aktivieren der Einstellung Automatisches Verbinden zum Daemon verbindet sich
die GUI beim Start automatisch mit dem Daemon.

3.8.6 Tool Tips
Wird diese Einstellung aktiviert, so werden dem Benutzer weitergehende Informationen zu
den einzelnen Schaltﬂächen des GUI angezeigt, wenn der Mauszeiger für die Dauer der
eingestellten Zeit in Sekunden auf diesen verweilt.

3.9 Upgrade Dialogbox
Beim Verbinden mit dem Anoubis Daemon oder nach Abschluss der Installation neuer
Software im Rahmen eins Upgrades wird überprüft, ob Signaturen registriert sind, die
jetzt angepasst werden müssen. Ist dies der Fall wird dem Benutzer eine Dialogbox (siehe
Abbildung 3.3) angezeigt, um ihn auf diese Änderungen hinzuweisen. In diesem Dialog
hat er die Möglichkeit, die Option zum Wiederanzeigen der Dialogbox auszuschalten, den
Dialog ohne weitere Aktionen zu beenden oder den SFS Browser zu öffnen, um dort ein
Update der signierten Prüfsummen vorzunehmen.
Der Dialog wird standardmäßig angezeigt, allerdings höchstens einmal innerhalb von 60
Sekunden. Er kann im Anoubis Main Panel unter der Option Upgrade - Enable Upgrade
Message ausgeschaltet werden. (siehe Abbildung 3.4).
Manche Distributionen installieren im Rahmen eines Upgrades jede Softwarekomponente
einzeln. Wenn dies der Fall ist, kann es vorkommen, dass der Dialog für einen Upgrade
Vorgang 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 mehr
zugegriffen werden kann. Diese Zugriffsverweigerung kann die Funktionalität des Systems
beeinträchtigen.


KONFIGURATION
• Allgemein
• Kontexte und
Kontextwechsel
• 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 einzelne
Anwendungen enthalten. Zusätzlich kann eine Konfigurationsdatei verwendet werden Für
jeden Nutzer gibt es zwei voneinander unabhängige Regelsätze:

Der Administratorregelsatz mit Priorität 0 Dieser Regelsatz wird vom Administrator
vorgegeben und kann vom Nutzer nicht verändert werden. Die darin enthaltenen Re-
geln geben den Rahmen vor innerhalb dessen der Nutzer für einzelne Anwendungen
noch 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 nach
seinen 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 aber
auch 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. Konﬁguration

# 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) Regelsatzdatei
vorgenommen wurden, kann diese vor der eigentlichen Aktivierung auf syntaktische
Korrektheit 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 Datei
mit 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 und
nicht 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 aktiv
sind. Dazu listet das folgende Kommando die Prozesse des aufrufenden Benutzers
auf.

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 bis
zum 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 jeweils
die ID des aktiven Regelsatzblocks des Admin- bzw. des Benutzer-Regelsatzes
ausgegeben. Die ID-Nummern ﬁnden sich auch in der Ausgabe des Kommandos
anoubisctl 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 Prozesses
sein, es sei denn, der aufrufende Prozess hatte keine entsprechendecontext new
Regel.
Wird die Option -v zweimal angegeben, werden zu den Dateinamen zusätzlich auch
die Prüfsummen der Programmdateien ausgegeben.
Mit Hilfe der Option -u kann sich der Root-Benutzer auch die Prozesse von anderen
Benutzern 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 der
folgenden 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 wird
der Neustart so lange verzögert, bis ein gerade laufendes Upgrade beendet ist.
anoubisctl reload Die Konﬁguration des Anoubis-Daemon wird neu geladen.
anoubisctl status Der Status des Anoubis-Daemon wird überprüft und ausgegeben.



• Passphrase des privaten Schlüssels von root zur Verfügung stellen
Wenn der mit Hilfe der rootkey Option des Anoubis-Daemon konﬁgurierte 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 verwenden
kann. 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 Version
der 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 dem
aktuellen Stand verglichen, aufgelistet und entfernt werden.

• Hinzufügen
Das 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 Match
ausgegeben. Sollten die Prüfsummen nicht übereinstimmen, so wird Checksum
Missmatch zurück gegeben.

$ sfssig validate /pfad/zur/datei
Checksum Match

• Auﬂisten
Die im Prüfsummenbestand zur Überwachung registrierten Dateien können mit dem
Kommando list ausgegeben werden. Mit Hilfe verschiedener Filteroptionen können
auch verwaiste Einträge aufgefunden werden.

$ sfssig list /pfad/zur/
/pfad/zur/datei1
/pfad/zur/datei2
/pfad/zur/datei3


4.1. Allgemein 35

• Entfernen
Ein Eintrag kann aus dem Prüfsummenbestand mit dem Parameter del entfernt wer-
den.
$ sfssig del /pfad/zur/datei

• Export
Um den eigenen Prüfsummenbestand in eine Datei zu sichern, wird das Kommando
export verwendet.

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

• Import
Der 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önnen
diese 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 die
einzelnen Filteroptionen erläutert werden.

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

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

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



• –upgraded
Diese 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 einer
Datei abgelegt werden. Hier durch können auch dann Aussagen über systemkritische
Dateien 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. Mittels
Extended-Attributes kann dem Kernel aber auch mitgeteilt werden, bestimmte Dateien
bei 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 von
Anoubis, 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 Manpage
playground(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ätzlich
die Option -X empfohlen. Diese sorgt dafür, daß die Anwendung in einer isolierten
X11 Umgebung gestartet wird. Dadurch wird klarer ersichtlich, welche Programme in
einer Playground-Umgebung laufen und welchen nicht.
Zum Aufbau der X11-Umgebung wird ein Skript in verwendet, das zusammen mit
dem 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 Administrator
editiert werden. Insbesondere kann dort die Displaygröße der X11-Umgebung von
1024x768x24 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 Playground
weder Dateien übernommen noch gelöscht werden können. Entsprechend kann auch
der 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’ angewandt
werden.

• 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>



Die Option –ignore-recommended bzw. -F erlaubt die Übernahme von Dateien trotz
Warnungen von ’empfohlenen’ (recommended) Inhaltsscannern (Virenscanner bei-
spielsweise). Ist ein solcher jedoch als required (erforderlich) konfiguriert und gibt
dieser 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 mehr
als 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 auch
daran, dass der darauf folgende Aufruf des ls-Kommandos die Datei als im System
vorhanden 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 entfernt
werden:
$ 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 nur
noch die Datei /tmp/bar vorhanden.
Es können Fälle auftreten, bei denen sich zwar Dateien und Verzeichnisse in einem
Playground befinden, sie aber nicht mehr physikalisch existieren. Solche Situationen
entstehen, wenn Playgrounds Dateien referenzieren, die auf nicht-persistenten Datei-
systemen (wie zum Beispeil tmpfs) gespeichert werden. Nach einem Reboot gehen
diese Dateien verloren. Um diese Dateien trotzdem aus einem Playground löschen
zu können, kann das delete-Kommando mit der Option -f aufgerufen werden. Jetzt
erwartet 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-
schlie¨ end die gesamte Playground-Sitzung aus der Liste ausgetragen.
s
Ferner unterstützt das playground-Kommandozeilenwerkzeug, wie anoubisctl und
sfssig die Optionen -h, um die möglichen Optionen und Kommandos (bzw. deren
Syntax) 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 mehr
referenziert 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 Reihe
von Blöcken. Jeder Block gilt für eine oder mehrere Anwendungen und enthält einen Satz
von 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 diese
Anwendung 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, findet
Anwendung, wenn in einem Modul kein anderer Block vorhanden ist, der zum aktuellen
Kontext 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 als
Kontext übernommen werden.
Der Kontext eines ausgeführten Programms muss also nicht notwendigerweise mit
den Daten des ausgeführten Programms übereinstimmen.

4.2.2 Aufbau von Kontext-Regeln
Regeln für den Kontextwechsel sind wie folgt aufgebaut:



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 zur
Identiﬁkation der Applikation verwendet werden soll. Mehre-
re Applikationen werden durch Komma voneinander getrennt.
Statt einer Liste von Applikationen, kann auch das spezielle
Schlü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 diesem
Kontext laufen: Das Flag nosfs bewirkt, dass Zugriff dieses
Prozesses auf das Dataisystem nicht den SFS-Regeln unter-
liegen. Das Flag pgforce erzwingt einen neuen Playground
für den Prozess, falls dieser nicht bereits in einem Playground
läuft.

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

Unmittelbar vor einem Block Hier geben die Anwendungen in der Liste an, für welche
Kontexte 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 eine
ausgefü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 sinnvoll
einen Kontextwechsel durchzuführen, sondern auch dann, wenn bestimmte Dateien (in
der 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üsselwort
open ersetzt wird.


4.3. ALF 41

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

4.3 ALF
Die Konﬁguration 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. 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 einem
Playground läuft.
action Die Aktion, die beim Zutreffen der Regel ausgeführt werden
soll. Mögliche Aktionen sind allow (Zulassen der Verbindung),
deny (Unterbinden der Verbindung) und ask (Nachfrage an
den Benutzer).
operation Netzwerkoperation, auf die die Regel zutreffen soll. Mögliche
Operationen 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 hierbei
eine höhere Priorität als „log”.
capability Angabe, ob die Regel Zugriff auf privilegierte Sockets haben
soll. Mögliche Werte sind raw (RAW Socket), other (andere
Sockets) 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ür
IPv6.
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 Absenderinformation
folgt.



to Schlüsselwort, auf das die Angabe einer Empfängerinformati-
on folgt.
address Adressangabe für Absender- und Empfängerinformation. Es
wird 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 Hilfe
von 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 Regel
wird 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 einem
SSH-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 an
den DNS-Server 192.168.0.1 gestellt und die Antworten empfangen werden. Ein anderer
Computer mit der IPv6-Adresse fe80::200:12ff:fe34:5678 darf SSH-Verbindungen auf den
lokalen 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 vom
System verwalteten Datenbank einzutragen. Diese Prüfsummen können optional signiert
werden, 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-Regeln
einzuschrä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:



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öglichkeiten
stehen zur Verfügung:
• „self”: Eine vom Nutzer selbst hinterlegte unsignierte
Prü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 mit
der angegebenen Key-ID signierte Prüfsumme.

valid action Die Aktion wird angewandt, falls die Prüfsumme zum Inhalt der
Datei 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üfsumme
im System gefunden wurde.
action Eine Aktion besteht aus einer optionalen Anweisung, mit der
eine 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 wird
mit der nächsten Regel fortgesetzt.

„default” Schlüsselwort, das eine Default-Regel kennzeichnet. Default-
Regeln enthalten lediglich ein Pfadpräfix und eine Aktion. Eine
Prüfsumme ist nicht notwendig. Eine Default-Regel findet nur
Anwendung, 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 (uid
0) vorhanden ist. Bei einer ungültigen Prüfsumme, ist der Zugriff verboten, ansonsten
wird 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. Ist
keine eigene Prüfsumme vorhanden, dann wird anhand der verbleibenden Regeln
entschieden.
• 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 folgenden
zwei 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. Ändert
sich 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 dann
unter dem echten Namen der verlinkten Datei in die Prüfsummen-Datenbank eingetragen
werden. 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 Virenscanner
sinnvoll 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 eventuell
hinterlegten 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 muss
das Flag nosfs angegeben werden.



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 konfiguriert
haben, 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 einem
Playground läuft.
action Eine Aktion besteht aus einer optionalen Anweisung, mit der
eine 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 einem
Pfadprä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 der
selben Form, wie es auch im Modul SFS möglich ist, kann die
Gültigkeit der Regel auf Dateien eingeschränkt werden, für die
eine gültige Prüfsumme aus der durch subject angegebenen
Quelle vorliegt. Wenn die Regel für alle Dateizugriffe unabhän-
gig von eventuell hinterlegten Prüfsummen gelten soll, dann
darf 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 eine
Datei zu erlauben, das Ausführen aber zu verbieten, sind also
zwei 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, wenn
keine 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 gelesen
und 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. Schreibzugriffe
sind 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



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 es
notwendig 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 Zertiﬁkat 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 die
Möglichkeit, sein Schlüsselpaar mit xanoubis zu erzeugen. Details dazu sind im Ab-
schnitt 5.7.4 zu ﬁnden.


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 Kommando
anoubis-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ültige
Signaturen 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 die
vorhandene 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. Dies
ist vor allem für den Root-User sinnvoll, dem ja in der Regel in diesem Schritt sowohl
der ö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üssel
installiert wird.

4.8 Regelwizard
Der Administrator darf Standard ALF- und SB-Freigaben erstellen. Klickt der Benutzer im
Regelwizard auf add default services (ALF) bzw. add default permissions (SB), dann
werden die entsprechenden Freigaben geladen.
Die Listen werden im Verzeichnis /etc/anoubis/profiles/wizard/ abgelegt. Die
Datei 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



# 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. Endet
eine 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 oder
xanoubis, verwendet wird. Der standardmäßig eingestellte
Pfad 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 deﬁniert, 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 ist
der 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 der
Beginn 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 ist
der Beginn des Upgrades. Wird dieser Prozess geschlos-
sen ist das Upgrade beendet. Der Pfad zur Binärdatei muss
unter der Option upgrade_trigger eingetragen werden.

upgrade_trigger Hier kann eine durch Komma separierte Liste von Auslösern für
ein Upgrade angegeben werden. Im Falle von upgrade_mode
= off muss nichts angegeben werden. In allen anderen Fällen
muss die Liste mindestens einen Eintrag beinhalten. Ist mehr als
ein Auslöser angegeben, muss nur einer zutreffen, um den Up-
gradestart auszulösen.
rootkey Mit dieser Option kann dem Daemon der private Schlüssel des
root-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 Passphrase
geschützt ist, dann muss sie mittels anoubisctl zur Verfügung
gestellt werden.



rootkey_required Hier wird das Verhalten festgelegt, wenn die Upgrade-Prozedur
startet, aber der private Schlüssel des root-Users noch nicht zur
Verfügung steht. Dieser Fall tritt ein, wenn die mit rootkey konfi-
gurierte Datei nicht existiert, oder die Passphase noch nicht zum
Daemon gesendet wurde. Mögliche Werte sind:
• true Wenn der private Schlüssel benötigt wird, dann wird
der Upgrade-Prozess kein Lock auf die Paketdatenbank be-
kommen, und er beendet sich mit einer entsprechenden
Fehlermeldung.
• false Durch root signierte Prüfsummen werden nicht auto-
matisch aktualisiert. Er muss es, wie jeder andere Benutzer
auch, 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 dem
Anoubis-Daemon authentisieren sollen, wenn sie eine Verbin-
dung aufbauen. Mögliche Werte sind:

• enabled Die Authentisierung ist aktiviert. Die Verbindung
wird durch den Anoubis-Daemon nur dann akzeptiert, wenn
der Client den korrekten Schlüssel verwendet.
• optional Die Authentisierung ist genau dann aktiv, wenn
ein Zertifikat für den anfragenden Benutzer am Anoubis-
Daemon hinterlegt wurde. Konnte der Anoubis-Daemon
kein Zertifikat finden, dann wird die Verbindung immer ak-
zeptiert.
• off Es wird keine Authentisierung vorgenommen. Client-
Verbindungen werden durch den Anoubis-Daemon immer
akzeptiert.

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 jeden
Scanner festlegen, ob dieser zwingend ausgeführt werden muss (required) oder nur
empfohlen ist (recommended).

commit Mit dieser Option wird ein Inhaltsscanner konfiguriert. Die
commit Option kann mehrmals verwendet werden, um mehrere
Scanner 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 allow
und 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ährlich
angezeigt wird. Der Name kann auch Leerzeichen enthal-
ten.

In der Standardeinstellung ist das Übernehmen von Dateien aus
einem Playground nicht möglich. Um ein Übernehmen aller Da-
teien ohne Inhaltsscan zu ermölichen, kann die folgende Zeile
verwendet werden:
commit = required allow Immer akzeptieren
scanner_timeout Diese Option bestimmt, wie lange ein Inhaltsscanner pro Datei
benötigen darf, bevor er abgebrochen wird. Der Wert wird in Se-
kunden angegeben, wird aber nur mit einer Granularität von etwa
10 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 einen
Coredump erstellen soll. Mögliche Werte sind:
• true Die Erstellung von Coredumps ist aktiv.
• false Es werden keine Coredumps erstellt.
Der Standardwert ist false.



policysize Legt die maximale Größe einer Policy fest. Der Anoubis-Daemon
lehnt Policies ab, die größer sind, als der festgelegte Wert. Wird
der 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 das
von Anoubis verwendete Schlüsselpaar sowie ein Versionsmanagementsysteme für die
Policies. Manipulationen an diesem Verzeichnis könnten daher weitreichende Folgen
auf die Sicherheit des Systems haben. Es ist somit anzuraten, dieses Verzeichnis nicht nur
mit Unix-Dateirechten abzusichern, sondern auch durch Anoubis. Eine Policy für .xanoubis
kö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äufig
benutzte 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 über
den Socket /var/run/nscd/socket eine Anfrage an den nscd. Daraufhin wird nscd
ggf. eine DNS-Anfrage (Port 53) starten, und das Resultat an die Anwendung zurück-
schicken. Kann keine Verbindung zum nscd aufgebaut werden, erzeugt die Anwendung
selbst 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 muss
dem 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 Prozessgrenzen
hinweg zur Verfügung. Sicherheitslücken in Programmen können über IPC-Mechanismen
ausgenutzt werden. System-V IPC wird derzeit von Anoubis nicht betrachtet. Programme,
die solche Dienste anbieten, müssen selbst geeignet eingeschrängt werden.


B ETRIEB
• Eskalationen
• RuleEditor
• Regelwizard
• LogViewer
• Application Level Firewall /
ALF
• Sicheres Filesystem / SFS
• Proﬁle
• Versionskontrolle

Kapitel 5

Betrieb

5.1 Anzeigen und Beantworten von Eskalationen
Unter bestimmten Umständen entscheidet Anoubis nicht selbst, ob eine Operation eines
Programms 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 Anwender
entschieden 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 einem
Fragezeichen.

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 Nachrichten
aus.
In dem Auswahlmenü oben im Hauptfenster sollte bereits “aktuelle Nachfragen” vorein-
gestellt sein. Dadurch werden nur Eskalationen angezeigt, die noch nicht entschieden
wurden. Darunter werden Informationen über die erste Eskalation angezeigt. Mit Hilfe der
Navigationspfeile direkt unterhalb des Auswahlmenüs kann zu anderen Eskalationen ge-
wechselt werden.
Mit Hilfe der Schaltﬂächen erlauben oder verbieten kann die Eskalation entschieden wer-
den.
Dabei besteht für die meisten Eskalationen die Möglichkeit, eine temporär oder dauerhaft
gü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 werden
abhängig vom Ereignis verschiedene Möglichkeiten angeboten, um die erstellte Regel
genauer kontrollieren zu können.
Darüber hinaus kann durch Auswahl der entsprechenden Checkbox erreicht werden, dass
unmittelbar 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. Dies
kann verschiedene Ursachen haben:

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

• Die Regel, die das Ereignis auslöst, befindet sich nicht in dem Block, der zum Kontext
der 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 neue
Regeln 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 überschrieben
werden sollen. In diesem Fall wird der existierende Regelblock überschrieben und durch
den Wizard neu erstellt. Ansonsten wird die Konfiguration des Moduls übersprungen.
Nach Beendigung des Wizards werden die neuen Regeln im Regeleditor angezeigt. Dort
kö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üssen
im Regeleditor konfiguriert werden. Der Regelwizard ist nicht in der Lage, die komplette
APN abzubilden.

5.2.1 Regelkonfiguration einer Anwendung mit dem Regelwizard

Das folgende Beispiel zeigt die Konfiguration der Anwendung Lynx unter Zuhilfenahme
des Regelwizards. Hierbei werden in den einzelnen Phasen Regeln für den Kontext, die
ALF sowie Sandbox erstellt.
Zu Beginn des Konfigurationslauf begrüßt Sie das Startfenster des Regelwizards. Von
hier aus werden Sie durch die einzelnen Einstellungsmöglichkeiten geführt, die die jeweils
aktuell vorzunehmenden Einstellungen im aktuellen Dialog aufweisen. Dabei gibt Ihnen
die linken Seite des Regelwizard-Dialogs stetig Auskunft über die aktuell bearbeiteten
Einstellungen (Kontextwechsel, Alf, Sandbox) und etwaige Kontextinformationen (z.B. der
Name 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 bei
Bedarf jederzeit in die vorhergehenden Dialoge des Regelwizards.


5.2. Regelwizard 61

Abbildung 5.1: Regelwizard: Anwendung Lynx wurde zur Konﬁguration 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 Schaltﬂäche Aus-
wahl erfolgen.


62 5. Betrieb

Abbildung 5.2: Regelwizard: Einstellungen zum Kontextwechsel

Die Einstellungen zum Kontextwechsel bestimmen welche Berechtigungen Anwendungen
haben, die von der konﬁgurierten 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 Hauptanwendung
gelten (ja). Optional können durch das Auswählen der Checkbox Ausnahmen zulassen
feingranulare 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, clientseitige
Netzwerkzugriffe durchzuführen, konﬁguriert. Die Auswahl der Option ja erlaubt der An-
wendung uneingeschränkten Netzwerkzugriff. Bei Wahl der Option eingeschränkt (Stan-
dardwerte) werden vordeﬁnierte Dienste erlaubt, alle weiteren führen zu einer Nachfra-
ge beim Benutzer. Mittels der Option eingeschränkt können feingranulare Einstellungen
vorgenommen 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 Einstellungen
zum eingeschränkten Netzwerkzugriff der Anwendung vornehmen. Bei Wahl der Schalt-
fläche Standarddienste hinzufügen werden vordefinierte Dienste hinzugefügt, die in
der 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 tragen
die 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 unter
Einbeziehung vordefinierter Berechtigungen durch die Wahl der Option Ja, Regeln aus
Standardwerten 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 vordeﬁnierte Zugriffsrechte eingeräumt, alle weiteren
fü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 der
nä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 der
Schaltflä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äche
Verzeichnis auswählen. Bei Auswahl der Schaltfläche Standardberechtigungen werden
vordefinierte 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 Dateisystemzugriffs
können im Folgenden vorgenommen werden. Die Optionen bieten hierbei die gleichen
Unterscheidungsmöglichkeiten wie die schon beim lesenden Dateisystemzugriff erwähn-
ten.


5.2. Regelwizard 71

Abbildung 5.11: Abschluss der Konﬁguration

Nach Abschluss der Konﬁguration besteht die Möglichkeit, die erstellten Regeln sofort zu
aktivieren. 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. Das
Symbol 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 einer
Applikation zu einem Verbindungsaufbau eingegangen ist, erscheint das Anoubis Tray-
Icon mit dem entsprechenden Meldungssymbol. Das Symbol in der Menüleiste wird erst
nachdem 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 der
Schaltﬂä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 die
Module ALF, Sandbox und Kontext durch Auswahl der Schaltfläche Erstellen neu erzeugt
werden.
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 dann
die bereits vorhandenen Filterregeln für diese Applikation angezeigt. Außerdem stehen im
Drop-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ür
die 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ählt
werden. In den Reitern unterhalb der linken Liste können dann die Anwendungen, für die
diese Regel gelten soll, verändert werden. Gleichzeitig werden die einzelnen Filterregeln
fü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 bearbeitet
werden 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 rechten
Liste die entsprechende Filteroption ausgewählt. Der Reiter unterhalb der Liste verändert
sich entsprechend der Regel, dort können die gewünschten Änderungen vorgenommen
werden.
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ßen
gilt. 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 der
Schaltfläche Entfernen gelöscht. Administratorregeln sowie der SFS-Block können nicht
gelö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 der
linken Liste grau hinterlegt und mit (A) gekennzeichnet.


74 5. Betrieb

Diese Regeln können von einem nicht privilegierten Benutzer nur eingesehen, aber nicht
verändert werden. Die zugehörigen Tabs sind daher deaktiviert.
Der Administrator hat die Möglichkeit, Administratorregeln von allen Nutzern anzuzeigen
und zu verändern. Dazu muss der gewünschte Nutzer mit Hilfe der Auswahl links oben im
Regeleditor 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 einige
Schaltflä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 angezeigte
Regelsatz an den Anoubis-Daemon gesendet und dadurch tatsächlich aktiv.
Neuladen vom Daemon Aktualisiert den Regelsatz im Regeleditor, sodass er sicher mit
dem im Anoubis-Daemon aktiven Regelsatz übereinstimmt. In aller Regel geschieht
dies automatisch.
Importieren Bietet die Möglichkeit, einen Regelsatz aus einer Datei in den Regeleditor
zu laden. Der Regelsatz kann vorher in einem Editor erstellt oder zuvor mit Hilfe des
Exports 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 gelten
sollen. 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 verschiedene
Anwendungen 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 Regelblock
gelten soll. Es kann mehr als eine Anwendung zu der Liste hin-
zugefügt werden. Wurde keine Anwendung angegeben, so gilt
automatisch der Wert any, das bedeutet, dass dieser Block ge-
nau dann gelten soll, wenn vorher kein passender Regelblock
fü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ängigkeit
zu der Prüfsumme bzw. einer Signatur der dazugehörigen An-
wendung. Folgende Einstellungen können hier vorgenommen
werden:

• unabhängig Bei der Auswahl des Regelblocks spielt die
Prüfsumme und Signatur keine Rolle.
• Prüfsumme Die Prüfsumme der Anwendung muss mit der
im SFS-Browser hinterlegen übereinstimmen.
• Selbst signiert Die Signatur der Anwendung muss
mit der Signatur, die der aktuelle Benutzer im SFS-
Browser hinterlegt hat, übereinstimmen.
• Uid Die Prüsumme der Anwendung muss mit der, die der
Benutzer mit der angegebenen UID im SFS-Browser hin-
terlegt hat, übereinstimmen.
• Schlüssel Die 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:
SFS 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- Für diese Anwendung wird eine Playground-Umgebung er-
ten zwungen (siehe Abschnitt 5.9.3).
Diese Einstellung kann man ausschließlich in Kontext-
Diese Regel nur für Der Regelblock ist nur dann gültig, wenn der dazugehörende
Playgroundprozesse Kontext bereits in einer Playground-Umgebung läuft (siehe Ab-
anwenden schnitt 5.9.3).
Diese Einstellung kann man nicht in Kontext-


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 einigen
allgemeinen Informationen über die Prozesse eine kurze Übersicht über alle für Anoubis
relevanten 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 angezeigt
werden 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 Bedeutung
der Spalten in der Prozessliste ist dabei wie folgt:

Spalte Bedeutung
Prozess ID Die Prozess-ID des Prozesses
Benutzer 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 jeweils
durch den Benutzer konfigurierte Regeln sowie vom Admini-
strator vorgegebene Regeln geben.
Playground ID Wenn der Prozess in einem Playground läuft, wird hier die
Playground-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, um
detaillierter 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 reale
und 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 die
Auswahl der Applikationsregeln bestimmen. Es werden drei
unter 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 informativen
Charakter 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 verwendet
werden.
• 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 werden
die vom Benutzer konfigurierten Regeln, im rechten die vom
Administrator vorgegebenen Regeln angezeigt. Durch einen
§ ¤
Klick auf die Schaltfläche ¦ Bearbeiten... ¥öffnet sich der Re-
geleditor mit der angezeigten Regel, so dass diese bearbeitet
werden 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ür
das 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 den
Benutzerregeln haben.
Die ALF filtert alle ein- und ausgehenden Netzwerkverbindungen von Anwendungen und
fü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:

Aktion / Log Angabe der Aktion, die die ALF im Falle der Übereinstimmung
der Filterregel durchführen soll. Hierbei steht „erlauben” für
das Zulassen der Netzwerkverbindung, „verbieten” für das
Unterbinden 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 einen
normalen 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 die
Regel auf eingehende Verbindungen angewendet werden soll,
„ausgehende” gibt an, dass sie für ausgehende Verbindungen
zutrifft.
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 Transmission
Protocol („sctp”).


5.7. SFS 79

Adresse Angabe der Quell- und Zielradresse und Quell- und Zielport der
zu ﬁlternden Netzwerkverbindung. Die Adresse wird in Form
einer IP-Adresse der gewählten Adressfamilie erwartet. Ports
werden dezimal in einem Bereich von 1 bis 65535 angegeben.
Capability Angabe für den Filterregeltyp Capability. ALF-Regeln können
auf Verbindungseigenschaften oder auf angeforderte Privilegi-
en angewendet werden. Hier bedeutet „capability”, dass
sich die Regel auf angeforderte Privilegien (wie RAW-Sockets)
auswirkt, „andere”, dass die Entscheidungsparameter sich auf
andere Verbindungstypen auswirkt und „alle” bezieht sich auf
alle 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 einer
Datei 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-Browser
verwalten.

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

Das SFS-Modul verwaltet für jeden Benutzer einen Bestand an Prüfsummen zu Dateien
im System. Eine vom Administrator festgelegte Prüfsumme für eine Datei gilt zusätzlich
fü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 SFS
Regel zur linken Liste im RuleEditor nicht hinzugefügt werden. Durch Verbinden mit dem
Anoubis-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 oder
durch 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

Gültig/Ungültig/ Angabe der duchzuführenden Aktion im Falle eines gültigen
Unbekannt oder ungültigen Ergebnisses einer Validierung oder wenn der
Zustand der Datei unbekannt ist. Als mögliche Aktion für jedes
Ergebnis kommen „erlauben”, „verbieten”, „nachfragen”
oder „fortführen” in Betracht. Im Falle von fortführen wird
die 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 das
Unterlassen eines Log-Eintrags, „normal” für einen normalen
Log-Eintrag und „kritisch” für Alarme.
Subject Angabe über den Pfad zur Datei und deren Subject. Für
die „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 im
SFS-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 Falle
von „Schlüssel” wird eine Schlüssel-ID angegeben, die ei-
ne Signatur für diese Datei im SFS-Modul hinterlegt hat. Ein
Subject einer KeyID sollte dann folgender Form entsprechen
85326181333deb31f8711b7cd6da563273100812

5.7.3 Einführung in den SFS-Browser

Der Browser (Abbildung 5.14) wird verwendet, um die Soll-Werte von Prüfsummen des
angemeldeten Benutzers zu verwalten. Zusätzlich kann ein privater Schlüssel und das
dazugehörige Zertifikat hinterlegt werden, um das Signieren der Prüfsummen aktivieren
zu 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 das
Basisverzeichnis 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 sich
von den registrierten Prüfsummen unterscheiden.

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

• Durch ein Upgrade veränderte Dateien Dateien, die durch ein
Betriebssystem-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, kann
das 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 ein
Schlüsselpaar, das im Tab Schlüssel (siehe Abbildung 5.15) konfiguriert wird. Um eine
Signatur 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 Signatur
an.
??? 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 mit
der lokal berechneten Prüfsumme überein.
Die am Anoubis-Daemon registrierte Prüfsumme stimmt mit der
lokal 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ührt
Anwenden die Operation ausschließlich auf den selektierten Dateien aus. Ist ein gültiges
Schlü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 somit
entstandene Signatur wird ebenfalls am Anoubis-Daemon registriert.
Ist die ausgewählte Datei ein symbolischer Link, dann wird die Prüfsumme über den Link
berechnet. 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, bietet
das 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 am
Anoubis-Daemon entfernen.
Ist ein gültiges Schlüsselpaar hinterlegt, dann wird zusätzlich die Signatur, die mit diesem
Schlü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 Signieren
kann ausgeschaltet werden, obwohl ein gültiges Schlüsselpaar hinterlegt ist.
Importieren... importiert Prüfsummen/Signaturen aus einer Datei, Exportieren... schreibt
sie in eine Datei zurück. Es ist auf ein korrektes Daten-Format zu achten! Details sind im
Anhang C zu ﬁnden.

5.8 Sandbox

5.8.1 Überblick
Das Sandbox-Modul verwaltet für jeden Benutzer einen Satz von applikationsabhängigen
Zugriffsregeln. Zudem existiert ein Satz an Administratorregeln, welche Vorrang vor den
Benutzerregeln 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:
Aktion/Log Angaben hinsichtlich der Aktion, die das Sandbox-Modul
im Falle einer Übereinstimmung einer Regel durchführen
soll. 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 an
den Benutzer.


5.9. Playground 85

Subject Angabe über den Pfad zur Datei und deren Subject. Im Text-
feld Pfad können Datei- und Verzeichnisnamen angegeben
werden. Ü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, die
im Pfad steht, ohne Berücksichtigung der Prüfsumme zu. Für
die „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. Im
Falle von „Schlüssel” wird eine Schlüssel-ID angegeben, die
eine 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 im
Falle 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 Ablaufumgebung
mit einem virtuellen Dateisystem auszuführen. Schreibzugriffe in dieses Dateisystem wer-
den transparent abgefangen und sind nur für diese Applikation sichtbar. Auf Wunsch
können nach Beendigung der Applikation einzelne Dateien vom Playground in das rea-
le Dateisystem übernommen werden. Dabei kann der Administrator die Verwendung von
Inhaltsscannern 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 von
Inhaltsscannern 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 den
nächsten Abschnitten detailliert vorgestellt.


86 5. Betrieb

Durch das Starten einer Applikation im Playground wird dieser im Daemon angelegt. Der
Playground enthält den ursprünglichen Prozess und gegebenenfalls seine Kindprozes-
se. Bei schreibendem Zugriff auf das Dateisystem werden die Änderungen nicht sofort in
das eigentliche System (Produktivsystem) übernommen. Stattdessen werden die Ände-
rungen separat abgespeichert und über den Playground referenziert. Die vom Playground
geschriebenen 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 konﬁgurierten Inhaltsscannern
untersucht. Dadurch kann die Übernahme von Viren oder anderen schädlichen Inhalten
ins 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 Playground
zu 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 das
ausgewählte Kommando in einem Playground. Zusätzlich zum Kommando können Sie
eventuelle 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 Option
Programm in einer isolierten X Sitzung starten auszuwählen. In diesem Fall wird für das
Programm eine eigene X11 Sitzung in einem Fenster gestartet. In dieser läuft dann das
Playground Programm isoliert von der übrigen X11 Umgebung. Dadurch ist einfach zu
erkennen, welche Fenster zu welchem Playground gehören.
Allerdings ist die Größe der X11 Umgebung auf 1024x768 Pixel festgelegt und kann später
nicht 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 Kontext
angegebene 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. Ist
dies 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 Ihr
Programm 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. Die
gewählte Applikation wird nun immer in einem Playground gestartet.
Bei jedem Start der Applikation werden Sie von Anoubis über den automatischen Start
des Playgrounds benachrichtigt. Diese Nachricht wird als Anoubis-Alarm versandt und
erscheint 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 des
Produktivsystems sind, sofern von der Sandbox zugelassen, les- und schreibbar. Alle
Schreibzugriffe werden von Anoubis in den Playground umgeleitet. Dies ist für die Ap-
plikation transparent. Applikationen müssen also nicht an Anoubis angepasst werden, um
in 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 stattﬁnden. Die Entscheidung ob diese Umbenennung durchgeführt werden
darf, wird als Eskalation an Sie weitergegeben.

Abbildung 5.20: Eskalation beim Umbenennen von Verzeichnissen

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


5.9. Playground 91

5.9.5 Auﬂisten von Playgrounds
Sie können zu jeder Zeit die gerade existierenden Playgrounds anzeigen. Wählen Sie
dazu das Modul Playground. Im unteren Teil des Fensters erscheint nun unter dem Punkt
Playground Übersicht die Liste aller im System verfügbaren Playgrounds. Die Liste wird
nicht automatisch aktualisiert. Bei Bedarf können Sie die Liste mit dem Button Ansicht
aktualisieren 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 oder
Löschen von Dateien ist nur für inaktive Playgrounds möglich. Die Playgrounds anderer
Benutzer 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 den
Playground ö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ählen
Sie 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 das
weitere Vorgehen von der Art des Scanners ab. Ist der Scanner als erforderlich (requi-
red) konﬁguriert, so ist ein Übernehmen der Datei nicht möglich. Ein Dialog informiert Sie
entsprechend.
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 von
Anoubis 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 Dateiliste
kö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 dazu
in 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 der
Playground automatisch entfernt.

5.10 Profile
Regelsätze können in verschiedene Profile abgelegt werden. Somit ist es möglich, die
Anoubis-Sicherheitseinstellungen flexibel zu wechseln.
Beispiele:

1. Ein Laptop steht an einem Arbeitsplatz in einer gesicherten Netzwerkumgebung. Die
Dienste 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 angebotene
Dienste 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 der
Regelsätze nötig ist (in diesem Beispiel: der Mitarbeiter verlässt sein Büro und erreicht den
Flughafen), 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 als
schreibgeschützt gekennzeichnet. Ein Administrator hat damit die Möglichkeit
Profile vorzugeben und sie den Benutzern zur Verfügung zu stellen.
2. Benutzerspezifische Profile. Sie dürfen von dem Benutzer beliebig editiert werden
und 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 damit
sofort wirksam.

5.10.3 Erzeugen und Aktualisieren eines Profils

Ein bereits vorhandenes Profil wird mittels Laden in den Regeleditor geladen. Dort kann
es beliebig editiert werden (siehe Abschnitt 5.4). Später kann der so modifizierte Regelsatz
mit Speichern wieder in ein Profil abgelegt werden. Wird dabei ein bereits existierendes
Profil ausgewählt, so wird es überschrieben. Ansonsten wird es neu angelegt, und es
erscheint 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 auf
die 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 einem
Backup 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 Regel
auszuwä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-Daemon
aktiviert! 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öschen
gelöscht.
Achtung: Die letzte Version kann nicht gelöscht werden!

5.12 Upgrade

Ein Upgrade ist als Aktualisierung von Paketen des darunterliegenden Betriebssystems
definiert.
Das Problem, welches bei einem solchen Upgrade entsteht ist folgendes.
Anoubis verwaltet Prüfsummen von Dateien. Diese Prüfsummen werden unter anderem
in Policy-Entscheidungen miteinbezogen. So kann man sogar den Zugriff auf eine Datei
komplett sperren, wenn die aktuelle Prüfsumme nicht mit der im Anoubis- Hintergrundsy-
stem hinterlegten Prüfsumme übereinstimmt. Wird nun eine Datei durch die Aktualisierung
eines 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 Zeitpunkt
noch nicht bekannt ist. Das erwartete Ergebnis solch einer Installation ist dagegen, dass
das Betriebssystem mit all seinen installierten Applikationen weiterhin funktioniert. Der
Anoubis- Prüfsummenbestand muss demnach automatisch nach einer Paket-Installation
angepasst werden.
Dieses Problem wird mit Hilfe des folgenden Vorgangs behoben:
Der Daemon des Anoubis-Systems erkennt selbstständig den Beginn und das Ende eines
Installationsvorgangs. Das kann das Sperren bzw. Entsperren einer Datei oder auch das
Starten bzw. Beenden eines Prozesses sein. In dieser Zeitspanne werden alle Schreibzu-
griffe des ausführenden Prozesses und seiner Kinder abgefangen, und die modifizierten
Dateien werden in einer Liste einsortiert. Ist der Installationsprozess abgeschlossen, wird
die 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üfsumme
berechnet und in den Anoubis-Prüfsummenbestand übernommen.
Start und Ende des Upgrade-Vorgangs sind sehr stark von der Distribution abhängig. Die
Frage 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 nicht
anpassen, da hierfür der private Schlüssel benötigt wird. Der Benutzer wird allerdings
von 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 in
der 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 der
private 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 dem
Upgrade mittels anoubisctl passphrase zur Verfügung gestellt werden. anoubisd
verwendet den entschlüsselten, privaten Schlüssel, um existiernde root-Signaturen auto-
matisch zu aktualisieren. Nach Beendigung der Upgrade-Prozedur werden Schlüssel und
Passphrase wieder aus dem Speicher entfernt.

5.13 Authorisierung
Der Anoubis-Daemon kann verlangen, dass sich die Clients mit einem kryptografischen
Challenge-Response-Verfahren gegenüber dem Daemon authorisieren. Nur wenn sich
der 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 den
Daemon-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 verlangt
und der Client kein oder ein falsches Zertifikat verwendet.


L OGGING
• 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 über
das GUI.

6.1 Übersicht über die Ereignisarten

Es gibt verschiedene Arten von Ereignissen, die unterschiedlich dargestellt und bearbeitet
werden 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 Programm
wird 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. Wenn
neue 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 werden
protokolliert 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 Logviewer
zur 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ßleiste
des Hauptfensters geöffnet und geschlossen werden.
Alternativ kann auch aus dem Menü Werkzeuge der Eintrag LogViewer zum Öffnen und
Schließen des Logviewers verwendet werden.
Wird der Logviewer geöffnet erscheint das in Abbildung 6.1 dargestellte Fenster. Jede
Zeile 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 Informationen
hä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 und
die 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 Information
darü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 Beantwortung
durch den Nutzer eine weiterer Eintrag im Logviewer erzeugt, der das endgültige
Ergebnis enthält.

Achtung: Ein Ereignis, das von Anoubis erlaubt wurde, kann immer noch aus anderen
Grü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, die
Art des Ereignisses, das erzeugt wird.

• Eine Regel, die mit ASK markiert ist, erzeugt eine Eskalation. Ob das zugehörige
Ereignis 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 von
einer eventuell zusätzlich erzeugten Eskalation) eine Log- oder Alertmeldung erzeugt.
Die Loggingeigenschaften einer Regel können im Regeleditor im rechten Fenster im
Karteireiter 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-Meldungen
werden auch über den syslog Mechanismus des Betriebssystems protokolliert und in
den dort konfigurierten Log-Dateien gespeichert. Die Konfiguration dieses Mechanismus
erfolgt über syslog.conf(5). Dabei wird die facitility LOG_DAEMON verwendet.
Meldungen mit dem Attribut LOG verwenden die Priorität LOG_INFO, Meldungen mit dem
Attribut 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 zu
einem anderen System aufgebaut werden.
Beispiel: Die Anwendung Firefox versucht www.example.com mit der IP-Adresse
1.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 anderer
Rechner Dienste nutzt, die vom eigenen System angeboten werden.
Beispiel: Ein Nutzer des Systems meldet sich zum Beispiel mit Hilfe des Programms
ssh ü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ür
diese Ereignisse Log- oder Alertmeldungen zu erzeugen, weil durch die große Anzahl an
Logmeldungen 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. Die
enthaltenen 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 auch
in Meldungen der Sandbox enthalten sind, also die Art des Zugriffs, den Pfad auf den
zugegriffen 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 Benutzerregel
ein Programm automatisch in einem Playground gestartet wurde, wird dies im Log-
Viewer durch eine entsprechende Meldung dokumentiert. Diese enthält den Namen
des Programms und die Regel, die den Playground erzwungen hat.
Übernahme aus dem Playground Wenn der Benutzer die Übernahme einer Datei aus
dem 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 das
Verschieben 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 werden
soll. Diese Rückfrage und die zugehörige Entscheidung des Benutzers erzeugen eine
Log-Meldung. Diese enthält eine detaillierte Beschreibung der versuchten Operation
und ob diese zugelassen oder verboten wurde.


106 6. Logging


F EHLERBEHANDLUNG
• Allgemein
• Application Level Firewall
• Sandbox und Sicheres
Filesystem

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 auch
die 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 vom
Systemadministrator nicht aktiviert. Dieses Problem muss vom Systemadministrator
behoben 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 vom
Systemadministrator nicht aktiviert. Dieses Problem muss vom Systemadministrator
behoben werden. Bis dahin können die Filtermöglichkeiten von SFS und Sandbox
nicht 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 Vordergrund
bringt, können Sie dies in der Regel durch einen Klick auf den Eintrag von xanoubis in der
Taskleiste 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 speichert
der Windowmanager die laufenden Anwendungen einer Benutzersitzung ab, um sie beim
wiederholten bzw. erneuten Einloggen in das System wiederherzustellen und die gewohn-
te Arbeitsumgebung zur Verfügung zu stellen. In der Regel können Anwendungen von
diesem Mechanismus innerhalb der Sessionverwaltung des Windowmanagers ausgenom-
men werden. Sollte es bei der Verwendung von xanoubis und der Autostartfunktionalität
zu diesem Verhalten kommen, so muss diese von der Sessionverwaltung ausgenommen
werden, 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 den
Administrator 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, dass
die eigene Policy nochmals zum Anoubis-Daemon gesendet wird, um eine signierte
Policy zu hinterlegen.

• Öffnen Sie nun den Regel-Editor. Veränderen Sie eine beliebige Regel und setzen
Sie 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äche
Aktivieren drücken.

7.1.5 Beim Editieren von Sandbox-/SFS-Regeln kann ich keinen Pfad
auswä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 Verhalten
wird 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 zur
Verfü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 eine
Liste 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 Sie
den 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 alle
Aspekte 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 Socket
zu ö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 ein
neuer 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 der
Anoubis-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 Policies
durchsetzen.

7.1.9 Xanoubis meldet: Falsche APN-Version

Nach dem Verbinden mit dem Anoubis-Daemon erscheint die Meldung: „Der APN-Parser
ist 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 des
Daemons.

7.1.10 Xanoubis meldet: Falsche Anoubis-Protokoll-Version

Nach dem Verbinden mit dem Anoubis-Daemon erscheint die Meldung: „Die Verbindung
konnte wegen einer Inkompabilität im Anoubis-Protokoll nicht aufgebaut werden.“Beim
Verbindungsaufbau konnten sich Anoubis-Daemon und xanoubis nicht auf eine gemein-
same Protokoll-Version einigen. In diesem Fall installieren Sie bitte die aktuellste Version
von 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.„Dies
bedeutet, dass die Version der Konfiguration in .xanoubis Xanoubis nicht bekannt ist. In
diesem Fall installieren Sie bitte die aktuellste Version von xanoubis. Alternativ können
Sie das Verzeichnis HOME/.xanoubis auch umbenennen. Xanoubis erstellt dann automa-
tisch ein neues Verzeichnis mit diesem Namen. Hiervon wird jedoch abgeraten, da alle
gespeicherten Profile nicht mehr zur Verfügung stehen, inklusive aller alten Versionen der
Policies.


7.1. Allgemein 113

7.1.12 Xanoubis meldet: Fehlender Schlüssel

Nach dem Verbinden mit dem Anoubis-Daemon erscheint die Meldung: „Die Verbindung
wurde abgebrochen, weil der Schlüssel nicht geladen werden konnten. Bitte überprüfen
Sie 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, dass
Sie 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 fragt
nach 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 zu
hinterlegen.“
Beim Verbindungsaufbau fragt der Anoubis-Daemon nach einem Zertifikat, das Sie nicht
konfiguiert haben. Sie müssen es entweder korrekt in den SFS-Optionen (siehe Abschnitt
5.7.4) einstellen, oder Ihr System-Administrator muss Ihr Zertifikat am Daemon für Sie
hinterlegen (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 und
Klicken Sie auf den Button Ändern.

• Wählen Sie den Karteireiter Erweitert.

• Stellen Sie sicher, dass im Bereich Erweiterte Einstellungen die Option
PAE/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 aktiven
Regelsatz im anoubisd so weit geändert wurde, dass anhand der Eskalation nicht mehr
entschieden 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 Änderungen
durch 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 automatisch
gewä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 automatisch
gewä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-Funktion
des SFS-Browsers, um die Prüfsumme zu aktualisieren. Versuchen Sie dann den
Zugriff erneut.

• Achtung: Bitte aktualisieren Sie niemals eine Prüfsumme, wenn die Änderungen an
einer 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 Logviewer
angezeigt.

• 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 Zugriff
auf Dateien, die für den Betrieb wichtig sind, entziehen. In diesem Fall kann es dazu
kommen, 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: Modiﬁzieren Sie die Regeln in der Datei policy mit einem
beliebigen Editor oder mit Hilfe des Regeleditors in xanoubis so, dass das Problem
behoben wird.

• Aktivieren Sie modiﬁzierten Regeln:

/sbin/anoubisctl -u userid -p user load policy

Wenn signierte Policies verwendet werden, dann ist dieses Vorgehen nicht ohne Weiteres
möglich, weil zum signieren der Policy der private Schlüssel des Nutzers benötigt wird. In
diesem 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ückfrage
zu 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ählte
Zertifikat 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 ein
privater Schlüssel konfiguriert sein. Der öffentliche Schlüssel muss zusätzlich dem
Anoubis-Daemon bekanntgegegben werden.

• Prüfen Sie, ob der im Anoubis-Daemon konfigurierte öffentliche Schlüssel zu dem im
GUI 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 aber
nicht
Die Sandboxregeln einer Applikation werden von oben nach unten abgearbeitet, die erste
Regel, 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 des
in 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 dem
tatsä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 eine
Regel 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 viele
Dateien im Verzeichnis /var/lib/anoubis/sfs/. Wenn dadurch die Partition voll oder
die 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 eigene
Partition 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, wird
zwar 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 diesem
Fall 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 zu
schließen und ihn dann neu im Playground zu starten.
Wenn sie tatsächlich zwei Browser gleichzeitig geöffnet haben möchten, von denen einer
im 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 dort
ein neues Profil anlegen oder ein gerade nicht benutztes Profil auswählen, weil immer nur
ein 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 neues
Fenster geöffnet, dieses läuft dann aber nicht im Playground.
Lösung: Das Problem ist analog zu dem im oben beschriebenen Problem mit Firefox. Die
Lösung besteht darin, die Applikation so zu starten, dass tatsächlich ein neuer Prozess
gestartet wird. Ob und wie das möglich ist, hängt von der Applikation ab und muss in
deren Dokumentation nachgeschlagen werden. Eine alternative Lösung ist, die außerhalb
des Playgrounds laufende Applikation zu beenden bevor die Applikation im Playground
gestartet 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 sie
verloren.
Lösung: Der Playground kann mit dem folgenden Kommando gelöscht werden:

$ playground -f remove <Playground ID>


F REMDSOFTWARE
• 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, um
eine reibungslose Zusammenarbeit zu garantieren.

Installation

Generell muss an dieser Stelle betont werden, dass bei den Installationsanweisungen die
Herstellerangaben der Firma Avira maßgeblich sind.
Unabhängig von der verwendeten Distribution kann die tar-Datei entpackt werden. Es
wird hierbei ein Ordner erstellt, in dem sich ein Shellscript zur Installation befindet. Es ist
auszufü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 Software
von 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ändig
ist. In den default-Regeln des Administrators für alle Benutzer werden alle Aktionen
erlaubt. Die bereitgestellten Profile für die Benutzer sind mit default ask Regeln versehen.
Hierdurch werden zur Laufzeit Nachfragen zu Ereignissen erzeugt (siehe Abschnitt 5), die
der Benutzer beantworten muss.
Für die On-Access-Funktionalität verwendet Avira DazukoFS. Dabei handelt es sich um
ein 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 den
Beschränkungen des SFS auszunehmen. Die Policies wurden bereits, wie im Kapitel 4.4.2
beschrieben, vorbereitet.
Nachdem die Binaries und Policies angepasst wurden, muss das Avira Hintergrundmodul
neu 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 entfernt
werden:

commit = required /usr/share/anoubisd/avira_glue.sh Avira AntiVir scanner

Danach muss als Benutzer Root die Konﬁguration 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, um
eine reibungslose Zusammenarbeit zu garantieren.

Installation

Angaben 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 Paketen
clamav-base, clamav-daemon, clamav-freshclam, libclamav6 genügt. Die
Installation des Virenscanners und des Programms zur Aktualisierung der Virensignaturen
kö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. Ein
passender 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. Ein
passender 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 Aufruf
fü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 Software
ClamAV mit. Dies umfasst sowohl den eigentlichen Scanner, der die Dateien durchsucht,
als auch das Update-Programm, welches für die Aktualisierung der Virenmuster zuständig
ist. In den default-Regeln des Administrators für alle Benutzer werden alle Aktionen
erlaubt. Die bereitgestellten Profile für die Benutzer sind mit default ask Regeln versehen.
Hierdurch werden zur Laufzeit Nachfragen zu Ereignissen erzeugt (siehe Abschnitt 5), die
der 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 im
Anoubis-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 dem
Mount-Point des darunterliegenden Dateisystems übereinstimmt.
Damit der Virenscanner auf alle Dateien zugreifen darf, ist es notwendig, ihn aus den
Beschränkungen des SFS auszunehmen. Die Policies wurden bereits, wie im Kapitel 4.4.2
beschrieben, 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 folgender
Zeile 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. Die
zweite Zeile verwendet dagegen clamdscan, welcher die zu scannenden Dateien an
den ClamAV-Daemon übergibt. Die zweite Variante ist schneller, erfordert aber dass der
ClamAV-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 werden
sollten 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 und
Linux-Distributionen ist komplett disjunkt mit jenen von Sophos und Talpa.

Installation

Herstellerangaben 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 das
Shellscript 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

Konﬁguration

Die Anoubis Security-Suite liefert keine Policies für die Antivirus Software von Sophos
mit. Damit der Virenscanner auf alle Dateien zugreifen darf, ist es notwendig, ihn aus
den 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ür
Sophos 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 werden
mü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 den
default-Regeln des Administrators für alle Benutzer werden alle Aktionen erlaubt. Die
bereitgestellten Profile für die Benutzer sind mit default ask Regeln versehen. Hierdurch
werden 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 der
TrueCrypt-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 der
Mount-Point der Container durch den Benutzer individuell festgelegt und geändert werden
kann. Das kann zur Folge haben, dass Policies nicht mehr gültig sind, da sich die Pfade
zu 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 und
zu benutzen.



Konﬁguration
Aus Nutzersicht gibt es keine nennenswerte Berührungspunkte zwischen Anoubis und
eCryptfs. Es ist daher keine Konﬁguration notwendig, um eine Interoperabilität mit Anoubis
zu gewährleisten.

8.3 X-Server (Xorg)
Die X-Server Software des Xorg-Projekts beinhaltet seit Version X11R6 eine Erweiterung
namens 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 einer
beliebigen Applikation nicht von denen der realen Hardware unterschieden werden. Die
Bibilotheksfunktionen der Erweiterung XTest erlauben das Generieren bzw. Senden von
Tastatur- und Mauseingaben. Damit lässt sich eine Applikation nahezu völlig automatisch
steuern. Das hieraus resultierende potentielle Sicherheitsrisiko, dass Eingaben am Nutzer
des Systems vorbei vorgenommen werden, lässt sich nur durch die Deaktivierung dieser
X-Erweiterung sicherstellen.

8.3.1 Deaktivieren von Xtest
Um die Erweiterung XTest des X-Servers dauerhaft zu deaktivieren, fügen Sie bitte den
folgenden 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, die
für alle →Policies gelten. Anschließend werden die speziellen Elemente für die Notation
von 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 geben
den Rahmen vor, der vom Anwender nur weiter eingeschränkt werden kann. Diese Be-
ziehung zwischen Administrator- und Benutzerregeln wird im Folgenden als Monotonie
bezeichnet.
Die Unterscheidung zwischen Administrator- und Benutzerregeln wird nicht auf der Ebene
der 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 Benutzern
sortiert 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 Teilergebnissen
ein Gesamtergebnis.
Erlaubt der Administrator zum Beispiel einem Benutzer, mit ssh(1) Verbindungen auf
beliebige Maschine vorzunehmen, kann der Benutzer selbst die Menge der Maschinen
einschränken. Beschränkt aber der Administrator die Menge der Maschinen, kann der
Benutzer 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 ein
zuvor 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 zu
definieren, 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 ein
neuer Regelsatz verwendet werden soll oder nicht. Werden keine weiteren Angaben zur
Vererbung 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 Wechsel
des 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 zwischen
Administrator- 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 Notation
spezifiziert. 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 und
SFS sowie ein Block Context, der die Regeln für einen Kontextwechsel beschreibt. Nicht
jeder 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öcke
möglich, im Modul SFS können direkt SFS-Regeln angegeben werden.
Ein Applikationsblock ist dabei immer wie folgt aufgebaut (ein Kontext-Applikationsblock
wird 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 Regelblock
gelten soll. Dabei kann optional eine im Prüfsummenbestand unter dem angegebenen
Namen 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 einem
Block zulässigen Zugriffsregeln (in der Grammatik beschrieben durch <accessrule>)
hängen wiederum vom konkreten Modul ab. Das Flag pgonly legt fest, dass diese Regel
nur 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 mehrere
UNIX-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 die
Applikation Firefox ergeben. Applikationen werden durch Angabe ihres absoluten Pfades
oder 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, komplexe
Applikationen, die aus mehreren Prozessen bestehen, die unterschiedliche Programme
ausführen, durch gemeinsame Regeln zu adressieren. Dies wird in der oben angegebenen
Grammatik durch das Symbol <apps> beschrieben, während eine einzelne Anwendung
dem 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 Regelsatz
selbst 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 angegebenen
Grammatik 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ür
eine bestimmte Zeitdauer einzuschränken. Das Erstellen von Regeln mit Scope wird vom
RuleEditor 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änkt
werden. Der Prozess wird identifiziert durch eine Zahl, die unabhängig von der
Prozess-ID durch Anoubis vergeben wird.

Endzeitpunkt Mit Hilfe von „until” kann ein Endzeitpunkt in Sekunden seit dem
1.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 entsprechend
ihrer Version interpretieren zu können. Die Version sollte am Anfang einer Policy stehen
und 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 Applikationen
an, 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 keine
eigenen Kontextregeln haben, sinnvoll. Darüber hinaus ist dies typischerweise der Fall für
Applikationen, 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 nicht
auf UDP und TCP basieren (insbesondere Raw-Sockets) oder anderen Adressfamilien als
IPv4 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 und
wie 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 ask
eine interaktive Rückfrage beim Nutzer zu veranlassen.
Anschließend wird die Richtung des Zugriffes angegeben, connect oder accept bei
TCP oder SCTP und send oder receive bei UDP.
Mit dem optionalen Terminalsymbolen log und alert wird bestimmt, dass Zugriffe, die
von dieser Regel gefiltert werden, protokolliert werden.
Darauf folgt die Definition des Protokolls. Hier stehen die Terminalsymbole tcp, udp und
sctp zur Verfügung und eines muss gegeben sein.
Als letztes folgt die Angabe der Quell- und Zieladresse, die ein Paket haben muss, damit
diese Regel angewendet wird. Mit from wird der Absender und mit to der Empfänger
festgelegt. Absender und Empfänger entsprechen dabei der in jedem IP-Paket gegebenen
Absender- und Empfängeradresse.
Statt einer einzelnen Adresse oder eines einzelnen Ports kann jeweils eine ganze Liste
oder any angegeben werden. Darüber hinaus sind bei Adressen auch Netzmasken in
CIDR-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 Netzwerkzugriffe
definiert. 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 von
Pfad 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 geschehen
soll, wenn die Regel zutrifft. Es kommt immer die erste zutreffende Regel zur Anwendung.
Eine weitere Auswertung der Regeln ﬁndet nicht statt. Allerdings wird eine Default-Regel
unabhängig von ihrer Position in der Liste nur dann angewandt, wenn keine andere Regel
fü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äﬁx liegen. Ist hier „any” angegeben, dann sind alle Pfade zulässig.
• Wenn mit Hilfe von <subject> auf eine Prüfsumme im Schattenbaum verwiesen
wird, muss eine solche Prüfsumme vorhanden sein und die Prüfsumme muss zum
aktuellen Inhalt der Datei passen. Ist die Prüfsumme signiert, so muss zusätzlich die
Signatur gültig sein.
• Die Zugriffsart (lesen, schreiben oder ausführen) des Ereignisses muss in den durch
<permissions> angegebenen Zugriffsrechten enthalten sein. Bei einem Zugriff, der
mehrere 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 das
Verhalten von Default-Regeln der Sandbox entspricht genau dem von Default-Regeln der
ALF.



A.6 SFS
Das Modul SFS bietet die Möglichkeit, unabhängig von einer bestimmten Anwendung
festzulegen, 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 dabei
durch 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ür
alle Aktionen eines Nutzers.
Jede Filterregel wird durch die Angabe eines Pfadpräﬁx 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üfsumme
als manipuliert betrachtet werden muss.
Die Prüfsumme wird mit dem tatsächlichen Inhalt der Datei verglichen. Abhängig vom
Ergebnis dieses Vergleichs wird eine der drei Aktionen ausgeführt:

valid Diese Aktion wird ausgeführt, wenn eine Prüfsumme vorhanden ist und mit dem
Inhalt der Datei übereinstimmt.

invalid Diese Aktion wird ausgeführt, wenn eine Prüfsumme vorhanden ist, diese aber
nicht 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 dann
keine 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äﬁx einer SFS-Regel erfasst wird, ist immer
genau eine dieser drei Aktionen anwendbar. Um dennoch die Möglichkeit zu haben, die
Regelauswertung 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äﬁx Dieses schränkt die Gültigkeit der Default-Regel auf Dateien unterhalb
des 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 sich
Default-Regeln des SFS-Moduls also durch das zusätzliche Pfadpräﬁx.


Anhang B

Architektur und Pfade

Anoubis besteht aus einer Kernelkomponente, einem Systemdaemon und einer Reihe von
Programmen zur Arbeit und Konﬁguration.

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. Diese
gibt 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 durch
den 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 eingebunden
werden.
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 den
Modulen 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 OpenBSD
wurde die TrustedBSD-Infrastruktur, wie sie in FreeBSD implementiert ist, portiert und
verwendet.

B.2 Der Anoubis-Daemon
Der Anoubis-Daemon nimmt Ereignisse vom Kern entgegen und führt sie anhand der
aktiven 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) muss
dazu 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 einem
Systemupgrade.
scanner Ein Scannerprozess startet die Inhaltsscanner für die Playgrounds. Es kann
mehrere Scannerprozesse geben, einen je Benutzer.

B.2.1 Pfade
Dieser Abschnitt dokumentiert Pfade, die vom Anoubis-Daemon verwendet werden. In der
Regel sollten die darin enthaltenen Daten auch vom Administrator nicht direkt modiﬁziert
werden. 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 es
von den Userinterfaces verwendet, um durch den Kern
berechnete Prüfsummen zu ermitteln.
/dev/eventdev Über dieses Device empfängt der Anoubis-Daemon
Nachrichten 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. Ein
Zugriff sollte mit Hilfe des Kommandos sfssig ge-
schehen.
policy/admin/ Dieses Verzeichnis enthält die Admini-
stratorpolicies. Der Zugriff auf dieses Verzeichnis
sollte mit anoubisctl geschehen.
policy/user/ Dieses Verzeichnis enthält die User-
Policies. Der Zugriff auf dieses Verzeichnis sollte mit
anoubisctl 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 der
Anoubis-Daemon Informationen zu den Play-
grounds, in denen noch Programme laufen oder
Dateien existieren, die weder gelöscht noch ins
Produktivsystem ü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 vom
Administrator 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 alle
diese 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 ﬁnden sich xanoubis und playground
in /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 von
xanoubis und die Daten der Versionsverwaltung und der gespeicherten Proﬁle. Änderun-
gen an diesen Daten dürfen nur mit Hilfe der jeweiligen Werkzeuge z.B. dem RuleEditor
vorgenommen werden. Das Vornehmen von manuellen Änderungen an diesen Daten wird
nicht 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 steht
ein Eintrag. Jeder Eintrag besteht aus dem Dateinamen (mit Pfad), sowie Prüfsumme
und/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üssels
keyid folgende Ersetzungsregeln angewendet:

• Vor Leerzeichen und Backslashes () wird ein zusätzlicher Backslash gesetzt.
• Zeichen mit ASCII-Code 1 bis 31 (Kontrollzeichen) werden als dreistellige Oktalzahl
mit 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 Abschnitt
4.9.4 beschrieben.
Die Scanner werden mit den Rechten des Systembenutzers _anoubisscan aufgerufen.
Das aktuelle Arbeitsverzeichnis des Scannerprozesses ist das Heimatverzeichnis dieses
Systembenutzers (normalerweise /var/spool/anoubis). Falls dieses Verzeichnis nicht
existiert 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 Scanner
nur 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 sollte
nur 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 er
den 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 er
ausserdem eine Begründung für die Entscheidung auf STDOUT oder STDERR ausgeben.
Diese Begründung wird dem Benutzer angezeigt. Die Ausgabe eines einzelnen Scanners
darf nicht länger als 1 kByte sein. Die Gesamtlänge der Ausgaben aller Scanner inklusive
der konfigurierten Namen der Scanner darf nicht größer als 8 kByte sein.

144 D. Interface für Inhaltsscanner


Anhang E

Glossar

APN Abstract Policy Notation. Eine für Anoubis entworfene Sprache zur Beschreibung
von →Policies.

ALF Application Level Firewall. Im Gegensatz zu reinen Paketfiltern1 arbeitet die App-
lication Level Firewall auf Applikationsebene (Schicht 7 im ISO-OSI-Modell). Dabei
wird es dem Administrator und Benutzer ermöglicht, den Netzwerkzugriff einzelner
Anwendungen (Applikationen) feingranular zu regeln. Hierbei werden Socket-Zugriffe
von 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änen
zustä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 Route
zu einem Zielnetz oder -rechner gibt, die genauer passen würde. Üblicherweise die
Route zum Internet.

EBNF Extended-Backus-Naur-Form. Die →Extended-Backus-Naur-Form ist eine kom-
pakte, formale Metasprache zur Darstellung kontextfreier Grammatiken. Die von
Anoubis verwendete →Abstract Policy Notation zur Formulierung von →Policies wird
in diesem Buch in →Extended-Backus-Naur-Form beschrieben.

FQDN Fully Qualified Domain Name. Der vollständige Name eines Rechners, der ihn im
Internet eindeutig identifiziert. Er setzt sich aus dem Hostnamen und dem Domain-
namen – durch einen Punkt getrennt – zusammen. Ein FQDN wird vom →Domain
1
Paketfilter untersuchen zumeist reine Verbindungsdaten wie Quelle (IP-Adresse), Ziel (IP-Adresse) und
Dienst (Port).

148 E. Glossar

Name System verwaltet und in eine →IP–Adresse (oder manchmal auch mehrere
davon) umgesetzt.
Grub Ein Bootloader für Linux, der derzeit bei den meisten Linux-Distributionen verwendet
wird.
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 einem
WWW–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 innerhalb
eines Netzes eindeutig sein muss. Sie ist bei IPv4 32 Bit lang und wird normalerweise
in der Form: 192.168.23.10 dargestellt.
Lilo Ein Bootloader für Linux, der früher häuﬁg 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 Applikationen
bei 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 zu
den 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 Paketdienst
aufsetzt.
SFS Secure Filesystem bietet jedem Nutzer die Möglichkeit Prüfsummen zu Dateien in
einer vom System verwalteten Datenbank einzutragen. Diese Prüfsummen können
optional 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 nur
in 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 auch
alle 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 (auch
TCP/IP–Subsystem).
URL Uniform Resource Locator Eindeutige Adresse zum Aufﬁnden von Informationen im
→WWW. Besteht aus Protokollangabe (HTTP, FTP), Rechnerangabe (Hostname)
und Dateipfad auf diesem Rechner.


Handbuch de

Weitere ähnliche Inhalte

Was ist angesagt?

Andere mochten auch

Handbuch de