Am 2020-08-03 20:36, schrieb Christian Boltz:
Hallo Mathias, hallo zusammen,
Am Montag, 3. August 2020, 09:28:57 CEST schrieb Mathias Homann:
Ich kapier's nicht...
Ich hab das jetzt erst mal so versucht wie es im header von /etc/apparmor.d/usr.lib.apache2.mpm-prefork.apache2 beschrieben ist..
Ich fürchte, da bist Du einem falschen Profil aufgesessen - der Pfad in diesem Profil passt nicht zum openSUSE-Apache, daher wird es auch nicht verwendet :-(
Bugreport existiert, ich werde es wohl ab dem nächsten AppArmor Major- Release nicht mehr standardmäßig mitinstallieren, um diese Verwirrung zu vermeiden.
Da gibt's übrigens noch ein zweites apache profil, das ist auch standardmässig installiert, passt auch nicht zum apache2 wie wir ihn haben...
Nimm lieber das Profil, das ich auf paste.opensuse.org gepackt habe. Das verwende ich in ähnlicher Form unter openSUSE im Produktiveinsatz, ich habe es nur etwas anonymisiert. Nach Anlegen der Datei in /etc/apparmor.d/ bitte "rcapparmor reload" nicht vergessen ;-) und danach Apache (einmalig) neu starten.
ich werd's mal ausprobieren... kann ich mit AppArmor überhaupt verhindern dass über einen Bug in Wordpress dateien hochgeladen werden die zwar nicht das system infizieren aber dann per link aufgerufen weden um den Rechner der auf wordpress zugreift zu infizieren? Nach meinem Verständnis würde das nicht gehen, weil dann generell Uploads in WP nicht mehr gehen würden, oder? Sollte ich für so was lieber amavis/clamd in WP einbinden, wenn das irgendwie geht? Situation ist folgende: Wordpress Blog, immer aktuelle version Immer wieder finden sich unterhalb wp-upload dateien die da nicht hingehören, so z.b. dateien mit der ending .ico die aber inhatlich aus "obfuscated" php bestehen. Password leak kann's "eigentlich" nicht gewesen sein, weil 1. nur ich accounts auf dem Blog hab, 2. ich email bekomm wenn sich einer anmeldet, und 3. ich auf allen logins 2FA aktiv habe... Wenn ich jetzt dem Apache per AppArmor oder konfig das schreiben verbieten würde, würden ja Uploads ins Wordpress nicht mehr gehn - und meine Nextcloud die auch noch da in einem VHost läuft wäre auch tot... Vorschläge bitte...
aa-status sagt alle apache-relevanten profile stehen auf enforcing,
Ich vermute mal, dass Du da nur das "falsche" (siehe oben) Profil siehst, aber nicht das richtige (httpd2-prefork).
und dennoch sagt mir ein ausearch -m avc -i -ts recent:
"type=AVC msg=audit(03.08.2020 09:24:07.541:17166) : apparmor=DENIED operation=change_hat info=unconfined can not change_hat error=-1 profile=unconfined pid=9006 comm=httpd-prefork"
Und das heisst nach meinem verständnis dass der httpd als unconfined läuft...
Richtig.
In diesem Zusammenhang: auf Leap 15.2 wird selinux ohne policies paketiert - das hilft auch nicht wirklich weiter.
Das ist leider nicht mein Fachgebiet ;-) Ich weiß, dass jemand im SUSE Security Team auch etwas an selinux arbeitet, aber wohl nicht besonders intensiv, weil der Fokus eher auf AppArmor liegt.
Ich weiss ja nicht - bisher kommen bei mir im Zusammenhang mit AppArmor deutliche "Linux from scratch"-Gefühle auf, "alles muss ich selber machen". Zumindest für die Dienste die "man" immer so braucht sollten doch eigentlich brauchbare profile schon dabei sein und auch aktiv sein. [...]
Theoretisch kann man mit AppArmor auch Full System Confinement machen. Ich habe es nie selbst ausprobiert, aber ich stelle es mir ähnlich schmerzhaft vor wie das, was ich gerüchteweise über selinux gehört habe ;-)
Die Gerüchte hab ich auch mal gehört - und 5 Jahre lang mein Brot damit verdient diese Gerüchte auszumerzen. Das war früher mal so (Red Hat vor Version 6.x). Lang ist's her. Wenn man sich selinux auf RHEL heute ansieht fragt man sich eher "warum machen wir was anderes"... Andererseits: das selinux so wie es auf obs in security:SELinux liegt ist auch nicht besser als das was in Leap 15.2 daherkommt... Wieso bitte läuft der apache unter der SELinux version als prozesstyp kernel_t ????? ein apache läuft normalerweise als system_u:system_r:httpd_t, dementsprechend ist das dateisystem gelabelt, und dann "geht es einfach" und ist trotzdem hübsch eingesperrt...
Gruß
Christian Boltz
Ditto. -- Mathias Homann Mathias.Homann@openSUSE.org telegram: https://telegram.me/lemmy98 irc: [lemmy] on freenode and ircnet obs: lemmy04 gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102