Gründe, SELinux zu deaktivieren / aktivieren

Angesichts dieser Frage zu StackOverflow und der völlig anderen Masse, die wir hier haben, frage ich mich: Was sind Ihre Gründe, SELinux zu deaktivieren (vorausgesetzt, die meisten Leute tun es noch)? Möchten Sie es aktiviert lassen? Welche Anomalien haben Sie erfahren, als Sie SELinux eingeschaltet haben? Welche anderen Anbieter außer Oracle bieten Probleme bei der Unterstützung von Systemen mit aktiviertem SELinux?

Bonusfrage: Hat es jemand geschafft, Oracle mit SELinux auf RHEL5 zum Laufen zu bringen, indem er den Zielmodus erzwingt? Ich meine, streng wäre großartig, aber ich weiß noch nicht, dass dies auch nur aus der Ferne möglich ist. Bleiben wir also zuerst bei Targeted.

RedHat schaltet SELinux standardmäßig ein, weil es sicherer ist. Nahezu jeder Anbieter, der von Redhat abgeleitete Produkte verwendet, schaltet SELinux aus, weil er nicht die Zeit (und damit das Geld) investieren möchte, um herauszufinden, warum das Ding nicht funktioniert. Die Redhat / Fedora-Mitarbeiter haben enorm viel Zeit und Mühe investiert, um SELinux zu einer realisierbaren Option im Unternehmen zu machen, aber nicht viele andere Organisationen kümmern sich wirklich um Ihre Sicherheit. (Sie kümmern sich um ihre Sicherheit und den Sicherheitsruf ihres Produkts, was eine ganz andere Sache ist.)

Wenn du es schaffen kannst, dann mach es. Wenn Sie nicht können, dann erwarten Sie nicht viel Unterstützung von den Anbietern da draußen. Hilfe bekommen Sie wahrscheinlich von den RedHat / Fedora-Leuten, von den Selinux-Mailinglisten und dem # Selinux-Kanal auf freenode. Aber von Unternehmen wie Oracle - nun, SELinux berücksichtigt ihren Geschäftsplan nicht wirklich.

Normalerweise ist es besser, SELinux in Permissive auszuführen, als es vollständig zu deaktivieren. Sie können dann audit2whynach einer Weile überprüfen , welche Arten von Verstößen während Ihrer regulären Verwendung abgelehnt wurden, und benutzerdefinierte Richtlinien erstellen, indem Sie festlegen, audit2allowob diese Verstöße für Ihr Setup falsch positiv sind.

Ich habe festgestellt, dass das SELinux-Verhalten auf nicht von Fedora abgeleiteten Systemen wesentlich empfindlicher ist als das, was Sie mit einem typischen Fedora / RHEL-System standardmäßig erhalten.

Wenn Sie es noch nicht gesehen haben, finden Sie das Fedora SELinux-Benutzerhandbuch möglicherweise lehrreich.

Gründe für:

• Höhere Sicherheit durch verpflichtende Zugangskontrolle
• Sie benötigen einen Grund, der über das Sicherheitsniveau hinausgeht? :-)

Gründe gegen:

• Schwierig zu verstehen
• Schwer zu handhaben
• Schwierig zu beheben

Das heißt, wenn Sie über SELinux nachdenken, empfehle ich das Buch SELinux by Example .

Ich habe für eine Firma gearbeitet , die SELinux auf jedem System im Durchsetzungsmodus aktiviert hatte. Der Schlüssel für uns war das Verstehen und Verwenden des Programms audit2allow, mit dem neue Kontextregeln erstellt werden können.

Zuerst generieren wir eine Vorlage mit audit2allow und erstellen sie dann mithilfe eines Skripts wie folgt:

export NAME="my_serviced"
sudo audit2allow -m "${NAME}" -i /var/log/audit/audit.log > ${NAME}.te
sudo setup_semodule ${NAME}

Das Skript setup_semodule:

#!/bin/sh

# Where to store selinux related files
SOURCE=/etc/selinux/local
BUILD=/etc/selinux/local
NAME=$1

