EasyLFS Projektthread

[Dennis Wronka]

So, ich hab jetzt SELinux im Targeted-Enforcing-Mode laufen. Soweit scheint alles zu funktionieren, inklusive dem SSH-Server.
Jedoch musste ich fuer den SSH-Server einen recht unschoenen Fix einbauen. Dieser Fix betrifft uebrigens nicht nur SSH, sondern z.B. auch Bind und wohl alle Daemons (oder gar alle Programme) die libcrypto nutzen.
In welchem Kontext laeuft bei Dir der SSH-Server? Bei mir ist es unconfined_t, was ich zur Zeit libcrypto in die Schuhe schiebe.

 

[andy72]

hm,bei mir gibts auch Probleme, allerdings im X11, KDE und libmng: X11 will unbedingt die libmng und libGL im Stack ausführen, das Audit im Kernel-Log ist "execstack" bei libGL, und "execmod" bei libmng. Eine Lösung gibts nicht, man muss die libs wohl lassen -was /ich/ bei Client-Programmen recht gefährlich finde

sshd läuft bei mir, auch im rechten Context: System_ubject_r:sshd_exec_t.
ABER: ich hab die Policy dazu nicht angepasst.Das einzige, was ich geändert habe ist, dass /etc/selinux kein link mehr auf /etc/security/selinux ist sondern ein reguläres Verzeichnis - vielleicht ist genau DAS das Problem, ichhatte mit dieser Variante auch zig Audits im Kernel.

Noch was: hostname, hwclock, ip etc lies sich nur fixen, indem der sysklogd nichts mehr auf die Console wirft - dazu habe ich die /etc/syslog.conf angepasst und im ersten init-script noch "dmesg -n 1" hinzugefügt, seitdem läufts.

 

[Dennis Wronka]

hm,bei mir gibts auch Probleme, allerdings im X11, KDE und libmng: X11 will unbedingt die libmng und libGL im Stack ausführen, das Audit im Kernel-Log ist "execstack" bei libGL, und "execmod" bei libmng. Eine Lösung gibts nicht, man muss die libs wohl lassen -was /ich/ bei Client-Programmen recht gefährlich finde

Genau dieses execstack-Problem hab ich im Zusammenhang von SSH und libcrypto (OpenSSL).
Aber ich hab jetzt moeglicherweise eine Loesung dafuer gefunden, ich hab naemlich SSH ohne --with-selinux kompiliert, was durchaus eine Erklaerung sein koennte.

sshd läuft bei mir, auch im rechten Context: System_ubject_r:sshd_exec_t.
ABER: ich hab die Policy dazu nicht angepasst.Das einzige, was ich geändert habe ist, dass /etc/selinux kein link mehr auf /etc/security/selinux ist sondern ein reguläres Verzeichnis - vielleicht ist genau DAS das Problem, ichhatte mit dieser Variante auch zig Audits im Kernel.

Hmm, komisch. /etc/security/selinux hab ich bislang vollkommen aussen vor gelassen, /etc/selinux ist also bei mir ein echtes Verzeichnis.

Noch was: hostname, hwclock, ip etc lies sich nur fixen, indem der sysklogd nichts mehr auf die Console wirft - dazu habe ich die /etc/syslog.conf angepasst und im ersten init-script noch "dmesg -n 1" hinzugefügt, seitdem läufts.

Hiermit hatte ich keinerlei Probleme, ich hab lediglich die entsprechenden Regeln gemaess audit2allow eingetragen und hatte keine Probleme mehr.

Nachtrag: Ich hab da was gefunden. Wenn man den ASFLAGS --noexecstack hinzufuegt sollte es gehen. Das hab ich im Zusammenhang mit OpenSSL gefunden, sollte aber auch bei anderen betroffenen Libraries helfen koennen.

--noexecstack don't require executable stack for this object

 

[andy72]

Mit libmng geht das evtl. ja noch mit den ASFLAGS, jedoch hab ich die libGL und libGLUT von nVidia - die sind ja bekanntl. im Binärformat ...die könnten ruhig die Linuxtreiber und libs opensource machen, denn gäbe es sicher weniger Probleme, die Software anzupassen.

