Also eigentlich wollte ich das Ganze schon ueberschaubar, also im Rahmen einer CD halten.
Die Moeglichkeit mit den zusaetzlichen Modulen gefaellt mir da noch am besten.
Das Problem dabei duerften nur die Abhaengigkeiten zu anderen Paketen sein.

In meinen Scripts, welche ja sozusagen alle voneinander wissen kann ich mit Abhaengigkeiten ziemlich einfach fertig werden, ein zusaetzliches Modul hingegen muesste z.B. mit find oder whereis pruefen ob eine notwendige Library bereits installiert wurde (falls diese nicht zum Standardumfang gehoert) und diese gegebenenfalls nachinstallieren.

Ja gut, installiert man zB KDE oder Gnome, werden natürlich noch zig Bibliotheken benötigt, und da bietet sich dann wohl doch an, das ganze in Pakete zu schnüren. Wobei mir da einfällt,dass man dann gleich mit RPM installieren kann, um diese Abhängigkeiten zu gewährleisten *an SuSE und RH denk, die dann schnell mal 200GB Platz brauchen *

RPM und DPkg sind ja in EasyLFS enthalten, und in der kommenden Version duerfte DPkg sogar funktionieren.

Funktionieren tut es schon, ganz sicher - aber soweit ich mal mit einem früheren LFS experimentiert habe, musste ich feststellen, dass sich RPM bei einer nicht zum System gehörenden RPM-DB beschwert hat, dass Paket b ohne Paket a nicht installiert werden kann, und ich ja noch nich mal ne Bash habe - was aber der Fall war. Man muss also RPM erstmal beibringen, was alles da ist, damit man damit richtig arbeiten konnte. Habe RPM in meinen selbst kompilierten Systemen nicht mehr verwendet, brauchte nur die Libs davon und Cpio, um RPM zu dekomprimieren

RPM funktioniert im Grunde soweit, DPkg eben erst mit der kommenden Version, da dafuer noch ein paar Dateien erstellt werden mussten.
Dass beide Paketmanager grundlegende Pakete nicht finden liegt daran, dass diese nicht in deren Datenbanken stehen, um solche Abhaengigkeiten zu umgehen gibt es aber bei beiden Managern die Moeglichkeit diese nicht zu ueberpruefen. Ist zwar nicht ganz fein, aber zum einen ist EasyLFS kein Einsteigersystem, zum anderen sollen die beiden Paketmanager eben nur dafuer da sein, dass man eben die Moeglichkeit hat fertige Pakete zu installieren.

Nun ja - ich gebe Dir soweit recht, aber mit Binär-Paketen gibts auch Probleme, denke ich. Habe versucht, Firefox binär laufen zu lassen (gibts leider nur bis Version 1.5), da ich zu faul war, selbst zu kompilieren, aber ohne passende libstdc++-5 gehts nicht. ich werd mich hüten, auf ne niedrigere glibc zu gehen, nur damit die alte version von firefox läuft

Vielleicht mach ich mal nen Geh-Versuch und versuche ne ältere glibc parallel zu installieren, natürlich in einen OS-untauglichen Pfad hinein, um mit einem Startscript den Browser zu starten, wo dann die libc geladen wird - sollte ja funktionieren, denke ich *g*

Oft, bei Skype z.B. hatte ich das mal, reicht scheinbar ein SymLink mit dem passenden Namen.
Aber Du hast schon recht, die GLibC zu ersetzen ist etwas was man nicht unbedingt machen sollte. Ich hab mir vor langer, langer Zeit mal meine Suse damit zerschossen.

Mit einem Symlink hab ich's versucht, brachte aber nur die Fehlermeldung, dass die Symbole in libstdc-6 nicht gefunden wurden, die der Feuervogel dort gesucht hat. Java hingegen läuft mit einem Symlink noch ganz gut

Ich wollte mal kurz die Aufmerksamkeit auf meinen vorsichtigen, vorlaeufigen Veroeffentlichungstermin fuer EasyLFS 0.3 lenken. Dieser Termin ist erstmal fuer Sonntag den 13. Mai angesetzt.
Details finden sich im verlinkten Blog-Eintrag.