/usr/bin/checkmodule -M -m -o ${BUILD}/${NAME}.mod ${SOURCE}/${NAME}.te
/usr/bin/semodule_package -o ${BUILD}/${NAME}.pp -m ${BUILD}/${NAME}.mod
/usr/sbin/semodule -i ${BUILD}/${NAME}.pp

/bin/rm ${BUILD}/${NAME}.mod ${BUILD}/${NAME}.pp

Dies erstellt das Modul aus der Vorlage (.te-Datei), generiert ein Paket und lädt dann das Modul.

Wir haben Puppet für unser Konfigurationsmanagementsystem verwendet und die Konfiguration für Puppet geschrieben, um all dies zu verwalten.

SELinux Puppet Modul:

• http://github.com/sansnoc/puppet/tree/master/selinux

Der Grund für das Deaktivieren liegt darin, dass das Debuggen schwierig sein kann.

Allerdings schalten wir es jetzt nicht aus. Wir halten es fast immer am Laufen. Ich schalte es gelegentlich aus, um schnell zu überprüfen, ob SElinux ein Problem ist oder nicht.

Das Debuggen ist jetzt viel einfacher, insbesondere wenn Sie sich mit audit2allow vertraut machen. Sie müssen es mit audit2allow nicht wirklich verstehen, aber manchmal kann es passieren, dass sich die Öffnung weiter öffnet, als Sie es mit audit2allow denken. Allerdings ist SELinux besser als keines.

Ich bin kein SELinux-Experte und benutze es erst seit ein paar Jahren. Ich verstehe die Grundlagen immer noch nicht wirklich, aber ich weiß genug, um Apps zum Laufen zu bringen, neben denen, die in der Distribution enthalten sind und zufällige Sachen, die aus dem Netz kompiliert wurden.

Die Hauptsache ich Gebrauch gehabt haben sind die ls -lZ(Show SELinux Kontext) audit2allow, chcon, semodule, getenforce, setenforceund booleans. Mit diesen Tools habe ich es geschafft, jede App unter SELinux zum Laufen zu bringen.

Ich finde eines der großen Probleme beim Debuggen von SELinux-Problemen. Ich erinnere mich einfach daran, nach SELinux-Problemen zu suchen, wenn ich andere unerklärliche Probleme habe. Normalerweise brauche ich ein wenig Zeit, um "h! Check SELinux !!"

Laut der Bind-Manpage ist SELinux weitaus sicherer als das Ausführen von Bind in einem Chroot-Gefängnis. Viele andere Leute, die weit mehr Ahnung haben, als ich empfehle, empfehlen es ebenfalls, also führe ich es jetzt blind aus. Und vermuten, trotz des gelegentlichen Problems lohnt es sich wahrscheinlich, es zu tun.

Ich habe SELinux für AppArmor deaktiviert und fand es viel benutzerfreundlicher und leichter zu warten als SELinux.

Es gibt keinen Grund, es auszuschalten, wenn Sie es im zulässigen Modus ausführen können. Die ausgeführte Anwendung wird nicht beeinträchtigt, und es wird weiterhin eine nützliche Sicherheitsprotokollierung bereitgestellt. Die einzige Ausnahme betrifft die Benutzerkontexte: Wenn Sie zwischen verschiedenen Benutzern wechseln, die sich in einer anderen Linux-Instanz befinden, die in einer Chroot-Umgebung ausgeführt wird, können Probleme auftreten.

SE Linux ist nicht mehr so ​​hoffnungslos unfreundlich wie früher, zumindest nicht in kommerziell unterstützten Distributionen wie RHEL5. Zum größten Teil können Sie es eingeschaltet lassen, und alles, was von RedHat bereitgestellt wird, ist in Ordnung. Mit etwas anderem kann es variabel sein. Das Problem ist, dass professionelle Servicearbeiten, um Anwendungen mit SE Linux zum Laufen zu bringen, eine gute Einnahmequelle für Unternehmen wie RedHat und Oracle darstellen.