Ich sehe gerade, d-bus meldet auch audits im log, aber nur, dass er in /var/run nix ausführen bzw nix schreiben darf ...werde ich also auch noch fixen *grummelz*

blöde Frage: libcrypto kommt von cracklib, oder ? hab die noch ned installiert - werde ich probehalber mal machen ...muss jetzt erstmal auf Arbeit

*Schönen Tag wünsch*

 

[Dennis Wronka]

Mit libmng geht das evtl. ja noch mit den ASFLAGS, jedoch hab ich die libGL und libGLUT von nVidia - die sind ja bekanntl. im Binärformat ...die könnten ruhig die Linuxtreiber und libs opensource machen, denn gäbe es sicher weniger Probleme, die Software anzupassen.

Es gibt in den Regeln fuer unconfined noch einen separaten Eintrag fuer Objekte die auch im Stack ausfuehren duerfen, diese muessen aber wahrscheinlich auch anders gelabelt werden. Evtl. liesse sich darueber was machen. Bisherige Versuche meinerseits sind da aber wenig erfolgreich gewesen.
Und gut, dass ich ATI nutze, da gibt es auch einen freien Treiber.

blöde Frage: libcrypto kommt von cracklib, oder ?

Nein, libcrypto kommt aus OpenSSL.
Irgendwie will OpenSSL mit dem ASFLAGS-Zusatz aber nicht kompilieren. Muss mal schauen, hab vorhin auch einen Patch dafuer gesehen.

 

[Dennis Wronka]

Was kommt bei Dir dabei rum wenn Du id ausfuehrst?
Ich hab das Gefuehl, dass bei mir die User nicht richtig mit Rollen bestueckt werden, denn auch root laeuft als unconfined_t.

 

[andy72]

Bei mir ist root ebenfalls unconfined_t - das hängt aber an dem Type der Policy. Im Targeted-Mode ist jeder User unconfined_t, das heisst, er darf (fast) alles tun. Dieser Modus bietet nur schutz für Server-Anwendungen, soviel ich gelesen habe. Der Strict-Mode erlaut dann die Feinabstimmung, jedoch gibts da dann wohl noch etwas mehr zu konfigurieren

 

[Dennis Wronka]

Im Targeted-Mode gibt es also keine zusaetzlichen Einschraenkungen fuer User, eben nur was Linux selbst bietet, nur bestimmte Dienste werden gezielt (targeted) beschraenkt, richitg?
Wo hast Du eigentlich Deine ganzen Informationen her, dann kann ich mich da auch mal durchwuehlen. Ich hatte von linuxsecurity.com ein paar Abhandlungen, die waren aber eher allgemein ueber SELinux an sich.

 

[andy72]

Genau so ist es - es werden nur die notwendigsten Dienste geschützt. M.E. bringt das für die Sicherheit des Users bzw für den Rechner nix, wenn der User alles (kaputt machen) darf

Habe sämtliche Infos über Google gefunden, teils aus RedHat's Documentation über die Verwendung von SELinux, Teils von Gentoo und wiederum einiges aus Mailinglisten

 

[Dennis Wronka]

Ich hab heute mal ein wenig rumgespielt und auch mal Engarde Secure Linux installiert, welches wohl "das Vorbild schlechthin" sein muesste in Sachen SELinux-Integration.
Auf jeden Fall bin ich nun wieder einen Schritt weiter, und zwar durch die Installation von PAM. Jetzt scheint der User-Context mehr Sinn zu machen, und ich hab auch die Strict-Policy zu grossem Teil nutzbar machen koennen, nur werden wohl einige Aenderungen durch PAM nun ueberfluessig werden, oder muessen eben wieder angepasst werden. Aber das ist nicht so tragisch, ich werd dann wohl nochmal mit einer frischen Policy anfangen und mich wieder durch die Meldungen von audit2allow kaempfen.
Jetzt zum Test ist PAM erstmal als Option drin, falls es sich aber hinreichend gut integrieren laesst werde ich es wohl zum Standard erklaeren.

Dank PAM bekomm ich bei id nun auch den Context root:sysadm_r:sysadm_t angezeigt, zumindest in der Strict-Policy.
Zuvor ging dies nur wenn ich mich ueber SSH eingeloggt hab.