Hallo Christian, Am 21.10.2016 um 21:03 schrieb Christian Boltz:
Hallo Thomas, hallo zusammen,
Am Freitag, 21. Oktober 2016, 16:23:53 CEST schrieb Thomas Michalka:
[...]
Im Zweifelsfall verhindert AppArmor das Ausnutzen einer Sicherheitslücke (nicht nur theoretisch - es hat mich schon mehr als einmal vor Problemen bewahrt), daher lasse ich das sehr gern aktiv und habe auch ein paar zusätzliche (leider nicht massentaugliche) Profile im Einsatz.
Klar, wer um die Wirkung weiß, steht nicht wie der Ochs vorm Berg, wenn von dovecot/imap fehlende, aber nicht näher definierte Permissions benannt werden. Wäre vielleicht 'nen Hinweis an die Dovecot-Entwickler wert. Es heißt ja auch "Unix perms seem to be ok (ACL/MAC wrong?)". Sonst hätte ich mich gar nicht an die Liste gewandt, wenn ich an den Unix Permissions noch hätte drehen können. Oder AppArmor könnte sich gegenüber Dovecot offenbaren.
Als AppArmor-Maintainer und einer der Entwickler bin ich in dieser Frage natürlich etwas befangen ;-)
Ich kann darüber nicht klagen :-) "Tue Gutes und rede darüber" sollte man hin und wieder beherzigen.
Nebenfrage: Gibt's eigentlich eine zentrale Datei, wo eingetragen ist, was auf einem System per Distri-Default läuft bzw. aktiviert ist, und wo am besten auch automatisch eingetragen wird, wann man selber einen Dienst oder was auch immer aktiviert, neu konfiguriert u.s.w.. Wäre schon interessant, wenn man das von Distri-Version zu -Version vergleichen könnte, und freilich auch, um zu sehen, was man über die Jahre selber so 'verbrochen' hat. Das wäre sozusagen ein sehr, sehr langsamer Log, weil nur Admin-Aktionen aufgezeichnet würden. So könnte man auch gut nachvollziehen, wenn man etwas verbockt hat, besonders, wo Fehler erst viel später auftauchen.
Nicht direkt, aber es gibt ein paar Möglichkeiten: - rpm -Va listet alle veränderten Dateien (ggf. | grep /etc verwenden) - rpm -qf /eine/datei zeigt, zu welchem Paket eine Datei gehört bzw. dass sie nicht zu einem Paket gehört - etckeeper verwaltet /etc/ in git (habe ich nie getestet, wäre aber für einen kurzen Bericht dankbar, falls es jemand einsetzt) - verwende ein Konfigurationsmanagement-Tool wie Saltstack, Puppet o. ä. und benutze nie "su" oder "sudo". Bei einem einzelnen Rechner ist das natürlich ein gewisser Overhead, dafür bekommst Du aber eine saubere Doku Deiner Config und kannst bei Bedarf einen neuen Rechner automatisch genau so konfigurieren. Bei mehreren (großteils) identisch konfigurierten Rechnern sollte es sogar Zeit sparen, weil Du alles nur 1x und nicht auf jedem Rechner machen musst
Die ersten zwei kenne ich natürlich und Versionsverwaltung mit CVS und Subversion sind mir geläufig und habe ich auch mal eine Zeit lang für Configs gemacht. Dann macht mir mein Admin-Diary aber doch weniger Aufwand. Aber beide haben den Nachteil, dass man sie pflegen und darin nachsehen muss ;-) Die Versionsverwaltung ist mir für die wenigen Änderungen in Jahren einfach zu hoch. Meine Systeme verändern sich nur langsam/selten und wenn, dann in Schüben. Das schreibe ich dann lieber manuell auf. Ich muss auch gar nicht genau wissen, was ich in Configs und in welchen Schritten verändert habe (kann ich mit diffs zw. der Originalversion und dem aktuellen File rausbekommen), sondern ich hätte nur gerne einen Automatismus, der mir aufzeichnet, wann ich welche Dateien verändert und Dienste neu gestartet habe bzw. Configs neu eingelesen wurden. Könnte man mit einigem Aufwand sicher aus den Logs herausfiltern.
[...] zunächst mal ein paar Zeilen aus /var/log/audit/audit.log:
type=AVC msg=audit(1476894139.994:14385): apparmor="DENIED" operation="open" profile="/usr/lib/dovecot/imap" name="/var/run/dovecot/mounts" pid=14664 comm="imap" requested_mask="r" denied_mask="r" fsuid=10000 ouid=0
Du kannst mit aa-logprof die AppArmor-Profile interaktiv updaten.
Was ist mit "interaktiv" updaten gemeint?
Du kannst aber auch folgende Zeile in /etc/apparmor.d/ usr.lib.dovecot.imap eintragen: /{,var/}run/dovecot/mounts r,
[...]
Nochmal speziell zur Datei "/etc/apparmor.d/tunables/dovecot". Hier stand bei mir nur die eine Zeile für bzw. gegen Dovecot drin:
@{DOVECOT_MAILSTORE}=@{HOME}/Maildir/ @{HOME}/mail/ @{HOME}/Mail/ /var/vmail/ /var/mail/ /var/spool/mail/
Ans Ende habe ich "/srv/mail/vhosts" eingetragen, was gewirkt hat. Im
Genau, passt.
Die für Dich "unnötigen" Verzeichnisse darfst Du übrigens gern rauslöschen.
Ja, steht auch im Kommentar.
[...]
Dateien eintragen ist übrigens komplett sinnlos, weil im Profil @{DOVECOT_MAILSTORE}/ rw, @{DOVECOT_MAILSTORE}/** rwkl, steht.
Die erste Zeile erlaubt Schreiben und Lesen des Verzeichnisses (quasi mkdir und ls), und durch den angehängten / wird die Regel ausdrücklich auf "Verzeichnis" festgelegt.
Die zweite Zeile gibt vollen Zugriff auf alle Dateien und Unterverzeichnisse innerhalb des Verzeichnisses.
"rw" ist klar, aber "kl"?
[...] Wacht AppArmor nicht über Benutzerverzeichnisse? Wo ist festgelegt, worüber grundsätzlich gewacht wird?
Doch, AppArmor wacht über alles. Genaugenommen erlaubt es nur das, was ausdrücklich erlaubt ist, und verbietet alles andere.
Guck nochmal in die tunables/dovecot - dort steht u. a. @{HOME}/Maildir drin. @{HOME} ist in tunables/home definiert und enthält /home/*/ und /root/
Sprich: @{HOME}/Maildir wird zu /home/*/Maildir und /root/Maildir expandiert und der Zugriff auf /home/*/Maildir somit ganz offiziell erlaubt.
Ok, ich dachte zuerst, dass mit @{HOME} das Mailhome, bei mir gemeint sei, denn zufällig entspricht das Home-Verzeichnis der Systembenutzer genau den Mail-Homes für Dovecot. Aber AppArmor juckt der IMAP-Server ja nicht.
Gibt's irgendwo eine Stelle, wo man alle Neuerungen von Distri-Version zu Distri-Version gesammelt und möglichst schön gegliedert und in einer gewissen Tiefe (oder gerne mit Links auf entsprechende Doku) nachlesen kann, damit man besser auf dem Laufenden bleibt?
Die Release Notes und das Release-Announcement sind ein guter Überblick über die wichtigsten Änderungen.
Aber nur von Release zu Release innerhalb der Version, und das ist schon viel Stoff. Würde man alle bis zu einer neuen Version lesen, hätte man die ersten schon wieder vergessen.
_Alle_ Neuerungen seit der letzten Version ergeben eine *sehr* lange Datei, die vermutlich eh niemand lesen würde.
Eben, wenn man sich aber auf die größeren Änderungen beschränken würde, z.B. welche Dienste neu und standardmäßig eingeschaltet sind, dann wäre die Datei viel kürzer.
Zum Vergleich: Tumbleweed hat im Schnitt 4 Releases pro Woche, und die Changelog-Mail (für jedes dieser Releases, also für 2 Tage) ist meistens mehrere hundert Zeilen lang. Jetzt rechne Dir das auf ein jährliches Release hoch ;-)
Ja, klar, deswegen müsste man eher an der Oberfläche bleiben bzw. einen sinnvollen Kompromiss darüber finden, was man bringt und was nicht -- natürlich nur in einer extra Datei mit den großen Änderungen, nicht in den Release Notes, denn Kleinigkeiten können auch wichtig sein.
Vor langer, langer Zeit (noch SuSE) gab's mal einen Documentation Server im System, wo man im Browser auch Man Pages, die On-the-Fly nach HTML umgewandelt wurden, und viele andere Doku lesen konnte. Gibt's heute etwas entsprechendes?
http://doc.opensuse.org (zwar keine Manpages, aber eine ganze Menge Handbücher)
Naja, "einige" würde ich sagen.
Die Manpages findest Du auch irgendwo online, oder Du verwendest z. B. "man:apparmor.d" in Konqueror.
Ich komme schon klar mit man <Befehl> im Terminal, aber ein Doku-Crawler, von dem aus man zentral ein System oder sogar ein ganzes LAN, wenn man Doku-Server hat, nach Doku durchsuchen kann, wäre schon praktisch, auch zum Schmökern, wie in einer Buchhandlung. Da kommt man auf Schätzchen, die man sonst nicht finden würde.
Für den Einstieg in AppArmor empfehle ich gern meinen "AppArmor Crash Course". Die Slides gibt es auf blog.cboltz.de, ein Vortragsvideo von der letzten openSUSE Conference irgendwo ;-) auf conference.opensuse.org und bei YouTube.
Danke, schaue ich mir gerne an. Schöne Grüße Thomas Michalka -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org