Sooooo ...nur mal als allgemeine Info: Heute wurde nun endlich der neue Kernel 2.6.21 released - für mich bedeutet das gleich mal einen neuen Kernel aufzusetzen und SELinux auf die kommende Version 2.0 zu updaten, die Builds dafür stehen ja schon länger auf www.nsa.gov/selinux zur Verfügung. Auch eine neue refpolicy gibt es: refpolicy-20070417, diese wird dann gleich mit integriert. Infos werde ich zu diesem Projekt natürlich hier und auf meiner Webseite hinterlassen

Argh, und das jetzt wo ich in den Endspurt uebergehen will.
Na mal schauen ob sich der Quatsch noch fuer die 0.3 einbauen laesst, testen werd ich auf jeden Fall mal.
Der Kernel sollte ja kein Problem darstellen, aber SELinux und die RefPolicy koennten haarig werden.

Wie weit ist Deine Targeted-Version der Policy ? Wäre nett, wenn Du mir evtl. mal eine Kopie als Vergleich schicken könntest - zum Testen der neuen 0.3 EasyLFS werde ich leider erstmal nicht kommen, da ich zur Zeit bissi viel zu tun habe, aber ich werde zumindest mein SELinux-Project weiterführen, das geht auch mal abends oder am WE :|

Wenn ich daheim bin lad ich hier mal den Patch gegen die ReferencePolicy von Dezember hoch, dann kannst Du mal schauen. Dort ist aber nur Kram drin der eben fuer EasyLFS relevant ist, zusaetzliche Pakete die der User evtl. noch installieren koennte werden dabei nicht bedacht.
Ich bin also nur anhand der Meldungen von audit2allow vorgegangen.

Wenn ich mich recht erinnere hab ich dort auch schon ein paar Sachen fuer die Strict-Policy drin, ganz sicher bin ich aber nicht da ich den Patch ein paar Mal neu erstellt hab. Koennte also sein, dass in dem aktuellen Patch die Sachen fuer die Strict-Policy nicht drin sind.

Würde mir auch erstmal reichen um zu sehen, wie Du das umgesetzt hast, bzw ob wir da parallel arbeiten - ich habe leider den Verdacht, dass ich mit meiner Policy zu selbst-eigen bin, d.h, dass meine Policy womöglich woanders nicht so funktioniert, wie bei mir.

Dass sie, wie du schon schreibst, nicht überall laufen wird, ist mir klar, trotzdem ich da auf den FHS geachtet habe. zB fängt es bei mir an, dass die originale refpolicy KDE in /opt/kde3 installiert, und QT in /usr - was mir gar nicht passt. KDE ist bei mir in /opt/kde-3.5.6 und /opt/kde ist nur ein Link, bei Qt4 ist es ähnlich. Dann noch Xorg-7.1, was bei mir in /usr/X11 liegt, habe das so gemacht, da Xorg mit X11R6 nichts mehr zu tun hat und den Code zwecks Updates getrennt zu halten. refpolicy besagt aber, dass X11 nach /usr/X11R6 oder direkt nach /usr gehört ... sind lauter so Sachen, die man entweder komplett in EasyLFS anpassen müsste und das bereits in der Policy berücksichtigt, oder man lässt das aussen vor und überlässt das dem User, wo ich denke, nicht jeder User wird sich gleich auf die SELinux-Sache stürzen, wenn EasyLFS erstmal als solide Basis eines guten OS installiert ist

So, hier mal mein Patch fuer die Reference-Policy.
Die bisherigen Anpassungen fuer die Strict-Policy sind auch mit drin. Wenn man diese auf Enforcing stellt kann man sich aber, wegen einem bisher nicht erlaubten Kontextwechsel, nicht einloggen.

Ich hab auch diese Stack- und MemExec-Anpassung uebernommen die ich eigentlich vermeiden wollte, aber einen anderen Weg konnte ich nicht finden. Bei der Strict-Policy besteht dieses Problem auch nicht, was auch ein Grund ist warum ich auch weiter an der Strict-Policy arbeiten werde um im Endeffekt auch diese anbieten zu koennen.