Heute morgen habe ich PAM installiert und daraufhin shadow nochmal neu aufgesetzt, alles SELinux-kompatibel und es läuft ... man sollte überlegen, ob man Dein EasyLFS nicht gleich mit allem Sicherheitskram ausstattet und folglich "EasyLFS SE" nennt

Mit PAM hab ich mich bislang auch nicht gross auseinander gesetzt.
Ich hatte glaub ich mal versucht es irgendwann irgendwo einzubinden aber anschliessend war kein Login mehr moeglich wenn ich mich recht erinnere.
Ich muss da also scheinbar was falsch gemacht haben.

Wird PAM denn auch effektiv genutzt oder ist es einfach nur da?
Welchen Vorteil bringt uns PAM?

PAM bringt den Vorteil, dass es sämtliche Logins abgreift, OpenSSH noch etwas mehr einschränkt (absichert) und eben auch auf SELinux aufsetzt. Ich vermute, da es auf SELinux aufsetzt, dass es intern ebenfalls den Context abprüft, ob im Sys was passieren darf. Ersteres ist aber Fakt - SuSE und RedHat setzen das schon seit Jahren ein

Ich denke es koennte durchaus eine Ueberlegung wert sein PAM einzubauen.
Aber ich denke eher in der nachfolgenden Version und nicht mehr in der kommenden, da ich ja jetzt im Grunde schon bei den letzten Tests bin und ungern noch was umfangreiches wie PAM einkleben moechte.

Allgemein bin ich auf jeden Fall nicht abgeneigt PAM einzubauen, moeglicherweise sogar als Teil der Standardinstallation.

Joah, würde ich gut finden - ich denke, das hebt das Linux von anderen Selbstbau-sachen doch stark ab

Ich denk allein durch den SELinux-Support kann sich EasyLFS schon von so einigen Distributionen abheben. Denn so viele Distributionen duerften dies auch nicht bieten.
Suse ist nach einem kurzen Zwischenspiel mit SELinux auf AppArmor, welches aber nicht so umfassenden Schutz bietet wie SELinux, umgestiegen und auch bei vielen anderen Distributionen vermisst man es im Auslieferumfang.
Ausserdem bin ich eben auch der Meinung "wenn SELinux, dann auch richtig", also dass es gleich mit dem System installiert wird und auch die Software, soweit noetig, darauf abgestimmt wird.

Und wenn wir dann eben auch noch PAM bieten waer das noch besser.

Ich hab mir auch vorgenommen mich mal etwas mit UDev auseinander zu setzen um noch umfassendere Regeln ausliefern zu koennen sodass z.B. kein zusaetzliches Script mehr noetig ist um beim Systemstart z.B. die USB-Module zu laden und sowas.
Sollte ja eigentlich ueber UDev moeglich sein.

hm, soll ich dir was sagen ? ich hab von udev absolut NULL ahnung ... ich freu mich, wenn es - den letzten kernel, den ich vor deinem 2.6.19 kompiliert habe, war noch aus der 2.4er Reihe ... und da brauchte ich weder udev noch /sys noch /srv, wo ich mich frage, was /srv macht - das verz. ist in allen Distris die hin und wieder mal teste immer leer

...das einzige, was ich über udev weiss ist, dass es wohl hotpug ersetzt *glaub*

/srv ist einfach nur da, und zwar aus dem Grund dem FHS zu entsprechen.
Warum die Distributionen nicht so konsequent sind und es auch mal nutzen anstatt es einfach nur dem Standard zuliebe kann ich aber auch nicht nachvollziehen.

Viel hab ich mit UDev bisher auch nicht gemacht. Ich hab mal eine Regel geschustert die einen SymLink fuer meinen MP3-Stick anlegt, egal welches Device er zugewiesen bekommt, sodass ich eben immer auf /dev/mp3stick zugreifen kann und 2 Regeln fuer meine CD-Laufwerke.
Mit dem Laden von Modulen hatte das alles aber nichts zu tun.

Aber ich hab bei einem Blick auf ein paar Regeln was dazu gesehen und gehe somit davon aus, dass es machbar sein sollte.

/sys finde ich persoenlich uebrigens eine Klasse Sache. Man bekommt dort einen Haufen nuetzlicher Informationen gut sortiert praesentiert. Geplant ist ja scheinbar, dass saemtliche Hardware-Informationen von /proc nach /sys wandern, was im Grunde keine schlechte Idee ist, nur eben noch ein paar Jahrzente dauern duerfte.

Nachtrag: Frueher haben Hotplug und UDev zusammengearbeitet. Seit Kernel 2.6.irgendwas (ich glaub 16) ist Hotplug aber wohl nicht mehr notwendig.

naja, bisher nutze ich noch /proc, da ich weiss, wo man was findet ... was udev betrifft, hab ich mich ja schon öfter gewundert, wie das geht, dass mein cdrom automatisch gefunden wird ... ich dachte bis dato immer dran, dass die gucken, welches LW nen cdrom ist und in proc gucken oder im dmeg nen grep veranstalten ... also ist ja udev ne schöne sache, wenn das das ganze scripting ersetzt und man nicht per hand den symlink von /dev/hd? auf /dev/cdrom setzen muss

