NFS mit gescheiter Auth?

Denke ich schiebe immer nur die INDEX und INDEX.db per cpdup (cp sollte doch auch reichen, oder?). Dann muß ich auf dem Hostsystem keinen Dienst laufen lassen und jedes system bleibt komplett eigenständig.

Wobei ich mich noch an deine Vorträge erinnere zu dem Thema, einfach von extern rumkopieren in die jails rein etc, alles solle per Dienst laufen, wie ftp ssh etc :-)

Aber bei solchen Dingen wie hier sehe ich keine Gefahr..

Gruß, incmc.
 
Man sollte eine Jail auch wie ein externes System behandel, imho. Also nicht einfach wild in das Verzeichnis kopieren in dem die Jail liegt. Das sage ich aber auch nur zu Leuten die noch keine Erfahrungen mit Jails haben, nicht das die sonstwas dann kopieren und sich später wundern.
Eine Gefahr sehe ich beim nächtlichen kopieren der INDEX aber auch nicht...
 
Hehe, jetzt muß ich aber aufpassen, dass ich die nicht kopiere bevor die jails den cvsuplauf gemacht haben.... :-) oder ich klammer die vom update aus.

Noch ne Frage:

Portupgrade braucht doch eh keine INDEX und INDEX.db oder irre ich mich? Denn das updatet auch wenn die beiden Files veraltet sind auf die neusten Versionen indem es selber nachschaut in den Portsverzeichnissen.

Gruß, incmc
 
Jetzt raff ich gerade was nicht. Ich lasse von den Jails alle Ports bis auf die INDEX* files ziehen. Die werden nur auf dem Hostsystem generiert mittels portsdb -Uu. Da kopiere ich alle INDEX* Dateien in die Jails hinein.
Aber aus irgendeinem Grund erstellen alle jails gerade selber ein neues INDEX.db und INDEX!!! Was soll das denn???

Gruß, incmc
 
Nein.

Das einzige was ich per Cron momentan Testweise versuche ist ein automatisches upgraden der Ports, ausser der echt wichitigen Dienste, wie Inn, proftpd... die mach ich lieber von Hand und habe sie daher in pkgtools.conf verboten. Hier das file aus periodic/daily

Code:
/usr/bin/nice -n 20 /usr/local/bin/cvsup /usr/local/etc/cvsup/ports-supfile
/usr/bin/nice -n 20 /usr/local/sbin/portupgrade -arRl /var/log/portupgrade.log
/root/skripte/daemonen-restart
exit 3

Die einzige Erklärung die ich habe ist, dass hier das Portupgrade anlief bevor das Hostsystem die neuen INDEX* FIles kopiert hatte, und dass portupgrade aber diese Dateien braucht. Daher läuft dann automatisch ein portsdb -Uu. Das dürfte dann ja ab jetzt nicht mehr passieren, da jetzt die INDEX* Dateien ja vorhanden sind. Ich hatte halt vorher alles in den jails unter /usr/ports platt gemacht...

Gruß, incmc
 
OK, das scheint zu stimmen, heute keine bauerei mehr in den jails, aber eines verstehe ich nicht: Wenn ich nun portversion aufrufe, dann machen die jails bei ersten mal immer folgendes:

Code:
[Updating the portsdb <format:bdb1_btree> in /var/tmp ... - 10795 port entries found .........1000.........2000.........3000.........4000.........5000.........6000.........7000.........8000.........9000.........10000....... ..... done]

Was machen die da?

Gruß, incmc
 
incmc schrieb:
2) FTP mounten geht auch noch nicht, weil ebenfalls noch nicht implementiert.
Und das bleibt hoffentlich auch so! FTP Mounts sind ja mit das krankeste, was man sich ausdenken kann...

4) SFS scheint mir immer eine interaktive Passphrasenabfrage zu benötigen, also nix beim booten mounten. (Das habe ich aber bis jetzt nur überflogen)
Es geht auch ohne. Aber ich gebe zu, es ist etwas schlecht dokumentiert

Zu dem restlichen Thread (habs nur ueberflogen). Du willst /usr/ports in saemtliche Jails mounten? Dann mach das mit mount_nullfs oder mit mount_nfs (jeweils read-only) vom Host-system aus. Den INDEX generiert natuerlich NUR der Host, die Jails sehen den ja dann direkt, da sie ebenfalls auf /usr/ports/INDEX zugreifen.

hth
 
Keine Ahnung wie ihr immer mount_nullfs kommt, bei mir heisst das immer noch mount_null. Also NOCH einmal: Verwendung dessen is laut man page wie gesagt nicht ausgereift und zudem wie auch gesagt nicht ro möglich, da sonst bei der Installation von Ports kein work Verzeichnis erstellt werden kann und auch kein distfiles Ordner. Das hatte ich alles schon oben wirklich ausreichen erklärt, also nicht überfliegen :-)

Was FTP mounten angeht, ich sehe nicht wieso das krank ist. Das ist nur nur ein weiteren Weg zu mounten. Was krank ist is NFS, quasi keine richtige Auth, DAS ist ein Witz... liegt halt an dem Entwicklungsdatum.

