[Gelöst] /var/InternerSpeicher mit noexec mounted

The Brad

Mitglied
Mitglied seit
20 Dez 2007
Beiträge
234
Punkte für Reaktionen
1
Punkte
16
Hallo,

auf meiner 3490 (3490_07.01-freetz-devel-14887) wird der interne Speicher "/var/dev/nand" mit "noexec" gemounted, auf meiner 7490 (7490_07.01-freetz-devel-14887) hingegen nicht.

Kennt jemand die Ursache?

Mir ist nicht bewusst, dass ich abweichende Einstellungen vorgenommen hätte.

Danke+Gruß, Brad
 
Das erklärt alles. Danke für die saubere Antwort.
 
gibts mittlerweile einen Patch für alle NAND-Boxen, so dass /var/media/ftp/ ausführbar gemacht werden kann? Oder kann man das als Option ins Menuconfig einbauen, bzw. ist dort schon vorhanden?

Oder ist /var/media/ftp das selbe wie /var/tmp/flash (/var/flash) ??

Ich weiß, der Thread ist schon etwas älter, aber warum einen neuen öffnen, wenn der alte Thread die Thematik weitestgehend behandelt...
 
Zuletzt bearbeitet:
Das ist schon drin in Freetz ... es fehlt wohl nur der Link für das verwendete Modell, wenn es bei Dir nicht angewendet werden sollte. Ich sehe auch nichts, was die Anwendung dieses Patches von irgendwelchen speziellen Einstellungen abhängig machen würde ... solange er "gefunden" wird, wird er wohl auch genutzt.

Zu finden ist dieser Patch normalerweise unter "patches/devices/07_0x/<model>/220_internal_memory_mount_drop_noexec.patch" - für die 7490 gibt es da ein Verzeichnis, für die 3490 nicht. Ob die 3490 das 7490-Verzeichnis irgendwie "mitbenutzen" sollte oder nicht, weiß ich nicht (und habe jetzt auch keine Lust, dem nachzugehen) - das Einfachste ist ein Symlink für "3490" auf "7490".

Ein Patch(!) für alle Modelle ist leider nicht ohne weiteres realisierbar, da der interne Speicher unterschiedliche Dateisysteme verwendet - solange das also als "diff"-File für das "patch"-Kommando realisiert ist (und nicht per "sed" o.ä. das "noexec" als Option entfernt), muß zumindest pro Dateisystemformat eine solche Datei existieren und für das Modell die passende ausgewählt werden.

Wobei sich das alles ohnehin mit der nächsten FRITZ!OS-Version erledigt hat, weil dann dieses Mounten des internen Speichers an einer anderen Stelle erfolgt ... allerdings kommt AVM einem hier sogar wieder entgegen, weil man das jetzt alles in einer passenden Datei ("/etc/boot.d/ubi_functions" bzw. "/etc/boot.d/yaffs_functions") zusammengefaßt hat und es nicht stört, wenn man einfach beide Dateien ändert, egal welche davon auf dem aktuellen Modell genutzt wird.

Bei den Puma6-Boxen (ich habe bisher nur die 6490 angesehen) ist das dann aber weiterhin anders (aber immer noch komplett "verdreht" ggü. dem bisherigen Stand) - dort gibt es aber auch die Möglichkeit, über eine Whitelist in der Firmware (die m.W. auf dem ATOM-Core bisher nicht existiert, bis in die akt. Laborversion hinein) das Löschen bestimmter Dateien und Verzeichnisse bei "Factory Reset" zu verhindern - daher erfolgt da das ganze Mounten des internen eMMC-Speichers für das NAS (der ja auch noch "ext4" als Format verwendet) wieder in der "/etc/init.d/rc.mount.sh".

Genau solche Änderungen sind es aber auch, die mich sehr gespannt auf die weiteren Entwicklungen bei Freetz (abseits der Toolchain, es geht hier um die gerätespezifischen Anpassungen und den gesamten "mod"-Teil) blicken lassen ... waren verschiedene Patches (insb. die "remove"-Patches) schon seit 06.5x nicht mehr wirklich passend, ändern sich mit 07.2x auch viele andere interne Abläufe, an denen Freetz bisher Änderungen vorgenommen hat bzw. wo sich Freetz einklinkte.

DAS dürfte auch zumindest einer der Gründe sein, warum bisher keiner der beiden Freetz-Forks (weder der "originale" noch "Freetz-NG") irgendwelche Anstalten erkennen läßt, Support für 07.2x (bzw. Labor 07.19) zu implementieren. Mein eigener Fork befaßt sich ja gar nicht erst mit den Teilen, die nach der Toolchain kommen (also "make/mod", verschiedene Patches und der Image-Builder "fwmod") ... von mir ist in dieser Hinsicht also auch für keinen der beiden anderen Forks irgendein Beitrag (an dieser Stelle zumindest) zu erwarten.

