SELinux und AppArmor
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 95 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/32301 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
FrOSCon 201746 / 95
4
8
9
15
20
22
23
24
25
27
29
32
36
37
38
39
40
45
46
47
48
49
50
51
53
54
59
63
64
65
74
75
76
79
83
84
86
87
88
89
91
92
93
94
95
00:00
SELinuxHTTPAppArmorOpen sourceLINUXMobile appXMLUMLComputer animation
00:48
Oracle <Marke>Graph (mathematics)SQLUNIXComputing platformDefault (computer science)SELinuxAppArmorConfiguration spaceAlgebraic closureInformation securityRollbewegungConstraint (mathematics)ACCESS <Programm>Client (computing)Web browserPOSIXMechanism designZugriffskontrolleUNIXLINUXWeb browserConfiguration spaceIP addressEckeAlgebraic closureEmailComputer fileLarge eddy simulationMultiplicationRollbewegungMobile appStandard deviationRoundingConstraint (mathematics)ZugriffBerührung <Mathematik>DatabaseDatabaseSystem administratorService (economics)Smart cardZugriffskontrollePressureArmVideo projectorBitPOSIXMySQLAppArmorPort scannerComputer animation
10:41
POSIXACCESS <Programm>ZugriffskontrolleMechanism designLINUXUser profileAppArmorSELinuxUNIXAlgebraic closureNovell <Marke>Kernel (computing)openSUSEUbuntu <Programm>Mechanism designLINUXPOSIXMySQLUbuntu <Programm>Computer data loggingProgrammer (hardware)Kernel (computing)Computer fileSet (mathematics)Variable (mathematics)ImplementationDistribution (mathematics)Mobile appConstraint (mathematics)BitComponent-based software engineeringZugriffDefault (computer science)Module (mathematics)ACCESS <Programm>Zusammenhang <Mathematik>CodeError messageopenSUSEUNIXNovell <Marke>Normal (geometry)Video projectorArmBackdoor (computing)Standard deviationZugriffskontrolleComputer animation
20:35
AppArmorNovell <Marke>Kernel (computing)LINUXopenSUSEUbuntu <Programm>SELinuxComputer fileConstraint (mathematics)AppArmorLINUXBitWeb servicePoint cloudArmComputer animationLecture/ConferenceMeeting/Interview
24:36
Service (economics)User profileScripting languageAppArmorPrincipal ideal domainUtility softwareLINUXUbuntu <Programm>Server (computing)ParsingVersion <Informatik>BIND <Programm>ZugriffSound effectCodeWeb servicePlatteZugriffUser profileUbuntu <Programm>Parameter (computer programming)Process (computing)Module (mathematics)Server (computing)Group actionIP addressAppArmorMySQLDefault (computer science)Software testingMobile appLibrary (computing)NormaleAdaptive behaviorDynamic Host Configuration ProtocolSequenceComputer animation
30:43
CodeSound effectZugriffKernel (computing)AppArmorSELinuxMySQLACCESS <Programm>Aktion <Informatik>Computer fileComponent-based software engineeringScripting languageUbuntu <Programm>ACCESS <Programm>Adaptive behaviorTimestampInformation retrievalLocal ringSimilarity (geometry)Error messageServer (computing)Programmer (hardware)AppArmorDefault (computer science)MySQLComputer animation
36:51
Computer programAppArmorCodeIndexInternetdienstUbuntu <Programm>InternetdienstLINUXZugriffWikiopenSUSEGroup actionProgrammer (hardware)Computer fileTable (information)DatabaseCalculationFluxVideo projectorInformationAppArmorPhysical quantityMySQLSound effectMover <Programm>Computer animation
40:30
AppArmorIndexInternetdienstUNIXAlgebraic closureSELinuxLINUXNon-standard analysisFedora CoreKernel (computing)openSUSEDebian GNU/LINUXComputer fileAppArmorLINUXClient (computing)ZugriffProcess (computing)Statement (computer science)Programmer (hardware)Utility softwareWeb browserUser profileDatabaseDebian GNU/LINUXWeb serviceQuery languageInformationZusammenhang <Mathematik>Default (computer science)Meeting/InterviewComputer animation
47:42
MySQLCodeACCESS <Programm>Cache (computing)VECTOR <Programm>AverageKernel (computing)SELinuxLINUXNetwork socketLoginRollbewegungMechanism designTypMultiplicationMaximum length sequenceDesktopWorkstation <Musikinstrument>RollbewegungObject (grammar)Error messageData typeComponent-based software engineeringZugriffProcess (computing)LINUXAttribute grammarWorkstation <Musikinstrument>Server (computing)Mechanism designVECTOR <Programm>ACCESS <Programm>Decision theoryCache (computing)Expert systemRALLY <Programm>Computer fileMilitary operationComputer animation
54:28
Default (computer science)SELinuxComputer programCodeBackupComputer fileInternetdienstPerimeterWikiIndexDownloadAppArmorPlatteLINUXGastropod shellKernel (computing)Programmer (hardware)Attribute grammarBackupNormal (geometry)Process (computing)MySQLConstraint (mathematics)DownloadPerimeterCalculationWeb serviceContext awarenessCustom Computing MachineTable (information)Computer animation
01:01:15
openSUSEComputer animation
Transcript: German(auto-generated)
00:07
Herzlich willkommen zur Mitte des Nachmittags, wie der Vortrag heißt, wisst ihr alle aus den Ankündigungen, dass es Verirrte hier gibt, die eigentlich woanders hinwollten, nehme ich einfach mal nicht an. Es geht um SE Linux und App Armor.
00:24
Mein Name ist Jörg Brühe, ich arbeite bei der, achso, man sollte anschalten, arbeite für die Firma. So, was ist? Entschuldigung, so, also, F5, so, ich arbeite für die Firma FromDuel,
00:53
wir beschäftigen uns mit Dienstleistungen rund um MySQL und da ich diese Folien in der Arbeitszeit gemacht habe, muss der Werbeblock sein, ansonsten springen wir jetzt gleich weiter.
01:04
MySQL ist in diesem Vortrag kein Thema, aber es kommt als Beispiel vor. Also, es geht nicht um die Datenbank, sondern es geht um ein Programm, was normalerweise von SE Linux und App Armor behandelt wird. Ich selber habe mich immer rund mit Datenbanken beschäftigt und zwar nicht auf der Anwendungsseite typischerweise,
01:26
sondern auf der Anbieterseite, also Hersteller ursprünglich beziehungsweise jetzt Support, Consulting und so weiter. War eine Weile immer MySQL Bildteam, das spielt jetzt aber keine Rolle. Mit SE Linux und App Armor komme ich in Berührung, wenn das irgendwie auf Kundenmaschinen installiert ist
01:47
oder installiert werden soll und dann Support-Fragen auftauchen. Ihr kennt wahrscheinlich aus den verschiedenen Anleitungen, wer auch immer da mal was veröffentlicht, die typische Empfehlung SE Linux schalten wir erstmal ab.
02:05
Und ja, das ist typisch, das ist Fakt und das hat mich so dazu motiviert, dass ich mir sage, warum eigentlich? Es sollte nirgends so sein, dass ein Administrator ein Sicherheitsfeature abschalten muss.
02:21
Mag sein, dass er es macht, weil er sagt, ich bin in einer geschützten Umwelt, mir passiert hier nichts und ohne das Sicherheitsfeature geht es leichter oder schneller oder wie auch immer, aber spätestens beim Produktionseinsatz sollte es nicht nötig sein, damit es dann auch möglichst gar nicht erst passiert. Und Ziel dieses Vortrags ist es also, dass ein Zuhörer, wenn er in die Admin-Rolle schlüpft oder in dieser Admin-Rolle ist,
02:46
dass er AppArmor und SE Linux nutzen kann, dass er weiß, worum es geht, dass er in AppArmor oder SE Linux, je nachdem, was auf dem System installiert ist und läuft, dass er eingreifen kann und dass er da ein bisschen eine Vorstellung hat, was, wieso, warum
03:03
und dass er das vor allen Dingen an die lokale Konfiguration, an die lokalen Bedürfnisse anpassen kann. Ich habe das erstmal so gegliedert, ein bisschen über Zugriffsschutz in Unix und in diesem Sinne ist Linux auch nur ein Unix, zumindest von der Historie her.
03:24
Dann die Frage, warum gibt es überhaupt weitere Mechanismen, wofür sind die gut? Im Detail, diese weiteren Mechanismen könnten sein AppArmor oder SE Linux, jeweils mit einem eigenen Abschnitt und danach einen kurzen Abschluss, ein kurzes Fazit. Weil ich aber andererseits mit dem Vortrag ein leichtes Problem habe, das ich überziehe,
03:44
machen wir jetzt das Thema Zugriffsschutz in Unix ganz kurz. Die Folien werde ich hochladen auf die Firmenseite. Ich glaube, auf der Froskon-Seite wird es dann auch eine Hochlademöglichkeit geben. Die könnt ihr euch also dann beliebig holen und dann könnt ihr zu den übersprungenen
04:01
oder die Folien, die ich jetzt überspringen werde, in aller Ruhe nachlesen. Ganz grundsätzlich geht es natürlich bei Zugriffsschutz darum, dass wir einzelne Benutzer voreinander schützen wollen und dass wir die Zuverlässigkeit des Systems sicherstellen wollen, soll heißen, wir müssen die Systemkomponenten gegen unberechtigte Änderungen schützen.
04:25
Und das ist ein Dauerthema, seit Unix geschrieben wurde als Multi-User-System, seit es in den 70er Jahren entstanden ist. Und da kann man jetzt im Detail darüber reden, man kann es auch, wie ich das jetzt gerade ganz brutal gemacht habe, erstmal überspringen und nur die Tendenz zusammenfassen.
04:44
Im Anfang hatten wir bei Unix die Unterscheidung zwischen dem User, Owner, Eigentümer, na Owner, es passt schlecht von der Abkürzung her, also dem User und anderen, sprich Files und so weiter, waren entweder persönlich, privat, personengebunden. Soweit man jetzt einen Unix-Benutzer mit einer Person gleich setzt,
05:04
das tue ich jetzt mal ganz grob, oder aber sie waren öffentlich, lesbar bzw. schreibbar. Dann kam als nächste Stufe, sehr bald, ganz früh in der Unix-Geschichte dazwischen noch die Gruppe, also gab es auch Gruppenrechte.
05:20
Und später kamen die Zusatzgruppen, sodass also ein Benutzer mehreren Gruppen zugeordnet werden konnte, also mehreren Arbeitsgruppen oder dass er mehrere Rollen haben konnte. Und diese Einführung von Group und dem Set-Group-ID-Bit und später den Zusatzgruppen, die diente immer dazu, dass man Dateien oder Geräte, die eigentlich nicht öffentlich
05:45
zugreifbar sein sollten für jeden, aber doch für relativ viele einzeln kontrolliert zugreifbar machen konnte. Also typischerweise diese Zusatzgruppe LP als Eigentümer des Druckers bzw. eine Gruppe Scan als Eigentümer des Scanners und Scan-Berechtigter,
06:02
das waren immer Supplementary Groups. Es diente also dazu, gewissen Benutzern mehr Rechte zu geben, als sie von ihrer, also als Einzelpersonen gehabt hätten. Und viele Einzelpersonen kann man im Unix-Fallsystem halt nicht verwalten. Ein Fall hat immer nur einen Eigentümer. Warum also brauchen wir weitere Mechanismen?
06:22
Warum denken wir überhaupt darüber nach oder warum reden wir darüber? Näher die Unix Permission Bits, die haben Grenzen. Sie unterscheiden nur nach dem Benutzer, aber sie unterscheiden nicht nach dem Programm der Anwendung, die im Namen dieses Benutzers läuft.
06:42
Und wenn dieses Programm also durch eine Fehlfunktion oder durch einen Missbrauch auf Dateien zugreift, auf die der Benutzer zwar zugreifen dürfte, aber dieses Programm nicht sinnvoll zugreifen kann, dann können uns die Unix Permission Bits nicht dagegen schützen.
07:03
Das zweite Problem ist, dass wir mit den Permission Bits nur durch die Rechtevergabe des Eigentümers überhaupt Benutzungseinschränkungen bekommen. Das soll heißen, wenn der Eigentümer einer Datei leichtsinnig ist und sie für alle weltles und schreibbar macht,
07:23
dann gibt es nichts von den Permission Bits her, was diesen Zugriff von anderen eigentlich Unberechtigten verhindert. In der Literatur werdet ihr das finden als DAC, das soll heißen Discretionary Access Control.
07:41
Discretion ist bittesehr nicht die Diskretion, die wir am Bankschalter oder in einer Arztpraxis hoffentlich üben, sondern Discretion hier ist das Ermessen. Das Ermessen des Eigentümers Permission Bits für seine Dateien zu setzen. Warum ist das Programm wichtig? Naja, ein Standardbeispiel ist das Adressbuch.
08:03
Mein Mailclient muss natürlich mein Adressbuch lesen können, wenn ich Mails verschicke, muss Namen zuordnen können und so weiter. Ich sehe aber erstmal keinen Grund, warum mein Browser, der in meinem Namen läuft und auf meine Fall zugreifen darf, warum der aufs Adressbuch zugreifen können soll.
08:20
Wenn ich es irgendwie schaffe, dem Browser den Zugriff auf mein Adressbuch zu verweigern, dann führt das dazu, dass selbst irgendein Hack, irgendein gehackter Browser, wie auch immer, nicht meine Adressen auslesen kann und dem Bösewicht übermitteln. Es ist also durchaus sinnvoll, dass ich dem Browser, der in meinem Namen läuft, trotzdem den Zugriff aufs Adressbuch verbieten kann.
08:41
Die Anwendung spielt eine Rolle. Anderes Beispiel, etc-passwd, ist zwar nicht mehr die Passwortdatei, sondern nur noch die Liste der Benutzendefinitionen, aber auch die ist auf der Maschine grundsätzlich für jeden lesbar. Normalerweise würde ich jetzt die Frage in die Runde stellen, warum.
09:03
Angesichts der Runde beantworte ich sie gleich selber, damit ls-l, der UserID, auch einen echten Usernamen zuordnen kann. Also muss es jeder lesen können, aber es gibt eigentlich keinen Grund, warum ein Webserver, der auf der Maschine läuft, irgendwie etc-passwd in aller Welt rausposaunen dürfte.
09:21
Sprich, wenn irgendjemand den Webserver hackt, möchte ich trotzdem nicht, dass er etc-passwd übermittelt bekommen kann. Gibt keinen Grund dafür. Das ist eine Sache, die gehört auf die Maschine und nirgends wo sonst hin, nicht in der Öffentlichkeit. Das heißt, es gibt sehr wohl ein Interesse daran, Programm spezifischer Beschränkungen zu haben,
09:41
die ich durch Permission Bits nicht ausdrücken kann. Ich möchte also gerne strengere Mechanismen haben. Ich möchte sie auch dann durchsetzen können, wenn der Benutzer diese Vorgabe vielleicht gar nicht macht. Das soll heißen, der Admin soll Sachen einschränken können.
10:02
Und weil diese Zugriffskontrolle jetzt nicht mehr dem Ermessen des Benutzers, des Dateieigentümers unterliegt, sondern für alle verpflichtend ist, der Admin führt sie verpflichtend ein, heißt sie MAC mandatory access control. Wenn wir sowas haben, stellt sich natürlich die Frage, wie steht es mit Standards?
10:21
Dürfen wir das überhaupt? Erlaubt uns das die strenge Norm? Die strenge Norm, die für uns interessant sein könnte, ist POSIX oder offiziell der Standard 1003.1. Ich habe leider nur die 2001er-Fassung vorliegen. Ich habe mich ehrlich gesagt gar nicht gekümmert, ob es eine neuere gibt. Von der IEEE wahrscheinlich gibt es.
10:43
Und dieser POSIX-Standard definiert zunächst mal die File Access Permissions. File Access Permissions sind genau die, die wir schon seit Urzeiten aus Unix kennen, zurückgehend auf Bell Labs. Also Rate, Write, Execute für User Group und Others. Der definiert die Set User ID und Set Group ID Features und Bits.
11:02
Der definiert die sogenannten Supplementary Group IDs, also genau das, was wir schon immer in Unix haben. So weit, so gut. Wir reden jetzt über strengere und über weitere Einschränkungen. Und dafür hat der POSIX-Standard ein Schlupfloch.
11:23
Laut POSIX-Standard kann es Additional File Access Control Mechanism, oder einen Additional File Access Control Mechanism geben. Das Wesentliche ist, dass dieser Zusatzmechanismus die Zugriffe, die erlaubten gegenüber dem, was von den Permissions Bits her zulässig ist,
11:44
dass der Zusatzmechanismus nur einschränken darf. Er darf nicht erweitern. Also wenn die Permission Bits irgendetwas verbieten, dann darf es nicht durch die Hintertür, durch diesen Zusatzmechanismus erlaubt werden. Aber wenn etwas nach den Permissions Bits durchaus zulässig ist,
12:03
dann darf der Zusatzmechanismus es trotzdem einschränken und damit den Zugriff verhindern. Also bitte nur einschränken, nicht aufweiten. Laut POSIX gibt es dann auch noch, oder ist dann ein Alternate File Access Control Mechanism möglich,
12:23
und dazu steht nichts weiter drin. Das heißt, da ist offen für Anbieter, für Hersteller, ob sie irgendetwas anderes machen wollen. Typisches Beispiel hier wären die ACLs, also Access Control Lists. Aber über die reden wir hier und heute nicht in diesem Vortrag.
12:42
App Armor und SE Linux sind jeweils ein solcher Additional Mechanism. Das heißt, sie dürfen einschränken. Die Implementierungsbasis ist die gleiche. Es gibt im Kernel sogenannte Security Modules. Und App Armor oder SE Linux, die beiden de facto vorhandenen Mechanismen,
13:05
nutzen die, bauen darauf auf. Beide sind insofern einander ähnlich, als sie selektiv sind, soll heißen, sie überwachen grundsätzlich erst mal ausgewählte Anwendungen. Ich werde es organisatorisch nicht schaffen, wirklich alle Anwendungen,
13:25
alle Programme meines Systems zu überwachen, weil es viel zu viele Tools gibt, gerade in der UNIX-Feld, sprich auch in Linux, die allgemein sinnvoll sind, die auf beliebige Files zugreifen können. Angefangen vom Copy oder CAT.
13:42
Mein VI darf, oder welcher, was auch immer der Lieblingseditor ist, darf natürlich auch Log Files usw. lesen, sonst hätte ich große Schwierigkeiten mit der Administration. Das heißt, es gibt sehr viele unüberwachte Anwendungen. In der Terminologie von App Armor und SE Linux
14:01
heißen solche unüberwachten Anwendungen unconfined. Unconfined, also unbeschränkt. Wenn ihr das im Zusammenhang mit App Armor und SE Linux lest, dann heißt das, das sind Programme oder Dateien, für die es keine spezifischen Einschränkungen gibt, für die also nur der normale Access-Bit oder Permission-Bit Mechanismus greift.
14:26
Wenn aber App Armor oder SE Linux in der Distribution dabei sind, dann liefert diese Distribution üblicherweise Profile, auch Policies genannt, die im Normalfall für eine Standardinstallation hoffentlich passen sollten.
14:42
Es wäre schlimm, wenn uns die Distribution ein Profil liefert, was nicht zu den Defaults passt. Und dieses Profil kann üblicherweise der Admin ändern oder er kann weitere erstellen und damit insbesondere also die Kontrolle verfeinern.
15:00
Was außerdem beide Mechanismen haben, ist ein Lernmodus, soll heißen, wenn ich irgendwie merke, ich führe was Neues ein oder ich habe was, das möchte ich überwachen, aber ich weiß noch nicht genau, was das legal machen darf, dann kann ich die Komponente, also SE Linux, App Armor in den Lernmodus schalten.
15:22
Das führt dazu, dass sie alle Verstöße gegen eine bereits definierte Politik nicht verhindert, blockiert, wie es es eigentlich machen würde, sondern dass sie diese Verstöße nur protokolliert und dann geschehen lässt. Das heißt, am Ende eines solchen Laufs habe ich dann ein Protokoll
15:43
und da stehen all die Fälle drin, wo die existierende Politik den Zugriff eigentlich verboten hätte. Und dann kann ich als Admin hingehen, mir dieses Protokoll greifen und nachgucken, ist das richtig, dass der Zugriff erlaubt ist oder ist das falsch.
16:01
Wenn der Zugriff erlaubt sein soll, dann muss ich die Politik an der Stelle ein bisschen erweitern, muss ich den Zugriff zulassen. Wenn er verboten sein soll, dann lasse ich die Politik so, wie sie ist. Und wenn ich mit diesem Lauf, mit diesem Lernbetrieb fertig bin, schalte ich die Komponente für wirklich aktiv und sage,
16:21
und ab jetzt überwachst du wirklich, du protokollierst nicht nur, du überwachst. Und dann werden eben solche Verstöße verhindert. Grundsätzlich, wie gesagt, App Armor und SE Linux können die Permission Bits oder das, was von den Permission Bits her zulässig ist, nur einschränken. Das heißt, bei einem Zugriff, den irgendein Programm macht,
16:44
bei irgendeinem Systemcall, werden zuerst die Permission Bits geprüft. Und wenn die Permission Bits den Zugriff nicht erlauben, dann ist die ganze Sache damit schon beendet. Das Programm kriegt eine Fehlermeldung, ganz normal. Wenn aber die Zugriffs Bits die Operation erlauben,
17:02
dann guckt App Armor bzw. SE Linux nach, nach Positivlisten, gibt es überhaupt irgendeine Policy für dieses Programm? Wenn es keine Policy gibt, gibt es auch keine Überwachung, dann sind die Permission Bits alles, was zählt, und dann ist der Fall auch beendet. Und der Zugriff geht durch und das Programm läuft weiter.
17:25
Wenn es aber eine Policy gibt, dann guckt App Armor bzw. SE Linux in diese Policy rein. Ist der Zugriff erlaubt? Wenn ja, wird er durchgeführt. Wenn nein, gibt es eine Fehlermeldung.
17:41
Diese Fehlermeldung ist genau die gleiche, die das Programm sowieso bekommen würde, wenn die Permission Bits etwas verbieten. Das heißt also im Zweifelsfalle der Permission Error E-Perm. Ich glaube 13 ist der Code. Und außerdem werden solche Verstöße protokolliert,
18:01
typischerweise im System-Log. Nein, sorry, E-Excess ist der Code. Das heißt, das Programm kriegt die normale Reaktion und außerdem eben noch das System-Log. Einen normalen Verstoß gegen Permission Bits würde ich im System-Log nicht sehen. Eine App Armor oder SE Linux Kontrolle, die das verändert, die sehe ich sehr wohl.
18:22
Ich habe bisher App Armor und SE Linux so gleich beschrieben, gleich benannt, weil diese Prinzipien eben wirklich für beide Komponenten übereinstimmen. Gucken wir uns jetzt mal spezifisch App Armor an. App Armor ist entstanden ab 1998 bei einer Firma im Munix.
18:43
Die wurde dann, wie das unter Firmen so häufig vorkommt, aufgekauft, in diesem Falle von Novell. Novell hat das noch weitergeführt bis 2007 und hat dann irgendwie die Lust verloren. Und zwei Jahre später hat es Canonical wieder aufgenommen und 2010 im Oktober in den Linux-Könnel eingebracht.
19:02
Das heißt, seit Oktober 2010 haben wir grundsätzlich im Linux-Könnel App Armor Version 2.6.36. Und es ist aufgenommen in die Distributionen von OpenSuse und von Ubuntu. Klar, ich meine, wenn Canonical was macht,
19:21
dann wird es im Zweifelsfalle mindestens bei Ubuntu landen. Es sollte keine große Überraschung sein. Und die Basis für die ganze Implementierung sind Textfiles, die alle abgelegt sind im Verzeichnis etc-apparmer.de.
19:41
Und das Textfile hat dann üblicherweise einen Namen, der an das überwachte Binary erinnert. Und weil ich gesagt habe, ich nehme MySQL als Beispiel, steht jetzt hier also der Pfadname des MySQL-Demons, wobei dann ein Slash ersetzt ist durch einen Punkt. Das ist bitte sehr nur eine Erleichterung, nur eine Zugriffshilfe.
20:05
Wichtig ist, dass in der Datei selber der volle Pfadname nochmal korrekt steht. Das heißt also, wenn der Pfadname Punkte enthält und jetzt hier niemand mehr unterscheiden kann, was ist wirklich ein Punkt, was ist ein Platzhalter für einen Slash, spielt das alles keine Rolle, weil diese Namen hier nur, ich sag mal, Lesehilfe, Sortierhilfe sind.
20:26
Wichtig ist der Inhalt. Inhalt, Verständnis fragen sofort, ja. Sorry? Richtig, wenn man eine Datei umbenennt, das war die Frage,
20:45
und dadurch also ihr Pfadname nicht mehr in der Profildatei auftaucht, dann ist sie automatisch unconfined, es sei denn, ich führe ein neues Profil für diesen neuen Pfad ein. Richtig. Das ist grundsätzlich bei AppArmor der Fall, weil es eben nur über Pfadnamen geht.
21:05
Okay, nochmal bitte die Frage.
21:24
Ja, die Frage ist, kann ich die Dateien unter Home ablegen? Ich nehme an, du beziehst dich auf die AppArmor-Profile. Ich glaube nicht, dass das geht. Ich habe es nie probiert.
21:42
Ich habe auch zugegeben, keine intensive Suche durchgeführt. Was kann man alles noch machen damit? Ich halte es für sinnlos. AppArmor oder auch SE Linux sind dafür da, dass der Admin Zusatzregeln festlegen kann und der Admin hat Root-Rechte und der wird das, wie sich das gehört, unter etc.
22:02
In diesem Falle etc.apparmor.de ablegen. Also Profile unter Home abzulegen. Erstens mal, wenn ich keine Root-Rechte habe, dann muss ich davon sowieso die Finger lassen, weil ich dann die Maschine nicht administriere. Und zweitens Profile unter Home abzulegen, ich weiß nicht.
22:26
Das läuft ja schon fast unter bösartig im Sinne Unklarheitsstiften. Wenn es gehen sollte, heftig davon abraten. Ich hoffe mal, dass es gar nicht geht, weil ich das für ziemlich unsinnig halte.
22:47
Theoretisch ja. Wenn es nur um weitere Einschränkungen geht, soll ich dann nicht auch als User weiter einschränken können? Theoretisch ja.
23:00
Aber praktisch, dass ich als User jetzt irgendeine von den überwachten Systemkomponenten hindere? Ich weiß nicht. Also ich glaube nicht, dass das sinnvoll ist. Als User habe ich da im Zweifelsfalle mit den Permission Bits doch bessere Möglichkeiten. Dann würde ich dem Owner die Rechte... Ach so, das geht auch nicht.
23:24
Ich glaube nicht, dass AppArmor oder SE Linux sowas vorsehen, weil der ganze Ansatz nicht dafür da ist. Der Ansatz ist eigentlich gedacht, um das nachzuholen, was der leichtsinnige User versäumt. Der Ansatz ist nicht dazu da, dem besonders strengen User noch mehr Möglichkeiten zu geben.
23:42
Könnte man über die Philosophie diskutieren, aber tut mir leid, das springt dann zu sehr aus dem raus, was ich mir für diesen Vortrag vorgenommen habe.
24:01
Man kann mit Include-Anweisungen arbeiten, richtig, aber dazu müsste man das Pfeil unter ETC manipulieren. Das heißt, mindestens dafür braucht man Ruthrechte. Und das dann zu machen... Wie gesagt, wenn man unbedingt Unklarheit stiften will, dann soll man so vorgehen, aber es gibt von mir keinen, das ist aber auch gut so.
24:26
AppArmor läuft auf der Maschine als Service, das heißt grundsätzlich kann man es als Service starten und stoppen. In älteren Versionen, sprich Sys5.init mit dem Service-Kommando, in neueren wäre System-Control dran.
24:41
Das Problem ist, Stopp ist nicht Stopp. Das wäre ja zu schön, das wäre ja viel zu einfach. Wenn ich einen AppArmor wirklich abschalten will, warum auch immer, kann ja momentan mal sinnvoller sein, dann heißt das bitte nicht Stopp, sondern Teardown.
25:01
Im Service-Kommando ist das kein Problem. Beim Service-Kommando kann ich beliebige Argumente mitgeben und wenn mein Skript die implementiert, ist gut. Wie das mit System-Control läuft, muss ich gestehen, habe ich immer noch nicht erforscht. Also in System-Control wird ein Teardown als Argument garantiert nicht akzeptiert.
25:21
Ob man jetzt in System-Control Stopp ausreicht oder ob es da irgendwelche anderen Tricks gibt, sorry, die Frage ist eine sehr sinnvolle, aber ich muss die Antwort schuldig bleiben. Grundsätzlich kann ich das eben starten, ganz normal als Service. Und ich kann es in verschiedenen Modi fahren.
25:42
Es gibt den Modus Complain, Enforce und Audit. Und jetzt verlässt mich mein Gedächtnis. Es ist doch schon ein paar Wochen her, dass ich die Folgen gemacht habe. Enforce ist klar, wenn AppArmor im Modus Enforce läuft, dann greifen die Zugriffsmechanismen und das, was von den Profilen verboten wird, wird blockiert.
26:08
Complain ist meiner Erinnerung nach der Lernmodus, aber wie sich Audit jetzt unterscheidet? Es lockt alles. Okay, irgendwie muss man die Platte erfüllen, die sind sowieso viel zu groß.
26:26
Danke. Es gibt ein Programm AA Status, was ich mit Ruhdrechten aufrufen kann und was mir ein bisschen was ausgibt, das finde ich ausgesprochen interessant, weil das einen sehr schönen Überblick gibt.
26:41
Ich habe jetzt also hier mal auf meinem System, das war ein Ubuntu 16.04, die eine Beispielausgabe mir erstellt, sagt mir erstmal, dass der Modul geladen ist und dass fünf Profile in diesem Fall aktiv geladen sind und alle diese Profile laufen im Enforce Modus, sprich sie verhindern wirklich das, was laut Profil nicht erlaubt ist.
27:07
Und es geht über den DHCP Client, es geht um den Network Manager, es geht um einen Connection Manager und es geht um den MySQL Demon. Die Profile sind halt mitgeliefert.
27:21
Keines ist im Complain Modus. Von diesen fünf Profilen laufen für zwei wirklich auch Prozesse, sodass die Profile was zu tun haben. Die anderen sind halt geladen, aber der entsprechende oder darin genannte Prozess läuft nicht. Und diese beiden Prozesse sind der DHCP Client und der MySQL Demon.
27:43
Wenn keine Profile im Complain Modus sind, können auch keine Prozesse im Complain Modus sein, das ist irgendwie logisch. Und es gibt auch keine Prozesse, für die es ein Profil gibt, was aber abgeschaltet wäre, die unterste Zeile. Also keine unconfined mit definiertem Profil.
28:04
App Armor ist sehr schön systematisch. Ein Profil muss geladen sein beim Start des Prozesses. Ich kann nicht erst einen Prozess starten und dann sein Profil laden und dann glauben, dass es die Aktion dieses Prozesses einschränkt. Wäre auch Blödsinn, weil der Prozess ja dann irgendwas zu Anfang machen konnte, was das Profil eigentlich verbietet.
28:27
Aber weil er damit schnell genug war, ist es durchgegangen. Und dieses nachträgliche Einschränken, das wird im Zweifelsfall jede Programmlogik durcheinander bringen, wenn es am Anfang ging und später nicht mehr. Das heißt, wenn ich wirklich einen Prozess überwachen will, dann muss ich erst App Armor starten und dann den Prozess.
28:50
App Armor startet normalerweise beim Boot, das heißt, das ist sichergestellt. Wenn ich andersrum vorgehe, wenn ich erst irgendwann einen Teardown mache und dann App Armor neu starte,
29:01
dann werden automatisch alle laufenden Prozesse unconfined, weil sie in einer kurzen Zeitspanne nicht überwacht waren und beliebig was machen durften. Und nur der spätere Prozessstart wird dann also das Profil wieder aktivieren. Ob der Prozess überwacht wird, kann ich mit ps rauskriegen. Mit der Option minus groß z sehe ich, ob er überwacht wird, ja oder nein.
29:25
Ich kann auch ins slashprog-Filesystem gucken. Weil ich eigentlich als Ziel habe, dass der Admin dann ungefähr weiß, wie verhält er sich, wie kommt er mit Problemen zurecht,
29:40
habe ich natürlich auch ein paar Tests gefahren, sprich ich habe ganz normale MySQL Pakete, in diesem Falle MySQL 47 auf dem Ubuntu 16 installiert. Ihr seht da die Liste, App Armor ist natürlich auch installiert und damit kann ich dann ganz normal arbeiten. Das Datadear ist per Default und da war lib MySQL, der Port ist 3306.
30:03
Ich habe die Adresse geändert, um alle Netzzugriffe zu erlauben. Und dann startet der Server und läuft ganz normal und kann auf seine Datenbestände zugreifen. Und ich kann auch remote damit arbeiten, das funktioniert alles, wie es soll. Das ist der Normalzustand, dafür sorgt das ausgelieferte Profil.
30:22
Jetzt kann ich ja, aus welchen Gründen auch immer, mir vornehmen, ich möchte meine Daten anderswo ablegen. Also, ich habe eine separate Platte und die heißt jetzt in meinem Fallsystem, damit es so schön deutlich wird, slash other disk und da habe ich ein Unterverzeichnis MySQL und das möchte ich als Datadear nehmen.
30:42
Dann würde ich also die entsprechenden Startscripten von MySQL bzw. Config Files usw. anpassen. In diesem Falle hier auch noch das Skript unter Systemd, ist dann leider nötig. Und dann kann ich MySQL den Demon wieder neu starten. Sudo System Control Start MySQL.
31:02
Und dann kriege ich eine schöne Fehlermeldung. Job failed because usw. Und dann wird mir vorgeschlagen, ich könnte mit System Control Status oder mit Journal Control nachgucken, was denn da passiert ist und was das Problem ist. Ich persönlich empfehle dir den Informationsgewinn, den ich aus diesen Programmen kriege,
31:23
als ausgesprochen gering, um es mal vorsichtig zu formulieren. Da steht wenig Hilfreiches für mein Verständnis. Aber zum Glück habe ich ja gesagt, der Colonel lockt die Ablehnungen, die gemacht werden. Und in diesem Falle sehe ich also in Warlock Syslog schöne Zeilen und da steht AppArmor gleich denied.
31:47
Also nach AppArmor kann ich natürlich wunderschön greppen, nach denied kann ich auch greppen. Und damit erfahre ich schon wesentlich mehr. In diesem Falle wollte also der MySQL Demon, der Server Prozess, ein MKNode machen, um was anzulegen.
32:04
Und zwar in diesem Falle ein Temp-File für InnoBase. Und das wurde ihm verboten. Also da steht denied drin, da steht ein Zeitstempel drin, da steht eine ID drin und so was, alles, damit komme ich klar.
32:24
Und ein, zwei Zeilen weiter steht dann, dass auch ein Anlegen einer Datei, nämlich EB Data 1, war ja eine Neuinstallation quasi, mit Schreiben und Lesen, dass das verboten wurde. Gut, ist natürlich nicht allzu überraschend. Ich habe ja gesagt, ich bin vom Default abgewichen und habe das unter slash other disk gemacht.
32:49
Was muss ich also machen? Na das einfachste ist, ich greife in das AppArmor Profil ein. Wie gesagt, das liegt unter etc-apparmor.de. Und wenn ich mir das angucke, ich habe jetzt hier nur die unterschiedlichen Zeilen,
33:02
nicht die ganze Datei, weil die viel zu lang ist. Wenn ich das ändern will, dann finde ich da in der Datei drin, dass also ein data.deaccess kommentiert ist und das normalerweise also aufs Datadirectory zugegriffen werden darf.
33:21
Und da wahrlebt man SQL lesend und belebig absteigend, lesend, schreibend und anlegend. Und das muss ich dann natürlich bei meiner Konfigurationsänderung ersetzen durch other disk MySQL.
33:43
Das wäre der Quick and Dirty Fix, der funktioniert. Der hat natürlich einen Haken. Der Haken bei diesem Fix ist, dass ich in eine Datei eingreife, etc.apparmor.de user.spin.mysqld, die vom Paketmanagement kommt, die von Ubuntu mit der AppArmor-Komponente mitgeliefert wird.
34:06
Das heißt also, ich greife in eine vom Paketmanagement kontrollierte Datei ein und kriege entsprechend irgendwann Upgrade-Probleme. Also Quick and Dirty, ja funktioniert, ist aber nicht so das Beste.
34:21
Es gibt eine andere Möglichkeit. Es gibt auch unter etc.armor.de ein Unterverzeichnis Local. Und wenn ich da drin Dateien ablege, dann haben die Vorrang. Ich kann lokal Anpassungen machen und das ist eben nicht mehr vom System ausgeliefert.
34:42
Das heißt, ich kann eine Local-Datei für den MySQL Demon einführen und da das reinschreiben, was ich erlauben möchte. Ich kann auch kontrollieren mit DPKG, dass diese Datei eben nicht dem Paketmanagement unterliegt. Und die kommt zwar mit, wird dann aber nicht mehr überwacht.
35:03
Und da steht schon als Kommentar sehr schön drin, dass es site-specific-editions-overrides sein. Und da kann ich dann slash other disk eintragen und damit habe ich mein Problem gelöst. Grundsätzlich könnte mir ja was ähnliches passieren beim Port.
35:22
Wenn ich also vom 3306, aus welchen Gründen auch immer, auf den 3307 abweiche, ja passiert zum Glück nichts, denn der Port wird von den app-armor-Profilen nicht überwacht. Da muss ich nichts anpassen. Erweitert, wollte gerade sagen.
35:47
Ich glaube nicht, dass das was ändert. Also wenn ich dann den anderen blockieren wollte wirklich, dann müsste ich immer noch ins Paketmanagement eingreifen. Die Frage ist, ob ich... Okay, danke.
36:04
So tief war ich nicht eingestiegen, finde ich gut. Also fürs Protokoll. Ich kann in die local-Datei auch die Neiregeln eintragen. Normalerweise würde local das, was global gilt und vom Paketmanagement kommt, erweitern.
36:20
Wenn ich da aber eine Neiregel eintrage, dann hat die, weil local Vorrang hat, eben Vorrang vor der globalen oder vor der allgemeinen Datei und verbietet dann etwas explizit, was da drin erlaubt wäre. Gut, soll heißen, wenn ich also eine local-Datei anlege, kann ich den Pfad ändern und danach kann ich also vom Standard, vom Default abweichen und mein System wird weiter laufen.
36:46
Das ist der eine Teil. Aber dann erinnern wir uns alle mehr oder weniger trotz unserer kurzlebigen Nachrichtenlage daran, dass es da sowas Böses wie ransomware und locky und so weiter gab. Und das können wir ja auch mal simulieren.
37:02
Was würde denn passieren, wenn so ein Bösewicht oder ein Vinera-Bösewicht Zugriff hätte auf unseren Rechner, möglicherweise noch mit Rudrechten? Also grundsätzlich habe ich in mySQL natürlich eine Tabelle der Benutzer. Und was da drin steht, kann ich mir angucken. Ich gucke jetzt nach user-host-authentication-string und dann sehe ich,
37:23
dass das die drei definierten Benutzer sind. Alles in Ordnung. Jetzt simuliere ich mal auf der Kommandozeile den Bösewicht. Und zwar benutze ich ein Encryption-Programm. CC-Encrypt ist standardmäßig dabei, bzw. kann man als Paket schlimmstenfalls installieren.
37:42
Und verschlüsselte diese user-Tabelle von mySQL mit irgendeinem Schlüssel. Wenn ich das mache, dann sehe ich, dass das Ding erstens mal um 32 byte länger wird.
38:01
Und zweitens, dass der Name geändert wird. Na gut, gegen die Namensänderung könnte der Loki ja immer noch was machen. Und damit mySQL das findet, mache ich die also rückgängig mit einem Move. Soll heißen, ich habe jetzt unter dem alten originalen Namen eine verschlüsselte Datei. Hm, warum?
38:20
Ich habe doch AppArmor. Ich habe doch AppArmor laufen. Warum hilft mir das nicht? Na erstens mal, der Effekt ist natürlich klar. Wenn die Datei verschlüsselt ist, dann kann der mySQL diemen, den Inhalt nicht mehr lesen. Er findet die Benutzer-Tabelle nicht und weigert sich zu starten.
38:41
Die interessantere Frage, warum war das möglich? Ja, wie gesagt, AppArmor überwacht definierte Programme. Und wenn ich für CCN-Krypt kein Profil habe, was ausgesprochen überraschend wäre, dann ist auch klar, dass AppArmor das, was CCN-Krypt macht, nicht überwacht und die böse Aktion nicht verhindert.
39:03
Und jetzt ganz egal, ob der Bösewicht das vorhandene CCN-Krypt nutzt oder was eigenes mitbringt oder wie auch immer, wenn er grundsätzlich mit Ruhrechten auf dem System ist, kann er, Klammer auf leider, drei große Ausrufezeichen, Schaden anrichten und kann meine Daten Files ändern
39:22
und mir so den Datenbankbetrieb lahmlegen. Dagegen schützt mich AppArmor leider nicht. Sprich, AppArmor, wir werden nachher sehen auch ESE Linux, sind kein Schutz gegen Krypto-Trojaner. Schade, aber das ist der derzeitige Stand.
39:45
Noch ein paar grundsätzliche Tipps. Ich kann per Kommando einzelne Dienste umschalten. Ich kann also einzelne Dienste aus der Überwachung ausnehmen, zum Beispiel, weil ich gerade defaults ändern will. Ich kann es auch durch einen Disable, die Überwachung eines einzelnen Dienstes komplett abschalten.
40:05
Ob das sinnvoll ist, ist eine andere Frage, aber es ist zumindest möglich. Im deutschen Ubuntu-Users-Wiki gibt es eine ausführliche Information über AppArmor, OpenSuse hat welche und es gibt ein eigenes AppArmor-Wiki.
40:21
Und da findet man alles weitere. So viel erstmal grundsätzlich zur AppArmor-Frage. Nein, AppArmor macht das nicht. AppArmor hat grundsätzlich das Programm, also das Binary, das File als überwachte Einheit.
40:48
AppArmor gibt mir keine Möglichkeit, irgendwie gezielt Dateien oder Verzeichnisse zu schützen.
41:11
Wenn du das Programm unter einem neuen Namen anlegst, unter Home oder auch irgendwo anders, irgendwie was am Namen drehst, dann gehst du damit de facto an AppArmor vorbei.
41:22
Ja, die Frage ist nur, wann kannst du das und wie kannst du das machen? Also für Programme, die du von Hand aufrufst, geht das natürlich, nur machen wir uns nichts vor. Das, was AppArmor da mitgeliefert hat, die fünf Profile, das waren genau Systemprogramme.
41:41
Also die Zielsetzung von AppArmor und auch von SI Linux ist üblicherweise, die wichtige Systemkomponenten, dazu zählt nun mal auch die Datenbank, zu schützen beziehungsweise solche Programme, die von außen erreichbar sind, denen ich von außen Befehle geben kann, denen möglichst Zurufe zu verbieten,
42:05
die Schaden anrichten könnten. Also Webserver und ähnliches. Diese AppArmor und ich schätze mal auch SE Linux liefern also keine Profile mit für meinen Mail-Client oder für meinen Browser oder so, weil die üblicherweise nicht solchen Schaden anrichten können
42:22
und weil die Erstellung eines Profils dafür mächtig aufwendig wäre, machen wir uns nichts vor.
43:21
Super, danke, darauf bin ich noch nicht gestoßen. Kurzform, wenn ein Prozess überwacht wird, dann wird das Profil auch an Kindprozesse vererbt, auch wenn die andere Namen haben. Okay, danke. So, ich hab gemerkt, ich muss mich sehr sputen. Also versuchen wir auf einem noch schnelleren Pfad SE Linux zu beschreiben.
43:46
Die Geschichte von SE Linux ist ein bisschen komplizierter. Das fing an 1973 mit einem rein akademischen Projekt. Da gab es von den Herren Bell und Lapadula ein Sicherheitsmodell und das sollte Informationsfluss nur aufwärts erlauben.
44:03
Hintergrund, wie so oft in solchen Zusammenhang das Militär, also vom einfachen, gefreiten Dienstgrad da unten über die ganzen Unteroffiziere, Offiziere hoch in den Generalstab, wird Information immer vertraulicher, immer wichtiger. Sie darf nur hoch fließen, sie darf in diesem Modell nicht runter fließen.
44:20
Wie man da in diesem Modell mit Befehlen und Anweisungen umgeht, überlasse ich der Fantasie der Zuhörer, ich weiß es nicht. Ab 1992 haben dann die NSA und irgendwelche Entwicklungspartner
44:42
angefangen für unter anderem Linux eine Sicherheitsarchitektur mit dem Namen Flask zu entwickeln. Ich habe vergessen, was das ausgeschrieben heißt, egal. Und das ist dann 2004 nach Fedora Core gekommen und so nach Red Hat reingekommen, Red Hat 4.
45:02
Ja, wer hat Fedora natürlich, Red Hat inzwischen auch Open Source, Debian als Option oder als Alternative und die Basis für SE Linux sind nicht Pfadnamen, sondern die Basis für SE Linux sind erweiterte File-Attribute.
45:22
Auch SE Linux läuft im Kernel, aber es ist kein Service, es ist kein sichtbarer Prozess. Ich kann ihn also nicht so einfach starten oder stoppen. Es gibt eine Config-Datei und wenn ich die ändere, dann greift die Änderung beim Reboot. Ich kann da also einschreiben Set Enforce auf 0 oder auf 1.
45:43
Ich kann den Zustand abfragen mit dem Kommando Get Enforce. Ich kann für einzelne Prozesse mit dem Kommando SE Manage was machen. Achtung, da werde ich nachher nochmal darauf hinweisen, SE Manage ist in der Default Installation schon nicht dabei.
46:01
Wer also meint, dass er mit SE Linux irgendwas machen muss und vielleicht ändern muss, bitte gleich Zusatzpakete installieren. Komm nachher nochmal. Ja, ich kann mir wie gesagt den globalen Status anzeigen. Ich kann für einzelne Module mit SE Module für einzelne Prozesse mir was anzeigen lassen.
46:20
Auch hier haben wir die Option Groß Z. Das ist schon mal sehr angenehm, dass die für beide die gleiche Option ist. Also mit PS minus Groß Z kann ich gucken, ob der Prozess in irgendeinem definierten Kontext, sprich eben nicht unconfined, sondern irgendwie eingeschränkt läuft. Aber weil wir jetzt nicht mehr nur über Pfadnamen und Prozesse reden,
46:40
sondern über ein bisschen mehr, kann ich mir das gleiche anzeigen lassen, diesen sogenannten Kontext für einen Benutzer mit ID unter Option Groß Z und für einen Dateikontext. Also ALS hat auch eine weitere Option, da gibt es ja noch nicht genug. Man braucht optionale Pakete, das habe ich gesagt. Und ansonsten habe ich den gleichen Test auch mit SE Linux gemacht.
47:04
Ich habe aus irgendwelchen Gründen, weiß nicht mehr was, hier aber den Commercial Client installiert gehabt für die Testzwecke. libSE Linux ist sowieso dabei. Interessant, weil ich gesagt habe, Zusatzpakete hier. Policy Core Utils und Policy Core Utils Python, SE Linux Policy, SE Linux Policy Targeted.
47:25
Also vor allen Dingen die Policy Core Utils sind die, die ich brauche für SE Managed, um da überhaupt irgendwas machen zu können. Sonst fehlt mir das Programm auf der Maschine. Ja und dann im Prinzip den gleichen Test wie vorher auch. default data directory varlib mysql port 3306.
47:42
Zugriff übers Netz freigeschaltet. Datadeer geprüft, alles funktioniert. Jetzt der eigentliche Test. Ich ändere das Datadeer und starte mysql neu. Und kriege die gleiche Aussage, kräftig oder in meinen Augen irreführende Fehlermeldung.
48:02
Auch hier finde ich nicht viel. Wenn ich jetzt hier im Log nachgucke, dann kommt der genaue Ort darauf an, wie ich meinen Logging-Mechanismus eingestellt habe. Also wenn ich mit Syslog oder R-Syslog oder anders arbeite, dann wechselt da der Pfad.
48:23
Ihr müsst bitte den richtigen finden. Das interessante sind Meldungen mit type gleich AVC. AVC ist nun eine weitere drei Buchstaben Abkürzung, damit der Vorrat nicht ausgeht. Das ist der Access Vector Cache. Das heißt im Access Vector Cache werden SE Linux Entscheidungen gespeichert,
48:43
um die Performance zu erhöhen. Und da steht jetzt also drin, dass es eine Audit Message gibt, dass der AVC verweigert hat, eine Append-Operation für diesen Prozess. Das war der mysqldemon. Der wollte ans Errorlog was anhängen und das ist ihm nicht erlaubt worden.
49:07
Der Source-Kontext, und da sind wir jetzt bei SE Linux spezifischen Sachen, war, dass es der System-User ist in einer System-Role und mit dem mysqld-Typ. Das ist das mysqld-Binary und der Target-Kontext, Target ist die Datei,
49:25
mit der was gemacht werden soll, also das Errorlog. Der Target-Kontext ist der System-User mit einer Objektrolle und einem Default-Typ. Und der mysqld-Typ als Prozess darf offensichtlich nicht auf einen Default-Typ als File zugreifen.
49:42
Das ist ihm verboten. Mysqldemon soll heißen also, meine Errorlog-Datei hat einen Typ, auf den der mysqldemon der Server-Prozess nicht zugreifen darf. SE Linux unterscheidet also zwischen Subjekten, das sind Prozesse oder auch Benutzer, also IDs,
50:06
und Objekten, das sind typischerweise Files, Directories und so weiter, was da alles im File-System existiert. Und hat dann das Konzept eines Kontexts, ein Kontext besteht aus einem User und einer Rolle und einem Typ.
50:21
Und der User-Kontext ergibt sich üblicherweise aus dem Login, wenn es ein interaktiver Benutzer ist, beziehungsweise aus anderen Einträgen in der PassWD, wenn es ein System-User ist, wie zum Beispiel mysql, in dessen Namen der Prozess läuft. Und User sind für bestimmte Rollen zugelassen und Rollen sind für bestimmte Typen zugelassen.
50:47
Falls ihr jetzt euch so still vor euch hin denkt, das ist aber kompliziert, ja, sehr richtig, ist es. Und der Mechanismus ist also, dass Subjekte nur dann auf Objekte zugreifen dürfen,
51:02
wenn der Subjekt-Kontext, ja, jetzt heißt es nicht mehr Kontext, jetzt heißt es Domain, damit es nicht zu einfach wird, für den Objektyp zugelassen ist. Das war das, was ich da zwei Folien zurück hatte.
51:21
Der Subjekt-Kontext enthält den Typ mysqldemon, der Target-Kontext enthält den Typ default und dieser Zugriff ist nicht zugelassen und darum scheitert er. Das steht auch sehr schön in der manchmal doch hilfreichen Literatur.
51:42
Der Hauptmechanismus von SE Linux ist Type Enforcement, also Typkontrolle, Typ Erzwingung. Und fast immer kann man die User und die Rollen ignorieren. Das heißt, ja, in den meisten Fällen sind sie rauschend, in gewisser Weise störendes Rauschen,
52:00
weil sie alle so viel Lärm machen und alles andere verdecken. So steht es zumindest im Admin Guide von Red Hat zu SE Linux. Ja, hier unten haben wir nochmal, warum das scheitert. Damit es nicht zu einfach wird, hat der Kontext eigentlich noch zwei weitere Komponenten.
52:21
Neben dem dreien Subjekt-Rolletyp gibt es auch noch Level und Category. Und dann kann man mal die Level Security einführen bzw. mal die Category Security. In der Praxis spielen die zum Glück keine Rolle und ich weise insbesondere auf den letzten Satz hin.
52:42
Multi-Level Security auf einer Workstation ist unbenutzbar. Ja, warum? Wenn ich alle möglichen Zugriffe kontrolliere und das dann noch über verschiedene Levels, dann kriege ich auf einer Workstation an einem Punkt ganz große Probleme.
53:00
Das ist nämlich der X-Server. Wenn da alle verschiedene Prozesse und Benutzer und was auch immer da läuft, irgendwelche Ausgaben machen wollen auf dem X-Server, dann werde ich früher oder später in eine Situation kommen, dass die von den verschiedenen Leveln nicht mehr zugelassen wird. Und dann ist mein System wirklich unbenutzbar.
53:23
Also auf einem Server mag das mit sehr viel Administrationsaufwand gehen, auf einer Workstation, wenn jemand eine Woche lang in Verzweiflung stürzen will, möge er es ausprobieren. Grundsätzlich arbeitet SE Linux mit Vererbung oder nach der Ergänzung von vorhin,
53:43
danke nochmal, sollte ich sagen auch mit Vererbung. Die Vererbung betrifft den Kontext von Files und von Directories. Grundsätzlich wird ein Kontext eines Directories auf alle darin enthaltenen Subdirectories und Files vererbt und so rekursiv runter,
54:03
wenn ich nicht an irgendeiner Stelle eingreife und den Kontext explizit ändere. Ähnlich wird auch der Prozesskontext vererbt, wenn ein Binary etwas anderes forgt und exec, dann wird der Prozesskontext vererbt, es sei denn, ich mache ein exec auf ein Binary, für das es gezielt eigene Attribute gibt.
54:29
Also Beispiel, das PassWD. Wo liegt denn das eigentlich unter Bin? Bin wahrscheinlich. Also Bin PassWD hat seinen eigenen Kontext,
54:40
wenn ich von meiner Shell aus Bin PassWD aufrufe, dann läuft dieser Prozess in dem Kontext, der zu seinem Binary gehört. Das ist ja auch sinnvoll, dass da nicht mein normaler Benutzer Shell Kontext gilt, sondern speziell der PassWD Kontext. Und entsprechend hat eben auch der MySQL Server,
55:01
die in seinen eigenen Kontext und so und so viele andere Prozesse oder Binary auch. Und bestimmte Files und Directories haben eben den Typ, der zu diesem Bearbeitungsprogramm passt. Wenn ich jetzt also meinen geänderten Datadiapfad zum Laufen bringen will,
55:21
dann muss ich den Kontext so ändern, dass der Typ passt. Dafür gibt es zwei Möglichkeiten. Beide laufen über SEManage. In beiden setze ich mit SEManage einen File-Kontext. Im einen Fall sage ich explizit, der Typ, MySQL-Datenbank-Typ soll gesetzt werden für meinen neuen Pfad
55:46
und alles, was da rekursiv absteigt. Und wenn ich das gemacht habe, dann ist das in einer internen Struktur im Kernel. Und das muss ich dann auch wirklich ins File-System durchschreiben, damit es aktiv wird und vor allen Dingen damit es eine Reboot überlebt.
56:00
Und dazu dient das Programm RestoreCon, also Kontext, soll heißen für Azadis Zapdia, was ich da oben gesetzt habe, wird der neue Kontext, der neu gesetzte Typ, ins File-System übernommen. Auch der zweite Weg geht über Raschung, über SEManage und setzten File-Kontext.
56:21
Der Unterschied ist, ich setze nicht absolut irgendeinen File-Kontext, den ich mir ausgedacht habe oder den ich einem Handbuch entnommen habe, sondern ich sage, bitte nimm den Kontext von var-lib-MySQL vom alten Default-Pfad und setze ihn auf mein neues Verzeichnis. Sprich, also ich kopiere einen existierenden Kontext, Copy and Paste,
56:42
kennen wir aus der wissenschaftlichen Arbeit, das ist genau die übliche Vorgehensweise. Auch hier muss ich den dann, weil er erstmal nur intern gesetzt wurde, mit RestoreCon auf die Platte durchschreiben. Für ein Port gilt es ähnlich. Wenn ich ein Port ändern will, muss ich eben dem neuen Port einen passenden Typ zuordnen,
57:04
den Service-Port-Typ. Da der Port aber nicht im File-System steht, kann ich da mit RestoreCon nichts machen. Das greift so. Auch hier der Test wie vorhin, ich habe meine Usertabelle und auch hier probiere ich CCN-Krypt und benenne das Ergebnis nachher wieder um.
57:23
Und auch hier scheitert danach der MySQL-Start. Soll heißen CCN-Krypt, wenn ich es von meiner Shell aus aufrufe, die unconfined läuft, dann ist CCN-Krypt auch unconfined. Als relativ generelles Programm gibt es dafür keinen spezifischen Kontext und folglich darf es auf den MySQL-B-Typ zugreifen.
57:44
Die interessante Frage, die mir mal gestellt wurde, lautet, kann man das nicht verhindern? Ich wage mal die Antwort, wahrscheinlich ja. Man muss dafür aber so tief in SE Linux und in die Policies eingreifen, dass man relativ große Chancen hat, wenn man sich da drin bewegt,
58:03
mit seiner Sitzfläche genau die Sachen einzureißen, die man hier brauchen wird. Also das Risiko, wenn ich da die Vollzugriffe plötzlich blockieren will, ist relativ hoch. Wenn man es probieren möchte, bitte ja, aber nicht auf ein Produktionssystem.
58:22
Grundsätzlich also, so wie es normalerweise kommt, sind Kryptotorianer leider auch unter SE Linux weiterhin möglich. Wichtig ist noch, AppArmor hat das Ganze über Klartext-Files gemacht. SE Linux macht es über die erweiterten Attribute. Bitte aufpassen, wenn ihr Backup oder Restore macht.
58:41
Backup soll ja bei fortgeschrittenen Rechnerbenutzern durchaus üblich sein. Habe ich mal gehört oder hoffe ich auch. Dann ist natürlich wichtig, dass diese Zurechtsrechte im Backup drinstehen und dass sie beim Restore mit übernommen werden. Bitte testen kommt wirklich sehr aufs Programm an.
59:00
Copy hat dafür auch passende Optionen bekommen. Copy kann einen Kontext mitnehmen, mit der Option –preserve gleich Kontext oder kann einen neuen Kontext setzen. Kann man alles machen, aber wenn man es nicht explizit angibt, ist das eben nicht. Dann gilt der Ziel Kontext.
59:21
Bei Red Hat heißt die mitgelieferte Policy Targeted und die hat sehr, sehr viele Regeln. Nein, es sind keine Schreibfehler. Also es sind wirklich 262.000 Allow-Regeln. Viel Spaß beim Kontrollieren. Und insbesondere 156.000 De- und Audit-Regeln.
59:41
Soll heißen, es kann sein, dass SE Linux was verbietet und es wird nicht gelockt. Naja, ich stelle mir was anderes als angenehm vor, aber wie auch immer. Tipps zu SE Linux, es gibt einen Admin Guide. Man muss diese weiteren Poly-Pakete installieren.
01:00:00
kann mit noch zusätzlichen Bullions verhalten, schalten, zum Beispiel ob ein P-Trace möglich ist und sehr viel Interessantes steht im Fedora-Wiki. So, es tut mir leid, dass ich so in Zeitprobleme komme, ich kann jetzt hier nur noch durchgaloppieren, also grundsätzlich beide Programme überwachen, nur das, wofür es Regeln gibt.
01:00:20
Programme ohne Regeln sind unconfined und laufen ohne Einschränkungen. Krypto-Torianer sind auch leider weiterhin möglich. Ich kann beide lokal anpassen, sie haben beide den Lernmodus. Apparmer erscheint mir wesentlich leichter verständlich und durchschaubar, aber es ist leider auch weniger weit verbreitet. SE Linux ist einfach schon durch seinen Umfang deutlich komplexer und Abschalten ist keine Lösung.
01:00:47
Literatur gibt es da noch, steht hier drin, wie gesagt, die Folie gibt es zum Download und da ich überzogen habe, muss ich die Fragen irgendwie ohne Folien beantworten. Tut mir leid, danke für euer Aufpassen und nochmal ganz ausdrückliches Danke für die Fragen und Ergänzungen.