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.

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_u:object_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.

Zitat von 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

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.

Zitat von andy72

sshd läuft bei mir, auch im rechten Context: System_u:object_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.

Zitat von andy72

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.

Zitat von as --help

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

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*

Zitat von 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.

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.

Zitat von andy72

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.

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.

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

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.

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

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.

Um auch hier mal wieder ein kleines Update einzubringen:
Es geht voran. Die Targeted-Policy scheint nun soweit nutzbar, der Resume-Support ist fast fertig und es hat sich kurzfristig ergeben, dass EasyLFS 0.3 hoechstwahrscheinlich GPG enthalten wird.

Wie in meinem Blog geschrieben moechte ich Euch nun wieder herzlich dazu einladen Ideen und Vorschlaege zu praesentieren, welche dann in Zukunft (also nach 0.3) umgesetzt werden koennen.

Hmm, Ideen lassen ja noch etwas auf sich warten, aber dafuer gibt es ein Update.
Zum einen scheint das Wiki, und somit auch die Downloadseite, zur Zeit leider nicht erreichbar zu sein.
Zum anderen geht es mit grossen Schritten in Richtung EasyLFS 0.3.
Ueber's Wochenende hab ich vollstaendige Testbuilds sowohl mit als auch ohne SELinux gefahren und es sieht soweit alles sehr gut und vielversprechend aus, auch die SELinux-Policy und PAM scheinen wunderbar zu funktionieren.
Letzte Probleme wurden beseitigt sodass fuer die Fertigstellung jetzt im Grunde nur noch der Resume-Support fehlt.

Noch bin ich nicht ganz sicher ob ich PAM schon fuer EasyLFS 0.3 mit in den Standardumfang aufnehmen soll. Klar ist aber, dass wenn dem nicht so ist es standardmaessig zur Installation ausgewaehlt sein wird.

Falls jemandem ein Grund einfaellt warum PAM nicht Standard werden sondern eine Option bleiben sollte waere es nett diesen zu erfahren. Ich sehe naemlich zur Zeit keinen.
Im Grunde setzen alle grossen Distributionen auf PAM, und allgemein scheint eine sinnvolle Geschichte zu sein.

Folgt man der LSB 3.1 ist PAM genauso "empfohlen" wie Qt4 etc - damit man zur LSB konform ist, muss man also scheinbar ein Komplett-System zur Verfügung stellen ...ich für meinen Teil benutze Linux gerade DESHALB, da es in Punkto Sicherheit einiges mehr als ein Windows zu bieten hat und eben dieser Punkt das System für mich erst interessant macht. Also plädiere ich natürlich dafür, dass PAM seinen Weg in EasyLFS findet, und zwar als Standard - wer es nicht mag, soll es aber abschalten können, genauso wie den Midnight-Commander, SELinux oder Lynx.

Weitere Idee: Optional Xorg 7.x sowie ein Gnome oder KDE - DAS macht EasyLFS erst für viele interessant denke ich, und stellt auch erst DANN eine ECHTE Alternative für Klicki-bunti-Ubuntu oder Gentoo dar - EasyLFS hat dann SELinux und einen Desktop, dazu noch eine Standard-Firewall, die dem User erlaubt, alles nach drausen zu senden aber nix hinein zu lassen und ist somit dann ebenbürtig mit RHEL

Zitat von andy72

Folgt man der LSB 3.1 ist PAM genauso "empfohlen" wie Qt4 etc - damit man zur LSB konform ist, muss man also scheinbar ein Komplett-System zur Verfügung stellen ...ich für meinen Teil benutze Linux gerade DESHALB, da es in Punkto Sicherheit einiges mehr als ein Windows zu bieten hat und eben dieser Punkt das System für mich erst interessant macht. Also plädiere ich natürlich dafür, dass PAM seinen Weg in EasyLFS findet, und zwar als Standard - wer es nicht mag, soll es aber abschalten können, genauso wie den Midnight-Commander, SELinux oder Lynx.

So ist es bisher geregelt, PAM ist standardmaessig ausgewaehlt, der User kann aber vor der Installation dafuer sorgen, dass es nicht installiert wird.
Ich werde es dann wohl optional lassen, aber als Abhaengigkeit fuer SELinux definieren, sodass es auf jeden Fall installiert wird wenn SELinux installiert wird.

Zitat von andy72

Weitere Idee: Optional Xorg 7.x sowie ein Gnome oder KDE - DAS macht EasyLFS erst für viele interessant denke ich, und stellt auch erst DANN eine ECHTE Alternative für Klicki-bunti-Ubuntu oder Gentoo dar

Dann duerfte es in dem CD-Image aber ordentlich eng werden. Ich bin ja jetzt schon bei 450MB, mit X und KDE waere ich wahrscheinlich bei 700-800MB, was dann nicht mehr passen wuerde. Und da waeren dann auch nicht noch die ganzen zusaetzlichen Libraries zur Aufloesung von Abhaengigkeiten und fuer zusaetzliche Features in KDE (von QT ganz zu schweigen ) dabei.

Moeglicherweise lassen sich solche grossen Zusatzpakete ueber eine weitere CD machen, vergleichbar mit BLFS. Dort koennten dann einige grosse Pakete inklusive ihrer Abhaengigkeiten und eben den passenden Installationsscript liegen und so dann auch solche Pakete schoen automatisiert installiert werden.

Allgemein wollte ich eigentlich EasyLFS eher kompakt halten, aber schon einen gewissen Satz sinnvoller Software mitbringen.
Falls ich mich dazu hinreissen lasse grosse Pakete auf eine zusaetzliche CD auszugliedern koennte ich evtl. sogar ueberlegen alle optionalen Pakete die nicht so tief im System sitzen wie SELinux und PAM auszugliedern um das eigentliche EasyLFS wieder etwas schlanker zu machen.
Eine andere Moeglichkeit waere die Modularitaet der Linux-Live-Scripts zu nutzen und optionale Pakete als Module anzubieten. Diese koennten dann in die LiveCD eingebaut werden und mitkompiliert werden.

Zitat von andy72

EasyLFS hat dann SELinux und einen Desktop, dazu noch eine Standard-Firewall, die dem User erlaubt, alles nach drausen zu senden aber nix hinein zu lassen und ist somit dann ebenbürtig mit RHEL

Ein Firewall-Script zu erstellen was alles dicht macht und per Connection-Tracking eben nur angefragte Daten reinlaesst ist kein Problem, das laesst sich machen.

Ich denke, in Zeiten von Multimedia-fähigen Rechnern könnte man ruhig über eine DVD nachdenken, jedoch diese alternativ zu 2 CD's anbieten, damit ältere Rechner darunter nicht leiden müssen ... ich persönlich würde das schon schön finden, wenn es ähnlich wie in Gentoo mehere Stages gäbe, die mir erlaubt, ein minimales grundsystem zu installieren, oder eben nach einlegen einer weiteren CD erlaubt, einen Desktop nachzuinstallieren.

Nachtrag:
Wenn man in Erwägung zieht, Xorg etc zu integrieren, könnte man das ja für Oktober vorsehen, wenn KDE 4 erscheint - dann könnte man einen genialen Desktop basteln - incl. D-BUS & HAL