Nicht, weil ich es keinem "gönne" oder Freetz für überflüssig halte, sondern weil das einfach außerhalb des Gebietes liegt, was mich selbst an Freetz interessiert und was ich davon brauchen kann (und das ist eben nur die Toolchain bzw. die Zusatzpakete) - meine Theorien, wie Freetz per se besser aufgeteilt werden sollte (Toolchain, Packages, Modifikationen, Image-Builder), habe ich oft genug vorgestellt.
 
Wie wäre es denn, wenn man bisweilen per "sed" die /etc/init.d/S15-filesys insofern beim build patchen würde, dass im teil /dev/proc/nand das noexec entfernt werden würde?!

Was ist denn bei ner 3490 z.b der Unterschied bei den Speicherarten?! wo liegt denn genau das /var/media/ftp .. und der /var/flash ?! .. liegen die auf dem selben Chip !?.. ist es dann grundsätzlich egal, wo genau die Dateien liegen (vorallem wegen Speicherplatz, Schreib-Lese-Zugriffen, etc)...
 
Du hast aber schon gelesen und verstanden, daß Du für die 3490 einfach nur einem Symlink auf dasselbe Verzeichnis wie bei der 7490 anlegen müßtest? Die "genauen" Pfadangaben (bezogen auf die Wurzel eines Freetz-Checkouts) habe ich Dir oben ja aufgeschrieben. Wenn es um ein anderes Modell geht, muß man halt schauen, was dort verwendet wird bzw. wovon dieses Modell eigentlich "abstammt".

Ob Du das dann als Patch für Freetz (also als Pull-Request, wenn es um "Freetz" geht) anlegst oder nicht, ist Deine Sache ... das hat auch mit der "config"-Partition alles nicht wirklich etwas zu tun. Die ist ein komplett anderes Thema (und ist die Partition, die bei der 7490 unter "/var/flash" gemountet wird, aber auch nur, um dort die Inodes für die Char-Devices des TFFS anzulegen) und hat mit dem NAS-Flash nichts zu tun ... ja, die wird sogar bereits ohne "noexec"-Option von AVM gemountet. Das ist auch kein großes Problem, da dort i.d.R. niemand (unbemerkt) schreiben kann und wenn doch, hat der auch ganz andere Möglichkeiten und läßt sich von einem "noexec" nicht beeindrucken.

Wobei es ohnehin recht unvorsichtig ist (um es mal "nett" auszudrücken), wenn man (dauerhaft) die Ausführung von Programmen direkt vom NAS-Speicher zuläßt ... die Gefahr, daß einem da fremder Code untergeschoben werden könnte, ist ungleich höher, als wenn man das mit einem (signierten) SquashFS-Image macht.
 
@PeterPawn es handelt sich ja gottseidank um keine öffentliche Freigabe...

Aber auf welchem Speicher werden denn die Daten geschrieben? Ist /var/tmp/flash im Endeffekt die gleiche Stelle wie /var/media/ftp? oder sind das unterschiedliche "chips" ...

Mir gehts um das Skript-gebastle.. viele Schreibzugriffe, bis das Skript dann mal fertig ist... Ich hoffe, ich konnte mich verständlich ausdrücken...

Wo würdest Du denn genau Skripts hinlegen, die nicht jede Box braucht, aber wenn, dass diese ausführbar aufgerufen weren können?
 
Ich würde die - wie an anderen Stellen ausführlicher erklärt - in ein SquashFS-Image packen und dieses dann wiederum in ein TAR-File, zusammen mit einer "/var/install", packen - ganz so, wie es AVM bei dem "PLUGINV2"-Mechanismus auch macht. Diese "/var/install" mountet dann das SquashFS-Image irgendwo und läßt dabei die "noexec"-Option weg. Das TAR-File ist dann natürlich mit einem privaten Schlüssel signiert, dessen öffentlicher Part auch in der installierten Firmware enthalten ist.

Das Schöne an dieser Lösung ist es, daß damit schon die AVM-Bordmittel in der Lage sind, die Authentizität des TAR-Files zu überprüfen und man diese Datei damit auch an irgendeiner Stelle ablegen kann, wo andere durchaus Zugriff haben dürfen - eine Änderung ist ohne passenden privaten Schlüssel ja nicht möglich.