Also sind beide deiner Ideen leider nicht sinnvoll (s.o.)

Gruß, incmc
 
Für was sind denn die Jails? Für Dich oder sind das Jails die alle ne externe IP haben und die andere, mehr oder weniger "fremde" nutzen sollen und Du dieses anbietest?
Nutzt Du diese privat, dann nimm "mount_nullfs" und mounte die ports vom hostsystem temporär, wenn Du sie brauchst, in die Jail. Oder aber, wenn Dir die manpage Angst einjagt (was nicht sein müsste da mount_nullfs hier stabil rennt), dann mach einen NFS-loopmount im Hostsystem von /usr/ports nach /jail/usr/ports. Auch das geht.
 
Denk mal weiter.... wenn er die Ports modifiziert, könnt er es im Extremfall schaffen, dass andere Dateien installiert werden. So könnt er alle anderen Jails / Systeme unterwandern (denn sie teilen sich hier die Ports)! Krass gedacht, aber durchaus möglich.

Daher ist das keine Option, wenn man es richtig sicher haben möchte.

Gruß, incmc
 
aber genau dafür gibt es doch die crc-checks wenn du das "make install" machst.
und wenn täglich sowiso ein cvsup durchgeführt wird, sind alle änderungen des einbrechers eh fürn ars*h :D
also eher ein kleines bis nicht existierendes risiko.
 
Wenn man es "richtig" sicher haben möchte, dann hat jede Jails ihr eigenes /ust/ports. Da braucht man gar nicht weiter diskutieren.
Wenn jemand in das System eindringt wird er allerdings anderes machen als einen von über 10.000 Ports zu ändern. Und Du hast andere Probleme. Zumal in einer Jail die einen Serverdienst anbietet kaum etwas nachinstalliert wird, und wenn das updates und fixes und da macht man davor einen cvsup der ports um das neuste zu bekommen.
Für was sind denn die Jails gedacht?
 
Wie genau CRC funzt, musst du mir erklären. Da kenn ich mich nicht aus.

Dennoch zieht das zweite Argument nicht, es wäre immerhin möglich bis zur erneuten cvsup-Ausführung Unheil zu stiften. Zudem wenn er in ein System eingebrochen ist, kann er auch kontinuierlich dafür sorgen, dass gewisse Makefiles etc. immer zu seinen Gunsten sind.

Bleibt also die CRC Frage, weiss nicht was das ist. Wäre schön wenn es so ist, dann könnte ich wieder einen zentrals Ports Kollektion nutzen...

Gruß, incnc
 
die distfiles werden immer mit einer md5 checksumme überprüft.
geänderte makefiles werden jedesmal überschrieben. und wenn er tatsächlich ein anderes programm installieren wöllte, wäre das die dämlichste art und weise dies zu tun.
 
Was soll er denn im Makefile ändern?
Bevor man ein update eines Ports macht, macht man einen cvsuo Lauf.
Ein Eindringling wird versuchen root rechte zu erlangen, hat er diese wird er anderes machen als in einem wahllos ausgesuchtem Port was zu ändern. Er wird einen Trojaner hinterlassen, whatever.
Wenn Du merkst dss eingebrochen wurde, dann kontrollier anhand Deiner aide DB und anderen installieren tools was evtl. verändert wurde.
Am besten lösch einfach die betroffene Jail und kopier dir die backup Jail dieser Jail, die Du, nachdem alles installiert war, mittels cpdup kopiert hast und auf ein anderes Medium verbannt hast, an die Stelle der eingebrochenen Jail.

Nochmals, sprechen wir von einem privaten System, welche evtl. nichtmal eine stat. IP hat und nur von Dir genutzt wird?
 
Die Jails bieten FTP, News, HTTP etc. an, jeweils getrennt. Wie gesagt, wenn das kein P200 wäre würde ich natürlich alles jede jail selber machen lassen, das sagte ich ja auch bereits. Auf die paar MB mehr oder weniger Transfer sei dann gesch..., aber hier ist das einfach eine CPU Frage. Das ist sogar alles für Privag, aber ändert nichts an der Frage.

Gruß, incmc
 
Vergiss die Manpage. Bis jetzt hatte ich nur mit mount_unionfs Probleme, und das auch nur, als ich es bis zum Exzess getrieben hatte.

Code:
man mount_null
No manual entry for mount_null

Code:
% mkdir /tmp/jail
% sudo mount_nullfs -o ro /usr/ports /tmp/jail
% mount | grep ports
coyote:/usr/ports on /usr/ports (nfs)
/usr/ports on /tmp/jail (nullfs, read-only)
% sudo touch /tmp/jail/foo
touch: /tmp/jail/foo: Read-only file system

Wo liegt jetzt das Problem? Du solltest mount(8) lesen, und nicht nur ueberfliegen ;]

Dann setzt du noch WRKDIRPREFIX in den Jails und fertig ist die Laube. /usr/ports/distfiles solltest du entweder vom Hostsystem aus befuellen, oder RW mounten, oder sonst wie synchronisieren. Bei den Jails waere es sowieso sinnvoller auf Packages umzusteigen, und das ganze Geraffel mit den Ports lassen. Wenn ich das richtig verstanden habe, laesst du aus 4 Jails ein cvsup laufen? Die cvsup Hoster werden sich freuen...
 
