Hallo Thomas, hallo zusammen, Am Freitag, 21. Oktober 2016, 16:23:53 CEST schrieb Thomas Michalka:
herzlichen Dank für Deinen _sehr richtigen_ Hinweis :-D Ich könnt' mich bloß in den A...sten beißen, weil ich mich dadurch wieder erinnere, dass ich deswegen schon mal den AppArmor kurzerhand zum Teufel geschickt habe (ich mag solche Nebenberechtigungs- oder besser Nebenbeschränkungssysteme nicht). Hätte ich bloß in meinem
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. Als AppArmor-Maintainer und einer der Entwickler bin ich in dieser Frage natürlich etwas befangen ;-)
Admin-Diary gesucht -- knirsch :-| Ist nämlich schon recht lange her; das war bei einer oS 12.3 oder 13.1, glaube ich. Heute habe ich oS 13.2.
;-)
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
Trotzdem gibt's so immer wieder was zu lernen, was das Gute daran ist, denn ich habe noch den Fehler mit /var/run/dovecot/mounts. Doch hier 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. Du kannst aber auch folgende Zeile in /etc/apparmor.d/ usr.lib.dovecot.imap eintragen: /{,var/}run/dovecot/mounts r, Genau passend zum Logeintrag wäre /var/run/dovecot/mounts r, aber obige Variante ist zukunfssicher und funktioniert für /var/run/... und /run/... In der aktuellen Upstream-Version der Dovecot-Profile ist diese Zeile übrigens schon enthalten - aber nur wegen dieser einen Zeile lohnt es sich nicht wirklich, ein Update anzustoßen. Außerdem braucht Dovecot diese Zeile nur in manchen Situationen - IIRC nur dann, wenn das Mailverzeichnis nicht existiert oder Zugriffsrechte fehlen.
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.
Kommentar darüber steht:
# @{DOVECOT_MAILSTORE} is a space-separated list of all directories # where dovecot is allowed to store and read mails
Muss ich das wörtlich nehmen, d.h. dass nur die Mailverzeichnisse dort eingetragen werden dürfen?
Du musst nicht, aber Du solltest ;-) Jedenfalls werden für alle angegebenen Verzeichnisse Schreib- und Leserechte für Dovecot vergeben. 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.
Wenn ja, wie müsste dann ein Eintrag aussehen, damit das lesen von "/var/run/dovecot/mounts" möglich wird? Oder kann/sollte man diesen Fehler getrost ignorieren?
Siehe oben - das gehört ins dovecot/imap-Profil.
Noch eines: als ich noch Systembenutzer als Mail-User zugelassen habe, war es AppArmor anscheinend egal, dass dovecot im Home-Verzeichnis des Benutzers die MailDir-Verzeichnisstruktur angelegt hat. 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.
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. _Alle_ Neuerungen seit der letzten Version ergeben eine *sehr* lange Datei, die vermutlich eh niemand lesen würde. 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 ;-)
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) Die Manpages findest Du auch irgendwo online, oder Du verwendest z. B. "man:apparmor.d" in Konqueror. 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. Gruß Christian Boltz -- A lot of us don't speak chinese - should we switch to this language to enable 1 billion people to read this list too? :) [Wolfgang Post in suse-laptop] -- 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