was mir gerade dazu einfällt:
Ich hatte was falsch an der config gemacht, als ich mit SELinux gebastelt hatte und init konne keine console mehr öffnen, weil die devices fehlten - konnte das damit umgehen, dass ich per hand in /dev/console und /dev/null mit mknod angelegt habe. vielleicht sollte man vor dem mounten die geräte im bootscript trotzdem anlegen, falls beim boot/mount was schief geht - dann kommt man wenigstens noch bis zum login - so musste ich am lilo "init=/bin/sh" eingeben, um ans system zu kommen

/dev/console und /dev/null sollte es eigentlich geben.
Diese werden bei der Installation angelegt da diese, wenn ich mich recht erinnere, schon vor UDev oder von UDev benoetigt werden.
Der Rest wird dann dynamisch angelegt.

Code bash:

1 2 3 4 5 6 7

LFS_JOB="populating /dev" echo $LFS_JOB   mknod -m 600 /dev/console c 5 1 || LFS_ERROR=1 mknod -m 666 /dev/null c 1 3 || LFS_ERROR=1   . /lfs-install/modules/error.sh

Zitat von Dennis Wronka

Ich hab mir auch vorgenommen mich mal etwas mit UDev auseinander zu setzen um noch umfassendere Regeln ausliefern zu koennen sodass z.B. kein zusaetzliches Script mehr noetig ist um beim Systemstart z.B. die USB-Module zu laden und sowas.
Sollte ja eigentlich ueber UDev moeglich sein.

Da hätte ich einen interressanten Link als Lektüre!

Schönen Tag noch, man liest sich.
Euer Jens Ornot alias Webstar

Vielen Dank fuer den Link, die Anleitung werd ich mir mal zu Gemuete fuehren.

Wahrscheinlich war es bei mir so, dass ich das Sys schon zu weit hoch hatte, und tmpfs schon nach /dev gemounted war - somit konnte init auf die konsole nich mehr zugreifen ... ich hatte was am udev-script gemurkst weil ich die rechte mit restorecon neu setzen wollte und im script einen tippfehler hatte

Nochmal zu PAM:
PAM lässt sich mit shadow und SELinux in den aktuellen Versionen installieren und konfigurieren (shadow=4.0.18.1 vom debian-ftp, pam=0.99.7.1 von ftp.kernel.org), hab nur noch ein kleines login-problem: PAM fragt beim login, welchen kontext ich benutzen will - find ich nich so klasse, da ein unerfahrener user da eh keine ahnung von hat ..werde also noch versuchen, ein"default" zu bastel nund die nächsten Tage ein Online-Tut zur Verfügung stellen

Bis denne
Andy

Nachtrag:
Habe bis heute morgen im Sys gefummelt, um PAM und SELinux zu koppeln, ist ja echt mal jede Menge Konfigurationsarbeit ...soweit läufts jetzt erstmal ohne die dumme Abfrage, habe aber noch 2 wichtige Sachen, die Du bitte ins Sys integrieren müsstest Dennis:

1.) /var/log/wtmp fehlt
2.) /var/log/lastlog fehlt
3.) /etc/shells fehlt
4.) /etc/securetty fehlt ebenfalls

Die Dinge gehören eigentlich zum Standard und werden von PAM bitter benötigt - vielleicht kannst du das im nächsten Release berücksichtigen

LG
Andy

So, ich bin auf ein kleines, aber wirklich unguenstiges Problem mit der Installation von SELinux gestossen, oder eigentlich eher mit den CoreUtils.
Der SELinux-Patch macht es notwendig, dass autoconf und automake vorhanden sind, sonst bricht die Installation der CoreUtils ab, was unguenstig ist.
Nur koennen eben diese zu dem Zeitpunkt wo die CoreUtils installiert werden noch nicht installiert werden sodass ich mich entschieden habe die CoreUtils, genau wie auch die GLibC, ein weiteres Mal zu installieren falls SELinux-Support aktiviert wurde.
Dies geschieht nun zusammen mit den SELinux-Utils, was so ziemlich am Ende der Stage 2 geschieht und somit sollte es auch keinerlei Probleme mit irgendwelchen Abhaengigkeiten geben.
PsMisc, Shadow und Util-Linux werden eh erst recht spaet installiert und da sind dann auch schon autoconf und automake da, falls diese dort denn ueberhaupt noetig sind. Damit sollte es also keine Probleme geben, aber das werd ich wohl erst etwas spaeter sehen.

Auf jeden Fall hab ich jetzt die Scripts was angepasst sodass die CoreUtils also erstmal ganz normal installiert werden und spaeter nochmal mit SELinux-Support.
War schon etwas wundersam, dass ich alles ohne Probleme im fertigen System kompilieren konnte nur eben beim Bau eben diesen Systems kamen dumme Fehler.
Naja, aus Fehlern lernt man und ich denke wir sind jetzt wieder einen Schritt weiter.

Nur wurde dadurch jetzt der Release etwas verzoegert und ich glaube nicht, dass ich vor Samstag morgen (wo erstmal meine letzte Chance fuer einen Upload ist bevor ich umziehe und ich in der neuen Wohnung mit dem sagenumwobenen Internet ausgestattet werde) die endgueltige LiveCD aus dem Aermel schuetteln kann.
Unmoeglich ist es aber nicht, das setzt aber voraus, dass jetzt alles glatt laeuft und ich wahrscheinlich morgen Abend ein paar Ueberstunden einlegen muss.

Zu Deinem Nachtrag: Werd ich mir mal anschauen.