Zuletzt bearbeitet:
Oh doch. Das änder etwas.
Sicherheit ist immer eine Frage das Aufwands den man betreiben möchte und ob es sich lohnt oder nicht.
Man man. Wenn Deine Serverdienste rennen, dann brauchst Du in den jails nichts mehr instgallieren, nur noch patches und updates der Serverdienste.
Also brauchst Du auch keine ports in den Jails. Du brauchst diese nur wenn es ein update, security fix gibt, und das bekommst Du über das Hostsystem mit wenn sich das was in den Ports zum jeweilgen Serverdienst was an der versionsnummer geändert hat.
Dann nimmst Du "mount_nullfs", mountest für x Minuten die ports in die jails, baust in der Jail neu, danach nimmst Du den mount wieder raus. fertig.
Das ist es was Du willst. Nicht mehr nicht weniger. Und Deine Security Paranoia von wegen veränderten Ports biste damit auch los (zumindest was über die jails gehen könnte).
Oder eben loopback NFS mount...
 
Code:
Spielen ~:mount_nullfs
-bash: mount_nullfs: command not found

Hier gibt es kein mount_null. Ist ein 4.x System. Evtl. ist das unter 5.x anders!?

Code:
% mkdir /tmp/jail
% sudo mount_nullfs -o ro /usr/ports /tmp/jail
% mount | grep ports
coyote:/usr/ports on /usr/ports (nfs)
/usr/ports on /tmp/jail (nullfs, read-only)
% sudo touch /tmp/jail/foo
touch: /tmp/jail/foo: Read-only file system

Keine Ahnung was du mir jetzt demonstrieren willst, was ich nicht weiss und schon gemacht habe :-)

Wo liegt jetzt das Problem? Du solltest mount(8) lesen, und nicht nur ueberfliegen ;]

Anscheinend haben wir andere mount_x Befehle...

Dann setzt du noch WRKDIRPREFIX in den Jails und fertig ist die Laube. /usr/ports/distfiles solltest du entweder vom Hostsystem aus befuellen, oder RW mounten, oder sonst wie synchronisieren.

Könnte ich mal testen, stimmt.

Bei den Jails waere es sowieso sinnvoller auf Packages umzusteigen, und das ganze Geraffel mit den Ports lassen.

Klasse Idee, veraltete Versionen zu nutzen...

Wenn ich das richtig verstanden habe, laesst du aus 4 Jails ein cvsup laufen? Die cvsup Hoster werden sich freuen...

Tja, genau das würde ich ja gerne vermeiden, aber nicht auf Kosten der Sicherheit. Privates System hin oder her, da mache ich keine Unterschiede. Nur weil es privat ist, fange ich da keine halben Sachen an. Egal wie unwahrscheinlich da Terz ist :-)

Gruß, incmc
 
Zuletzt bearbeitet:
@asg

Ich bin da halt pingelig und suche nach einer endgültigen sicheren Lösung die aber auch komfortabel ist. Mich würde noch einmal eine Erklärung der MD5 Sache interessierten. Wie funktioniert die Absicherung, dass das auch alles korrekt ist, was da abläuft?

Zudem, wenn ich das dann mal nicht privat brauche, dann habe ich bereits die Lösung :-)
Ich will doch keinem auf den Sack gehen hier. Ich will nur mal alle Möglichkeiten durchdiskutieren.... auf einige Ideen hier bin ich ja noch gar nicht gekommen, ist doch schon mal gut :-)

Gruß, incmc
 
incmc schrieb:
Hier gibt es kein mount_null. Ist ein 4.x System. Evtl. ist das unter 5.x anders!?
Sieht so aus, in CURRENT wurden die mount_* Befehle angepasst.
Code:
% mkdir /tmp/jail
% sudo mount_nullfs -o ro /usr/ports /tmp/jail
% mount | grep ports
coyote:/usr/ports on /usr/ports (nfs)
/usr/ports on /tmp/jail (nullfs, read-only)
% sudo touch /tmp/jail/foo
touch: /tmp/jail/foo: Read-only file system
Keine Ahnung was du mir jetzt demonstrieren willst, was ich nicht weiss und schon gemacht habe :-)
Du hattest behauptet, man koennte ueber NULLFS nicht R/O mounten.

Klasse Idee, veraltete Versionen zu nutzen...
Heute ist nicht dein Tag, oder? Du sollst NICHT die Packages von ftp.freebsd.org nehmen, sondern dir selber aktuelle packages mit 'make package' bauen...
Tja, genau das würde ich ja gerne vermeiden, aber nicht auf Kosten der Sicherheit. Privates System hin oder her, da mache ich keine Unterschiede. Nur weil es privat ist, fange ich da keine halben Sachen an. Egal wie unwahrscheinlich da Terz ist :-)
Also so wie du das momentan laufen hast, hast du viel zu viele Angriffspunkte. Ein komplexes System ist noch lange kein sicheres System (eher im Gegenteil)
 
Zurück
Oben