Für die Entwicklung eigener Skript-Dateien kann man - vor so einem Aufruf - ja auch problemlos noch ein mount -o remount,exec /var/media/ftp ausführen - damit wird die Ausführung von Dateien unter "/var/media/ftp" (aber nicht für einen Mountpoint, der darunter liegt) wieder gestattet ... und zwar auch ohne daß man das (permanent) im FRITZ!OS verankern müßte. Für dieses Kommando muß man auch nicht wissen, welches Dateisystem im NAS verwendet wird ... man braucht nur den aktiven Mountpoint und der ist (bei allen Modellen, die ich (näher) kenne bzw. bei den "Main-Models" von AVM) immer derselbe.

Und nein ... "/var/flash" ist nicht dasselbe wie "/var/media/ftp". Die Unterschiede in den Speichermöglichkeiten bei VR9-Modellen habe ich mal in aller Ausführlichkeit und mit Betrachtung von Vor- und Nachteilen im "modfs"-Thread aufgedröselt - zum größten Teil gilt das (für VR9-Modelle mit SPI- und NAND-Flash) immer noch. Aber solange man nicht jede Sekunde aus einem Skript heraus in den NAS-Flash schreibt (was man tatsächlich vermeiden sollte, aber das gilt praktisch für jeden Flash-Speicher - also EEPROMs), braucht man sich auch für "Entwicklung" nicht sooo viele Gedanken um die Anzahl von Schreibzyklen machen ... schon gar nicht, wenn es nur um das Editieren/Korrigieren von Skript-Dateien geht.
 
Also, ohne jetzt gross in die Images und Installationsskripte einzugreifen -

Ich möchte lediglich ein bis drei kleine Skripte, die entwender vom DNSMasq oder vom Cron augerufen werden auf die Box packen und dann ausführen können...

Und da wäre es doch für mich als "Endbenutzer" einfacher, ich packe die .sh-Dateien auf den /var/media/ftp/eigene_skripte ... und führe in der rc.custom einen "mount -o remount,exec /var/media/ftp(/eigene_skripte)" aus, oder:

ich erstelle einfach ein Verzeichnis unter /var/tmp/flash, packe dort die Skripte rein und führe dann einen "modsave flash" aus.. dann müsste auch alles bei einem Reboot vorhanden und ausführbar sein (wenn man noch den chmod +x setzt)... Oder ??
 
Ja, oder.

Ich wäre sehr verblüfft, wenn der Inhalt von "/var/media/ftp" irgendwie per "modsave flash" gesichert wird.

Aber ich verstehe das ohnehin immer noch nicht so ganz ... wenn es nur um ein paar Skript-Dateien als "Erweiterung" für den "dnsmasq" geht, warum packt man die dann nicht gleich (z.B. über die "fwmod_custom") mit in das SquashFS-Image für das Wurzeldateisystem? Zum Beispiel in einen (neuen) Ordner "/etc/dnsmasq" (oder wie auch immer man das organisieren will)? Da sind sie (a) sicher (weil read-only) und (b) auch immer verfügbar und (c) auch "ausführbar", wenn man die Dateirechte richtig setzt.

Muß man das erst einmal ausführlich testen, was man da an Skript-Dateien hinzufügen will, setzt man im ersten Schritt nur einen Symlink von dem (späteren) Ziel nach "/var/media/ftp/irgendwas" und dann kann man (wieder nur für die Dauer von Entwicklung und Test) natürlich auch das "remount" aus der "rc.custom" machen lassen - nur gehört das danach wieder gelöscht.

Ich verstehe ja noch, daß es ab und an mal "Testbedarf" gibt ... nur muß man sich deshalb ja nicht gleich wieder so in den Fuß schießen, daß diese Wunde nicht mehr verheilen kann. Ich verstehe auch, daß die Verwendung von "fwmod_custom" zum Hinzufügen eigener Erweiterungen etwas unhandlich ist (meine Diskussionen mit @er13 darüber füllen fast Bibliotheken in GitHub) ... aber deshalb muß man ja nicht für eine Handvoll Skript-Dateien gleich wieder sämtliche Errungenschaften von AVM in puncto Security über den Haufen werfen, nur weil man keinen besseren Ort zur Ablage solcher Dateien findet. Wenn die sich tatsächlich noch alle Nase lang ändern, ist das ggf. wieder etwas anderes ... aber wenn solche Skript-Files erst mal "fertig" sind, dürften die auch eher "statisch" hinsichtlich ihres Inhalts sein.
 

Statistik des Forums

Themen
244,696
Beiträge
2,216,705
Mitglieder
371,316
Neuestes Mitglied
realbluethunder
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.