Hallo, nachdem ich in 11.4 bezüglich AppArmor nun innerhalb kurzer Zeit zweimal ganz schrecklich auf die Nase gefallen bin (1x dovecot, 1x samba) und jede Menge Zeit vergeudet habe, wollte ich nun doch mal bei Euch nachfragen, ob ich da vielleicht generell was verkehrt mache. In beiden Fällen hat ein Ausknipsen von AppArmor die Situation bereinigt (es waren unterschiedliche Rechner), aber ich weiß ehrlich gesagt nicht, was das für mich in punkto Sicherheit bedeutet. Ist meine Kiste jetzt die Schießbude der Nation? Ist openSuSE ohne AppArmor, wie schickes Fahrrad ohne Schloss in der Großstadt - oder doch eher wie Auto mit elektronischer Wegfahrsperre aber ohne Alarmanlage? Aktuell bin ich, weil ich soviel Zeit verplempert habe, natürlich extrem genervt und deshalb emotional geneigt, mir in meinen Installationsnotizen zu vermerken : 1.) Installation mit DVD 2.) AppArmor abschalten 3.) Das System konfigurieren ... ... n.) Aus purer Lust das Treppenhaus mit der Zahnbürste putzen ... n+10^99.) Wenn irgendwann mal gaaaaanz viel Langeweile vorherrscht: Versuchen AppArmor in Betrieb zu nehmen. ... n+10^99+1.) Fertig! In der Zwischenzeit wurde übrigens u.a. der Weltfrieden verkündet. aber ist das die Lösung? Alternativ: Was muss ich denn jetzt schon wieder alles studieren um ein sicheres, aber administrierbares System zu bekommen? Ich finde es auch extrem schwer diesem Fehlerteufel auf die Spur zu kommen. In beiden o.a. Fällen bin ich erst nach langer Zeit und eher per Zufall darauf gekommen das AppArmor dahinter steckt. Wo gibt es denn da mal eine Fehlermeldung der Art: "Ich, AppArmor habe zugeschlagen!". Wäre nett von Euch, wenn Ihr mir schreibt was ich verkehrt mache und sorry für die unnötig lange Mail - ist so eine Art therapeutisches Schreiben für mich gewesen ... -- Herzliche Grüße Tao -- 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
On Thu, Oct 13, 2011 at 05:04:04AM +0200, Tao te Puh wrote:
nachdem ich in 11.4 bezüglich AppArmor nun innerhalb kurzer Zeit zweimal ganz schrecklich auf die Nase gefallen bin (1x dovecot, 1x samba) und jede Menge Zeit vergeudet habe, wollte ich nun doch mal bei Euch nachfragen, ob ich da vielleicht generell was verkehrt mache.
Das AppArmor-Profil für Samba war in der 11.4 fehlerhaft. Dafür ist mittlerweile eine Update verfügbar. http://en.opensuse.org/openSUSE:Most_annoying_bugs_11.4 Bug #666450 Samba server won't start. Possible workarounds: - run Update Profile Wizard (may be necessary two times: one time in order to get nmbd and smbd running and a second time in order to get access to the data) - quick and unrecommended workaround: disable AppArmor in YaST Wenn es auch nach dem Einspielen des Updates nicht funktioniert, dann öffne 666450 bitte wieder. Bei der Verwendung von Samba aus Tumbleweed ist besondere Vorsicht geboten, da sich für den nmbd das Verzeichnis des Sockets geändert hat. Aber auch hier hilft dann das oben beschriebene Vorgehen.
In beiden Fällen hat ein Ausknipsen von AppArmor die Situation bereinigt (es waren unterschiedliche Rechner), aber ich weiß ehrlich gesagt nicht, was das für mich in punkto Sicherheit bedeutet.
a) Stehen die Rechner direkt im Internet? Wenn ja, dann ist die Gefahr generell deutlich höher und ohne AA nochmals höher. b) Der oben beschrieben Ansatz (Update Profile Wizard) funktioniert auch für alle anderen Dienste. [ 8< ]
Alternativ: Was muss ich denn jetzt schon wieder alles studieren um ein sicheres, aber administrierbares System zu bekommen?
Ein Blick in die most annoying bugs der jeweiligen Version hilft oft.
Ich finde es auch extrem schwer diesem Fehlerteufel auf die Spur zu kommen. In beiden o.a. Fällen bin ich erst nach langer Zeit und eher per Zufall darauf gekommen das AppArmor dahinter steckt. Wo gibt es denn da mal eine Fehlermeldung der Art: "Ich, AppArmor habe zugeschlagen!".
In der Standardkonfiguration ist man meiner Erfahrung nach leider auf seine Intuition angewiesen. Gegebenenfalls bitte einen Featurerequest per openFATE öffnen. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Hallo Tao, hallo Leute, (bitte nimm mich beim Antworten ins CC - ich lese aus Zeitgründen hier nur sporadisch mit) Am Donnerstag, 13. Oktober 2011 schrieb Tao te Puh:
nachdem ich in 11.4 bezüglich AppArmor nun innerhalb kurzer Zeit zweimal ganz schrecklich auf die Nase gefallen bin (1x dovecot, 1x samba) und jede Menge Zeit vergeudet habe, wollte ich nun doch mal bei Euch nachfragen, ob ich da vielleicht generell was verkehrt mache.
In beiden Fällen hat ein Ausknipsen von AppArmor die Situation bereinigt (es waren unterschiedliche Rechner), aber ich weiß ehrlich gesagt nicht, was das für mich in punkto Sicherheit bedeutet.
Ist meine Kiste jetzt die Schießbude der Nation?
Nicht ganz, aber es fehlt Dir schon ein Stück Sicherheit. Ob Du dieses Stück Sicherheit brauchst bzw. gebraucht hättest, erfährst Du wie bei allen Sicherheitsmaßnahmen erst hinterher ;-)
Ist openSuSE ohne AppArmor, wie schickes Fahrrad ohne Schloss in der Großstadt - oder doch eher wie Auto mit elektronischer Wegfahrsperre aber ohne Alarmanlage?
Guter Vergleich - sogar dem Fahrrad ohne Schloss passiert nichts, solange kein Dieb kommt... Davon abgesehen würde ich Linux nicht mit einem Fahrrad vergleichen ;-)
Aktuell bin ich, weil ich soviel Zeit verplempert habe, natürlich extrem genervt und deshalb emotional geneigt, mir in meinen Installationsnotizen zu vermerken :
1.) Installation mit DVD 2.) AppArmor abschalten 3.) Das System konfigurieren ... ... n.) Aus purer Lust das Treppenhaus mit der Zahnbürste putzen
*lol*
Alternativ: Was muss ich denn jetzt schon wieder alles studieren um ein sicheres, aber administrierbares System zu bekommen?
Ich finde es auch extrem schwer diesem Fehlerteufel auf die Spur zu kommen. In beiden o.a. Fällen bin ich erst nach langer Zeit und eher per Zufall darauf gekommen das AppArmor dahinter steckt. Wo gibt es denn da mal eine Fehlermeldung der Art: "Ich, AppArmor habe zugeschlagen!".
/var/log/audit/audit.log schreibt das alles mit. So, und jetzt zum interessanten Teil - was kannst/solltest Du tun? Erstmal empfehle ich Dir die AppArmor-Pakete aus security:apparmor:factory [1] zu installieren - gegenüber der 11.4 gab es einige Verbesserungen und Ergänzungen in den AppArmor-Profilen. Mit etwas Glück sind damit Deine Dovecot-Probleme schon gelöst. Samba ist etwas problematischer, weil die Pfade für die Freigaben frei konfigurierbar sind. Aus Samba-Sicht ist das natürlich erforderlich, aber für AppArmor ist sowas nicht wirklich out-of-the-box handhabbar. Du brauchst für jede Freigabe folgende zwei Zeilen in /etc/apparmor.d/usr.sbin.smbd (falls Du die Pakete aus security:apparmor:factory verwendest, trage es besser in /etc/apparmor.d/local/usr.sbin.smbd ein): /pfad/zur/freigabe/ rk, /pfad/zur/freigabe/** rwkl, Ich arbeite gerade an einer Lösung, die diesen Schnipsel automatisch beim Starten von Samba aus der smb.conf ausliest und ins AppArmor-Profil einträgt - das Grundgerüst steht, die Integration in Samba und AppArmor dauert aber noch etwas. Wenn AppArmor jetzt immer noch etwas blockiert, würde mich interessieren, was genau. Dazu mach bitte folgendes (am Beispiel von Dovecot): - /var/log/audit/audit.log leeren oder umbenennen, danach "rcauditd restart" - die betroffenen Profile in den Lernmodus schalten: aa-complain /etc/apparmor.d/*dovecot* - Dovecot einen Tag lang verwenden, auch mal neu starten usw. - einen Bugreport aufmachen (Komponente "AppArmor) und /var/log/audit/audit.log anhängen - mit aa-logprof die Profile aktualisieren. Die Details dazu stehen im Security Guide unter [2] - die Profile wieder scharfschalten: aa-enforce /etc/apparmor.d/*dovecot* Das Ganze hört sich jetzt wahrscheinlich schlimmer an als es ist ;-) Gruß Christian Boltz [1] http://download.opensuse.org/repositories/security:/apparmor:/factory/openSU... [2] http://doc.opensuse.org/products/opensuse/openSUSE/opensuse- security/cha.apparmor.commandline.html#sec.apparmor.commandline.profiling.summary.logprof PS: Die Signatur ist zufällig (!) - aber so langsam beginne ich, an künstliche Intelligenz zu glauben ;-) --
Ideally, upstream projects would care for AppArmor profiles (as much as they would care for SELinux), Oh, upstream projects really care for SELinux? ;-) At least as much as they do for AppArmor ;-) [> Christian Boltz and Sascha Peilicke in opensuse-factory]
-- 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
Hi Christian, Am Donnerstag, 13. Oktober 2011, 13:12:22 schrieb Christian Boltz:
/pfad/zur/freigabe/ rk, /pfad/zur/freigabe/** rwkl,
Ich arbeite gerade an einer Lösung, die diesen Schnipsel automatisch beim Starten von Samba aus der smb.conf ausliest und ins AppArmor-Profil einträgt - das Grundgerüst steht, die Integration in Samba und AppArmor dauert aber noch etwas.
wenn man das dann auch noch nachstarten kann wenn Samba läuft wirds nahezu perfekt. Hint: Ich ändere gerne die smb.conf im laufenden Betrieb, was für samba ja auch problemlos funktioniert ... Gruss Falk -- 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
Hallo Falk, hallo Leute, Am Donnerstag, 13. Oktober 2011 schrieb Falk Sauer:
Am Donnerstag, 13. Oktober 2011, 13:12:22 schrieb Christian Boltz:
/pfad/zur/freigabe/ rk, /pfad/zur/freigabe/** rwkl,
Ich arbeite gerade an einer Lösung, die diesen Schnipsel automatisch beim Starten von Samba aus der smb.conf ausliest und ins AppArmor-Profil einträgt - das Grundgerüst steht, die Integration in Samba und AppArmor dauert aber noch etwas.
wenn man das dann auch noch nachstarten kann wenn Samba läuft wirds nahezu perfekt.
Es wird ein eigenständiges Script, das Du bei Bedarf auch per Hand aufrufen kannst ;-)
Hint: Ich ändere gerne die smb.conf im laufenden Betrieb, was für samba ja auch problemlos funktioniert ...
Mein Plan ist, es im Initscript zu verankern und bei start, restart und reload auszuführen (entsprechend auch bei systemd). Details siehe https://bugzilla.novell.com/show_bug.cgi?id=688040 - dort kannst Du auch den jeweils aktuellen Stand verfolgen. Gruß Christian Boltz --
[1] Schmerzen wg. einer Zerrung -- Nicht alles, was hinkt, ist ein Vergleich. In manchen Fällen ist es auch ein David Haller... *SCNR* [> David Haller und Mario van der Linde in suse-linux]
-- 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
Hallo Christian, zunächst mal vielen Dank für Deine Mail - die hat mich echt nach vorne gebracht! Am 13.10.2011 13:12, schrieb Christian Boltz:
[...]
Ist openSuSE ohne AppArmor, wie schickes Fahrrad ohne Schloss in der Großstadt - oder doch eher wie Auto mit elektronischer Wegfahrsperre aber ohne Alarmanlage?
Guter Vergleich - sogar dem Fahrrad ohne Schloss passiert nichts, solange kein Dieb kommt...
Davon abgesehen würde ich Linux nicht mit einem Fahrrad vergleichen ;-)
Du kennst mein Fahrrad nicht ...
Alternativ: Was muss ich denn jetzt schon wieder alles studieren um ein sicheres, aber administrierbares System zu bekommen?
Ich finde es auch extrem schwer diesem Fehlerteufel auf die Spur zu kommen. In beiden o.a. Fällen bin ich erst nach langer Zeit und eher per Zufall darauf gekommen das AppArmor dahinter steckt. Wo gibt es denn da mal eine Fehlermeldung der Art: "Ich, AppArmor habe zugeschlagen!".
/var/log/audit/audit.log schreibt das alles mit.
Danke! Die Datei war mir bisher völlig unbekannt. Nun muss ich nur noch die Sprache lernen die dort geschrieben steht ... In jedem Fall ist auffällig, dass vor dem Upgrade auf factory dort beim Zugriff auf den samba-Share Worte auftauchen wie "DENIED" und der Pfad zu meine Samba-Share ... BTW: Was muss ich denn mind. dazu lernen/lesen um den Inhalt der Datei "audit.log" einigermaßen zu verstehen?
So, und jetzt zum interessanten Teil - was kannst/solltest Du tun?
Erstmal empfehle ich Dir die AppArmor-Pakete aus security:apparmor:factory [1] zu installieren - gegenüber der 11.4 gab es einige Verbesserungen und Ergänzungen in den AppArmor-Profilen.
Das habe ich durchgeführt.
Mit etwas Glück sind damit Deine Dovecot-Probleme schon gelöst.
Die Dovecot-Maschine ist schon im produktiven Betrieb - da trau' ich mich das nicht so ohne weiteres - vielleicht mal am Wochenende ...
Samba ist etwas problematischer, weil die Pfade für die Freigaben frei konfigurierbar sind. Aus Samba-Sicht ist das natürlich erforderlich, aber für AppArmor ist sowas nicht wirklich out-of-the-box handhabbar. Du brauchst für jede Freigabe folgende zwei Zeilen in /etc/apparmor.d/usr.sbin.smbd (falls Du die Pakete aus security:apparmor:factory verwendest, trage es besser in /etc/apparmor.d/local/usr.sbin.smbd ein):
/pfad/zur/freigabe/ rk, /pfad/zur/freigabe/** rwkl,
Das habe ich ebenfalls durchgeführt und nun laufen Samba und AppArmor nebeneinander her und zunächst ohne weitere Auffälligkeiten. BTW: Was bedeuten die Kürzel "rk" und "rwkl" ?
Ich arbeite gerade an einer Lösung, die diesen Schnipsel automatisch beim Starten von Samba aus der smb.conf ausliest und ins AppArmor-Profil einträgt - das Grundgerüst steht, die Integration in Samba und AppArmor dauert aber noch etwas.
Ich liebe Schnipsel die Dinge automatisieren!
Wenn AppArmor jetzt immer noch etwas blockiert, würde mich interessieren, was genau. Dazu mach bitte folgendes (am Beispiel von Dovecot):
- /var/log/audit/audit.log leeren oder umbenennen, danach "rcauditd restart" - die betroffenen Profile in den Lernmodus schalten: aa-complain /etc/apparmor.d/*dovecot* - Dovecot einen Tag lang verwenden, auch mal neu starten usw. - einen Bugreport aufmachen (Komponente "AppArmor) und /var/log/audit/audit.log anhängen - mit aa-logprof die Profile aktualisieren. Die Details dazu stehen im Security Guide unter [2] - die Profile wieder scharfschalten: aa-enforce /etc/apparmor.d/*dovecot*
Okay, das werde ich versuchen wenn ich wieder Ärger habe. -- Herzliche Grüße Tao -- 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
Hallo Lars, Dank auch an Dich für Deine Hilfe. Am 13.10.2011 13:00, schrieb Lars Müller:
On Thu, Oct 13, 2011 at 05:04:04AM +0200, Tao te Puh wrote:
nachdem ich in 11.4 bezüglich AppArmor nun innerhalb kurzer Zeit zweimal ganz schrecklich auf die Nase gefallen bin (1x dovecot, 1x samba) und jede Menge Zeit vergeudet habe, wollte ich nun doch mal bei Euch nachfragen, ob ich da vielleicht generell was verkehrt mache.
Das AppArmor-Profil für Samba war in der 11.4 fehlerhaft. Dafür ist mittlerweile eine Update verfügbar.
Du meinst im normalen Update-Repo? Mein System war aktuell als der Fehler auftrat.
http://en.opensuse.org/openSUSE:Most_annoying_bugs_11.4
Bug #666450 Samba server won't start. Possible workarounds:
- run Update Profile Wizard (may be necessary two times: one time in order to get nmbd and smbd running and a second time in order to get access to the data)
- quick and unrecommended workaround: disable AppArmor in YaST
Die Seite hatte ich auch gefunden. Allerdings erst nachdem ich letztendlich AppArmor als Auslöser identifiziert und nach "samba <-> AppArmor" gesucht hatte.
Wenn es auch nach dem Einspielen des Updates nicht funktioniert, dann öffne 666450 bitte wieder.
Wenn ich nur wüsste welche Updates Du meinst - oder meinst Du das Update aus Factory welches Christian beschrieben hat? Normalerweise mache ich eine Bogen um Factory.
Bei der Verwendung von Samba aus Tumbleweed ist besondere Vorsicht geboten, da sich für den nmbd das Verzeichnis des Sockets geändert hat. Aber auch hier hilft dann das oben beschriebene Vorgehen.
Ursprünglich war der Rechner auf dem ich Samba installieren wollte ein Tumbleweed. Aufgrund der Probleme habe ich dann aber doch ein reines 11.4 installiert und war erstaunt, dass ich die gleichen Probleme hatte ...
In beiden Fällen hat ein Ausknipsen von AppArmor die Situation bereinigt (es waren unterschiedliche Rechner), aber ich weiß ehrlich gesagt nicht, was das für mich in punkto Sicherheit bedeutet.
a) Stehen die Rechner direkt im Internet? Wenn ja, dann ist die Gefahr generell deutlich höher und ohne AA nochmals höher.
Was meinst Du mit direkt? Der eine Rechner hängt schon am Internet, allerdings hinter einer Firewall, so dass die Dienste von extern nicht direkt zugänglich sind.
b) Der oben beschrieben Ansatz (Update Profile Wizard) funktioniert auch für alle anderen Dienste.
Den Profile Wizard hatte ich durchgespielt, das hat aber keine Besserung gebracht. Leider kannte ich zu diesem Zeitpunkt die Datei audit.log noch nicht und kann deshalb auch nicht mehr nachvollziehen, was nach dem Wizard noch angenörgelt wurde.
[ 8< ]
Alternativ: Was muss ich denn jetzt schon wieder alles studieren um ein sicheres, aber administrierbares System zu bekommen?
Ein Blick in die most annoying bugs der jeweiligen Version hilft oft.
Das werde ich mir merken/notieren.
Ich finde es auch extrem schwer diesem Fehlerteufel auf die Spur zu kommen. In beiden o.a. Fällen bin ich erst nach langer Zeit und eher per Zufall darauf gekommen das AppArmor dahinter steckt. Wo gibt es denn da mal eine Fehlermeldung der Art: "Ich, AppArmor habe zugeschlagen!".
In der Standardkonfiguration ist man meiner Erfahrung nach leider auf seine Intuition angewiesen.
Gegebenenfalls bitte einen Featurerequest per openFATE öffnen.
Ich erinnere mich noch an die Zeit als die SuSEfirewall Einzug fand. Da gab es ähnliche Situationen bei denen man erst einmal nicht darauf kam warum etwas nicht lief. Mittlerweile hat die Firewall ja sogar ein eigenes Logfile und der Blick dort hinein, ist zur Routine geworden ... zukünftig werde ich halt auch ein Auge auf das audit.log haben ... -- Herzliche Grüße Tao -- 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
Hallo Tao, hallo Leute, Am Freitag, 14. Oktober 2011 schrieb Tao te Puh:
Am 13.10.2011 13:12, schrieb Christian Boltz:
[...]
Ist openSuSE ohne AppArmor, wie schickes Fahrrad ohne Schloss in der Großstadt - oder doch eher wie Auto mit elektronischer Wegfahrsperre aber ohne Alarmanlage?
Guter Vergleich - sogar dem Fahrrad ohne Schloss passiert nichts, solange kein Dieb kommt...
Davon abgesehen würde ich Linux nicht mit einem Fahrrad vergleichen ;-)
Du kennst mein Fahrrad nicht ...
;-)
Wo gibt es denn da mal eine Fehlermeldung der Art: "Ich, AppArmor habe zugeschlagen!".
/var/log/audit/audit.log schreibt das alles mit.
Danke! Die Datei war mir bisher völlig unbekannt. Nun muss ich nur noch die Sprache lernen die dort geschrieben steht ... In jedem Fall ist auffällig, dass vor dem Upgrade auf factory dort beim Zugriff auf den samba-Share Worte auftauchen wie "DENIED" und der Pfad zu meine Samba-Share ...
BTW: Was muss ich denn mind. dazu lernen/lesen um den Inhalt der Datei "audit.log" einigermaßen zu verstehen?
Die einfachste Lösung ist, mit "aa-notify -s 1 -v" eine Übersicht anzeigen zu lassen. Wenn Du wirklich das audit.log selbst lesen willst (geht durchaus, ich mache das auch), hier die Kurzfassung an einem kokreten Beispiel. type=AVC msg=audit(1318588756.630:39): apparmor="DENIED" operation="mkdir" parent=1 profile="/usr/sbin/avahi-daemon" name="/home/sys-var/run/avahi-daemon/" pid=2024 comm="avahi-daemon" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 Das wichtigste und kryptischste vorweg: 1318588756.630 ist der Zeitpunkt des Logeintrags. Um den lesbar zu bekommen: # date -d @1318588756.630 Fr 14. Okt 12:39:16 CEST 2011 DENIED heißt, dass das Profil "scharfgeschaltet" ist. Alternativ gibt es ALLOWED bei Profilen im Lernmodus und AUDIT, wenn eine Regel mit "audit" markiert ist. operation= beschreibt, was das Programm machen wollte. profile= ist das verwendete Profil name= die Datei oder das Verzeichnis, für das Rechte fehlen requested_mask und denied_mask zeigen die angeforderten bzw. abgelehnten Rechte - hier "c" für create (wird im Profil zu _w_rite) Die anderen Dinge sind weniger wichtig und/oder selbsterklärend.
So, und jetzt zum interessanten Teil - was kannst/solltest Du tun?
Erstmal empfehle ich Dir die AppArmor-Pakete aus security:apparmor:factory [1] zu installieren - gegenüber der 11.4 gab es einige Verbesserungen und Ergänzungen in den AppArmor-Profilen. Das habe ich durchgeführt.
Mit etwas Glück sind damit Deine Dovecot-Probleme schon gelöst.
Die Dovecot-Maschine ist schon im produktiven Betrieb - da trau' ich mich das nicht so ohne weiteres - vielleicht mal am Wochenende ...
Die Pakete aus security:apparmor:factory laufen auch auf der 11.4 - ich habe das getestet, bevor ich mein System auf Factory aktualisiert habe. Wenn Du ganz sicher gehen willst, aktualisiere nur das Paket apparmor- profiles (aktuelle Profile, dürften nichts kaputtmachen). Allerdings verpasst Du dann einige andere Fixes und einen deutlichen Performancegewinn beim Booten - mit den Factory-Paketen startet AppArmor 20x so schnell (0,3 bis 0,4 Sekunden gegenüber 7,5 Sekunden auf meinem Laptop).
Samba ist etwas problematischer, weil die Pfade für die Freigaben frei konfigurierbar sind. Aus Samba-Sicht ist das natürlich erforderlich, aber für AppArmor ist sowas nicht wirklich out-of-the-box handhabbar. Du brauchst für jede Freigabe folgende zwei Zeilen in /etc/apparmor.d/usr.sbin.smbd (falls Du die Pakete aus security:apparmor:factory verwendest, trage es besser in
/etc/apparmor.d/local/usr.sbin.smbd ein): /pfad/zur/freigabe/ rk, /pfad/zur/freigabe/** rwkl,
Das habe ich ebenfalls durchgeführt und nun laufen Samba und AppArmor nebeneinander her und zunächst ohne weitere Auffälligkeiten.
BTW: Was bedeuten die Kürzel "rk" und "rwkl" ?
Das sind die Berechtigungen - r und w stehen für read and write, k für lock und l für link (Link erstellen). Falls Du Videotraining magst ;-) kannst Du Dir mal meinen Vortrag vom LinuxTag 2009 ansehen. Zu finden ist der auf http://en.opensuse.org/openSUSE:LinuxTag_09 (Video + Slides) Im Wesentlichen ist er noch aktuell - es fehlen nur ein paar neue Funktionen/Regeln, die aber eher selten gebraucht werden. Außerdem wurde "set capabilities" aus AppArmor entfernt. Gruß Christian Boltz -- Jaaaa! Und am besten den Rest des Desktops auch noch mit DHTML nachprogrammieren, ach was sag ich, JavaScript ist ja /die/ Sprache, um das ganze Betriebsystem neu zu entwickeln. [Ratti in fontlinge-devel] -- 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
On Fri, Oct 14, 2011 at 08:47:50AM +0200, Tao te Puh wrote:
Am 13.10.2011 13:00, schrieb Lars Müller:
On Thu, Oct 13, 2011 at 05:04:04AM +0200, Tao te Puh wrote:
nachdem ich in 11.4 bezüglich AppArmor nun innerhalb kurzer Zeit zweimal ganz schrecklich auf die Nase gefallen bin (1x dovecot, 1x samba) und jede Menge Zeit vergeudet habe, wollte ich nun doch mal bei Euch nachfragen, ob ich da vielleicht generell was verkehrt mache.
Das AppArmor-Profil für Samba war in der 11.4 fehlerhaft. Dafür ist mittlerweile eine Update verfügbar.
Du meinst im normalen Update-Repo?
http://download.opensuse.org/pub/opensuse/update/11.4/
Mein System war aktuell als der Fehler auftrat.
http://en.opensuse.org/openSUSE:Most_annoying_bugs_11.4
Bug #666450 Samba server won't start. Possible workarounds:
- run Update Profile Wizard (may be necessary two times: one time in order to get nmbd and smbd running and a second time in order to get access to the data)
- quick and unrecommended workaround: disable AppArmor in YaST
Die Seite hatte ich auch gefunden. Allerdings erst nachdem ich letztendlich AppArmor als Auslöser identifiziert und nach "samba <-> AppArmor" gesucht hatte.
Ja, das übliche Henne-Ei-Problem. :(
Wenn es auch nach dem Einspielen des Updates nicht funktioniert, dann öffne 666450 bitte wieder.
Wenn ich nur wüsste welche Updates Du meinst - oder meinst Du das Update aus Factory welches Christian beschrieben hat? Normalerweise mache ich eine Bogen um Factory.
Konkret meinte ich ein Update für AppArmor, dass den Fehler im Samba-Profil behebt.
Bei der Verwendung von Samba aus Tumbleweed ist besondere Vorsicht geboten, da sich für den nmbd das Verzeichnis des Sockets geändert hat. Aber auch hier hilft dann das oben beschriebene Vorgehen.
Ursprünglich war der Rechner auf dem ich Samba installieren wollte ein Tumbleweed. Aufgrund der Probleme habe ich dann aber doch ein reines 11.4 installiert und war erstaunt, dass ich die gleichen Probleme hatte ...
In beiden Fällen hat ein Ausknipsen von AppArmor die Situation bereinigt (es waren unterschiedliche Rechner), aber ich weiß ehrlich gesagt nicht, was das für mich in punkto Sicherheit bedeutet.
a) Stehen die Rechner direkt im Internet? Wenn ja, dann ist die Gefahr generell deutlich höher und ohne AA nochmals höher.
Was meinst Du mit direkt? Der eine Rechner hängt schon am Internet, allerdings hinter einer Firewall, so dass die Dienste von extern nicht direkt zugänglich sind.
Direkt heißt mit Hose runter. Ohne Firewall oder sonstige Filter. Eben IP für richtige Frauen und Männer. ;) [ 8< ]
Ich erinnere mich noch an die Zeit als die SuSEfirewall Einzug fand. Da gab es ähnliche Situationen bei denen man erst einmal nicht darauf kam warum etwas nicht lief. Mittlerweile hat die Firewall ja sogar ein eigenes Logfile und der Blick dort hinein, ist zur Routine geworden ... zukünftig werde ich halt auch ein Auge auf das audit.log haben ...
/var/log/audit/ zwar nicht gerade intuitiv, wenn das Werkzeug AppArmor heißt, aber so ist das Leben. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Hallo Christian, Am 14.10.2011 13:53, schrieb Christian Boltz:
Am Freitag, 14. Oktober 2011 schrieb Tao te Puh:
Am 13.10.2011 13:12, schrieb Christian Boltz:
Wo gibt es denn da mal eine Fehlermeldung der Art: "Ich, AppArmor habe zugeschlagen!".
/var/log/audit/audit.log schreibt das alles mit.
Danke! Die Datei war mir bisher völlig unbekannt. Nun muss ich nur noch die Sprache lernen die dort geschrieben steht ... In jedem Fall ist auffällig, dass vor dem Upgrade auf factory dort beim Zugriff auf den samba-Share Worte auftauchen wie "DENIED" und der Pfad zu meine Samba-Share ...
BTW: Was muss ich denn mind. dazu lernen/lesen um den Inhalt der Datei "audit.log" einigermaßen zu verstehen?
Die einfachste Lösung ist, mit "aa-notify -s 1 -v" eine Übersicht anzeigen zu lassen.
aa-notify: ERROR: 'root' must be in 'admin' group. Aborting
[...] Falls Du Videotraining magst ;-) kannst Du Dir mal meinen Vortrag vom LinuxTag 2009 ansehen. Zu finden ist der auf http://en.opensuse.org/openSUSE:LinuxTag_09 (Video + Slides) Im Wesentlichen ist er noch aktuell - es fehlen nur ein paar neue Funktionen/Regeln, die aber eher selten gebraucht werden. Außerdem wurde "set capabilities" aus AppArmor entfernt.
Das Video habe ich leider nicht gefunden - und wie immer ist es schwer, die Folien ohne Kommentar im Detail zu verstehen. Und wo wir gerade beim Thema Fortbildung sind: Kannst Du mir eine weitere Lernmittel-Empfehlung für den Einstieg in AppArmor geben? Mich interessiert dabei eher die Anwenderseite, also was in den Folien angedeutet ist: Profile erfassen/erstellen, Pflege/Erweiterung sowie Fehlerdiagnose/-Behebung. Aber einiges habe ich dazugelernt und es hat sich auch gleich mind. eine neue Frage aufgetan: Durch die Folien habe ich nun das Kommando "aa-unconfined" kennengelernt. Wenn ich das Kommando richtig verstanden habe, zeigt es mir die laufenden Prozesse und wie/ob diese geschützt sind. Nun sehe ich bei mir, dass sshd "nicht eingeschränkt" ist. Warum eigentlich nicht? Ich frage, weil ssh praktisch auf allen meinen Rechnern von außen erreichbar ist und ich bisher, unwissend, davon ausgegangen bin, dass diesem Dienst in openSuSE besondere Aufmerksamkeit geschenkt wird und somit selbstverständlich auch AppArmor seine schützende Hand über diesen Prozess hält ... Was mich allerdings wundert ist, dass es ja offensichtliche eine Profil-Datei für ssh gibt (/etc/apparmor/profiles/extras/usr.sbin.sshd). Ist die nicht scharf geschaltet? Muss ich die scharf schalten? Muss ich eventuell noch andere Profile scharf schalten? Wenn ja, wie geht man da strategisch vor und vor allem, wie macht man das? -- Herzliche Grüße Tao -- 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
Hallo Lars, Am 14.10.2011 16:30, schrieb Lars Müller:
On Fri, Oct 14, 2011 at 08:47:50AM +0200, Tao te Puh wrote:
Am 13.10.2011 13:00, schrieb Lars Müller:
On Thu, Oct 13, 2011 at 05:04:04AM +0200, Tao te Puh wrote:
nachdem ich in 11.4 bezüglich AppArmor nun innerhalb kurzer Zeit zweimal ganz schrecklich auf die Nase gefallen bin (1x dovecot, 1x samba) und jede Menge Zeit vergeudet habe, wollte ich nun doch mal bei Euch nachfragen, ob ich da vielleicht generell was verkehrt mache.
Das AppArmor-Profil für Samba war in der 11.4 fehlerhaft. Dafür ist mittlerweile eine Update verfügbar.
Du meinst im normalen Update-Repo?
Nö, das kann nicht sein. Dieses Repo habe ich eingebunden und trotzdem den Fehler gehabt. Oder sind das unterschiedliche Repos - bei mir ist nämlich, genau genommen, folgendes eingebunden: http://download.opensuse.org/update/11.4/ also ohne /pub/opensuse/ ...
Wenn es auch nach dem Einspielen des Updates nicht funktioniert, dann öffne 666450 bitte wieder.
Wenn ich nur wüsste welche Updates Du meinst - oder meinst Du das Update aus Factory welches Christian beschrieben hat? Normalerweise mache ich eine Bogen um Factory.
Konkret meinte ich ein Update für AppArmor, dass den Fehler im Samba-Profil behebt.
s.o.
In beiden Fällen hat ein Ausknipsen von AppArmor die Situation bereinigt (es waren unterschiedliche Rechner), aber ich weiß ehrlich gesagt nicht, was das für mich in punkto Sicherheit bedeutet.
a) Stehen die Rechner direkt im Internet? Wenn ja, dann ist die Gefahr generell deutlich höher und ohne AA nochmals höher.
Was meinst Du mit direkt? Der eine Rechner hängt schon am Internet, allerdings hinter einer Firewall, so dass die Dienste von extern nicht direkt zugänglich sind.
Direkt heißt mit Hose runter. Ohne Firewall oder sonstige Filter. Eben IP für richtige Frauen und Männer. ;)
Verstehe, mit aufgeknöpftem Hemd auf der Harley durch Sibirien ... ich habe dann doch eher die Schisser-Variante "Strickpulli in der Sauna". Bis auf ssh, ist bei mir von extern eigentlich nichts weiter erreichbar.
[ 8< ]
Ich erinnere mich noch an die Zeit als die SuSEfirewall Einzug fand. Da gab es ähnliche Situationen bei denen man erst einmal nicht darauf kam warum etwas nicht lief. Mittlerweile hat die Firewall ja sogar ein eigenes Logfile und der Blick dort hinein, ist zur Routine geworden ... zukünftig werde ich halt auch ein Auge auf das audit.log haben ...
/var/log/audit/ zwar nicht gerade intuitiv, wenn das Werkzeug AppArmor heißt, aber so ist das Leben.
Ja, das finde ich auch. Und so hatte ich, nachdem ich in messages keine relevanten AppArmor fand, in /var/log/ nach einer Datei gesucht, die zumindest eine kleine Namensähnlichkeit zu AppArmor aufweist ... Allerdings scheint sich da was in der Factory-Version getan zu haben. Jetzt habe ich sehr viele Einträge in messages bezüglich AppArmor. -- Herzliche Grüße Tao -- 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
Hallo Tao, hallo Leute, Am Samstag, 15. Oktober 2011 schrieb Tao te Puh:
Am 14.10.2011 13:53, schrieb Christian Boltz:
Am Freitag, 14. Oktober 2011 schrieb Tao te Puh:
Am 13.10.2011 13:12, schrieb Christian Boltz:
Die einfachste Lösung ist, mit "aa-notify -s 1 -v" eine Übersicht anzeigen zu lassen.
aa-notify: ERROR: 'root' must be in 'admin' group. Aborting
Stimmt, dieses Detail hatte ich vergessen. Der Gruppenname steht in /etc/apparmor/notify.conf - dort kannst Du eine Gruppe eintragen, in der Dein User Mitglied ist. Prinzipiell funktioniert "users" - falls aber mehrere User auf Deinem System arbeiten und nicht Zugriff auf jeder die AppArmor-Meldungen bekommen soll, könnte die Gruppe "trusted" eine bessere Wahl sein. Das erinnert mich gerade daran, dass ich einen Patch mit einer etwas ausführlicheren Fehlermeldung basteln sollte ;-)
[...]
Falls Du Videotraining magst ;-) kannst Du Dir mal meinen Vortrag vom LinuxTag 2009 ansehen. Zu finden ist der auf http://en.opensuse.org/openSUSE:LinuxTag_09 (Video + Slides) Im Wesentlichen ist er noch aktuell - es fehlen nur ein paar neue Funktionen/Regeln, die aber eher selten gebraucht werden. Außerdem wurde "set capabilities" aus AppArmor entfernt.
Das Video habe ich leider nicht gefunden - und wie immer ist es schwer, die Folien ohne Kommentar im Detail zu verstehen.
Guck mal in der rechten Spalte - direkt unter dem Link zum PDF ist ein Icon, das zum Video verlinkt.
Und wo wir gerade beim Thema Fortbildung sind: Kannst Du mir eine weitere Lernmittel-Empfehlung für den Einstieg in AppArmor geben? Mich interessiert dabei eher die Anwenderseite, also was in den Folien angedeutet ist: Profile erfassen/erstellen, Pflege/Erweiterung sowie Fehlerdiagnose/-Behebung.
Der openSUSE security guide dürfte ganz hilfreich sein: http://doc.opensuse.org/products/opensuse/openSUSE/opensuse- security/part.apparmor.html Leider ist der etwas veraltet - bitte alles zum Thema "Reporting" und aa-eventd ignorieren (Bugreport ist eingereicht). Auch die offizielle AppArmor-Doku kannst Du Dir mal ansehen: http://wiki.apparmor.net/index.php/Documentation
Aber einiges habe ich dazugelernt und es hat sich auch gleich mind. eine neue Frage aufgetan:
Durch die Folien habe ich nun das Kommando "aa-unconfined" kennengelernt.
Wenn ich das Kommando richtig verstanden habe, zeigt es mir die laufenden Prozesse und wie/ob diese geschützt sind. Nun sehe ich bei
Genau.
mir, dass sshd "nicht eingeschränkt" ist. Warum eigentlich nicht? Ich
Gute Frage - ich kann Dir leider keine Antwort anbieten.
frage, weil ssh praktisch auf allen meinen Rechnern von außen erreichbar ist und ich bisher, unwissend, davon ausgegangen bin, dass diesem Dienst in openSuSE besondere Aufmerksamkeit geschenkt wird und somit selbstverständlich auch AppArmor seine schützende Hand über diesen Prozess hält ...
Was mich allerdings wundert ist, dass es ja offensichtliche eine Profil-Datei für ssh gibt (/etc/apparmor/profiles/extras/usr.sbin.sshd). Ist die nicht scharf geschaltet? Muss ich die scharf schalten? Muss ich eventuell noch andere Profile scharf schalten? Wenn ja, wie geht man da strategisch vor und vor allem, wie macht man das?
Die Profile in /etc/apparmor/profiles/extras/ sind nicht aktiv. Das kann daran liegen, dass sie unvollständig oder zu sehr einschränkend sind (wie z. B. das Firefox-Profil, das Schreibzugriffe nur in ~/Downloads erlaubt). Oder es hat sie einfach noch niemand zu den standardmäßig aktiven Profilen verschoben ;-) Aktive Profile liegen in /etc/apparmor.d/ Für sshd heißt das: das Profil nach /etc/apparmor.d/ kopieren und AppArmor und den sshd neu starten. Gruß Christian Boltz -- Bei mir setzte Yast eben $LANG auf de_DE@euro. Solange ich LANG nicht umstelle, ist es dessen schuld und ich habe mich aus der Verantwortung gezogen, falls da irgendwann mal Persisch erscheint. ;-) [Ferdinand Ihringer in suse-linux] -- 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
participants (4)
-
Christian Boltz -
Falk Sauer -
Lars Müller -
Tao te Puh