Ich habe mal ein neues "modscript" für den Boot-Manager eingecheckt (und auch das "modfs.tgz"-File entsprechend aktualisiert) - dabei den Namen auf "gui_boot_manager_v0.4" geändert.
Wer also mit einer alten "custom_modscripts"-Datei arbeitet, muß da ggf. Hand anlegen, wenn er die neue Datei ein- oder ausschließen will. Da die neue Version einiges anders macht als die vorhergehende und ich nicht alle möglichen Zweige selbst testen konnte, weil ich nicht alle unterstützten Modelle besitze, bleibt die v0.3 erst einmal noch dabei ... aber ich wäre natürlich daran interessiert, für die v0.4 auch Feedback zu kriegen und daß die beiden Versionen nur alternativ verwendet werden dürfen, ist sicherlich auch klar.
Die Änderungen grob beschrieben:
- getestet auf 7580, sollte auf 7560 auch funktionieren - hier gibt es den yaffs2-Wrapper ja nicht, damit muß man das alternative System anders mounten für die Tests
- anstatt jetzt bei einem Mount-Versuch zu scheitern, wenn in den alternativen Partitionen gar kein System installiert ist, wird zuerst versucht festzustellen, ob in den ersten 16 Byte der fraglichen Kernel-Partition irgendwelche Daten stehen; dabei werden Bytes aus ausschließlich 0- bzw. 1-Bits (also 0x00 bzw. 0xFF) als gelöschter Flash-Speicher angesehen
- tritt so ein Fall eines "missing kernel" ein, ist die Umschaltung auf die alternativen Partitionen im GUI nicht möglich (der Radio-Button wird deaktiviert)
- ich habe versucht, die Erkennung des Datums der letzten Änderung für ein System zu verbessern
- der Fall der 7412 mit dem fehlenden "blkid"-Kommando (das gilt vermutlich für alle Modelle ohne NAS) sollte jetzt auch funktionieren - bei fehlendem "blkid" und vorhandenem "/wrapper"-Verzeichnis wird zuerst "yaffs2" als Dateisystem angenommen und nicht mehr "squashfs"
@eisbaerin:
Diese Version sollte die Probleme mit beiden Boxen bei Dir ausräumen ... wenn nicht, muß ich nachbessern (dann brauche ich wieder die Ausgabe von "sh -x guibootmanager html_display", um da etwas zu sehen).
-@Fireball3:
Du müßtest "/etc/hotplug/udev-mount-sd" anfassen und dort die "noexec"-Optionen entfernen (für jeden FS-Typ gibt es getrennte Mount-Kommandos). Generell möchte ich das nicht "anbieten", ich bin ja froh, daß AVM dieses endlich eingebaut hat und ich hoffe sogar im Gegenteil, daß AVM es auch für den internen NAS-Flash genauso noch nachzieht (dort kann man mit dem FTP-Service auch "x"-Flags setzen) wie für den WebDAV-Speicher (wo ebenfalls der volle Umfang der Flags emuliert wird).
Nach meiner Meinung sollte man das auch nicht für alle Volumes wieder entfernen ... wenn schon, dann max. selektiv für ein bestimmtes bzw. ich plädiere an dieser Stelle eher dafür, daß man solche Volumes mit einem signierten "Image-File" als einer Art "Autostart-Skript" versieht und dann in diesem Skript entsprechende Vorsichtsmaßnahmen trifft, daß da keine unerwünschten Programme auf dem Volume sind bzw. von dort aufgerufen werden.
So etwas kann man sogar mit minimalem Aufwand beim Ändern erreichen, indem man in der bereits erwähnten Datei "/etc/hotplug/udev-mount-sd" die Zeile "TR069START=/bin/tr069starter" gegen eine austauscht, wo man ein eigenes Shell-Skript eingetragen hat. Dieses Skript wird dann für jedes neu gemountete Volume aufgerufen (den Aufruf von "tr069starter" sollte man ohnehin entfernen, aber aus anderen Gründen) und kriegt als Parameter den Mount-Namen (das ist der Pfad ohne das Basisverzeichnis) übergeben. Dort kann man dann einfach mit fünf Zeilen in einem Skript (eine würde auch reichen ;-)):
Code:
#! /bin/sh
autoscript=yf_autorun.image
basedir=/var/media/ftp
[ -f $basedir/$1/$autoscript ] || exit
tr069fwupdate packet file://$basedir/$1/$autoscript
dafür sorgen, daß ein vorhandenes, "ordentlich signiertes" Archiv mit dem Namen "yf_autorun.image" (der natürlich auch angepaßt werden kann, wenn man will) von einer AVM-Komponente geprüft und ausgepackt wird - sogar die dort enthaltene "./var/install"-Datei wird von "tr069fwupdate" aufgerufen. Damit bringt man einfach dort seine gewünschten Kommandos unter - das kann notfalls sogar das "remount" für ein ganzes Volume sein, wenn man es wirklich so haben will.
Man muß nur berücksichtigen, daß (abweichend von den alten "Pseudo-Images") die Daten nicht in "/var" entpackt wurden (also relativ zum Wurzelverzeichnis), sondern in "/var/packet/var". Solange man aber mit relativen Pfaden arbeitet, kann das einem auch egal sein - das ist i.d.R. ohnehin der bessere Weg.
Gegebenenfalls muß man noch ein paar Vorsichtsmaßnahmen treffen, wenn man mehrere Volumes mit solchen Images hat und wenn man das ebenfalls sauber behandeln will ... ein zweiter paralleler Aufruf von "tr069fwupdate" würde zum Chaos führen, da es nur ein einziges Verzeichnis "/var/packet" zu jedem beliebigen Zeitpunkt geben kann. Aber theoretisch sichert das (zur Zeit jedenfalls) bereits AVM beim Mounten ab, daß da alles schön der Reihe nach funktioniert. Je nachdem, was man in der eigenen "install"-Datei so veranstalten will, muß man ggf. noch die Stelle für den Aufruf in der "udev-mount-sd" anpassen ... das (ehemalige) "tr069starter" liegt zwischen FTP- und Samba-Service bei der Konfiguration und auch vor allen Aktionen bzgl. Telefonie-Dateien (AB-Nachrichten, Faxe) und Mediaserver bzw. NAS-Funktionen (z.B. Index einbinden).
Um so eine Image-Datei sauber zu signieren, muß man natürlich zuvor den passenden öffentlichen Schlüssel (den eigenen oder den einer vertrauenswürdigen dritten Instanz, von der man solche "Pakete" akzeptieren will) in die Firmware einbauen lassen (es gehen auch mehrere, nach derzeitigem Stand sind sechs zusätzliche Schlüssel möglich, während AVM selbst 3-4 hinterlegt), das geht wieder mit "copy_binaries" absolut easy.
Damit hat man dann die Prüfung der Gültigkeit der Daten und Programme auf so einem USB-Stick schon mal auf den Stick selbst ausgelagert (die "./var/install" im dortigen Autorun-Image ist jetzt dafür verantwortlich) und hat bis zu diesem Punkt noch nicht eine einzige zusätzliche Sicherheitslücke eingebaut. Solange man zusätzliche Programme gleich mit in das signierte Archiv packt (und damit die Signatur auch diese validiert), ist das schon alles, was man machen muß - für Programme, die aus dem "tmpfs" laufen können, weil der vorhandene Hauptspeicher dafür ausreicht, ist das mehr als genug (man sollte sie nur an eine andere Stelle als "/var/unpack" verschieben).
Will man wirklich zusätzliche Programme vom USB-Volume direkt ausführen, muß man eben deren SHA256-Summen in einer Datei abspeichern und diese Datei mit in das Image-File aufnehmen (wo sie wieder von der Signatur geschützt wird). Dann kann man beim Mounten (eben wieder in der ./var/install) die SHA256-Summen prüfen lassen (das geht ja mit "sha256sum -c" recht elegant, auch wenn das m.W. bei AVM nicht direkt dabei ist - selbst die BusyBox mit diesem Applet kann man ja aber mit in das signierte Image packen). Dann kann man zumindest sicher sein, daß kein Unbefugter die Dateien auf dem Stick ausgetauscht hat oder einfach ein "allgemeines" Image von einem anderen Stick auf einen eigenen kopiert hat - das ist immer noch relativ sicher, auch gegen "Angriffe" mit einem eigenen USB-Stick durch Angestellte oder Familienmitglieder mit physikalischem Zugang zu so einer FRITZ!Box.
Dieser simple "autorun"-Mechanismus ist auch leicht in ein "modscript" verpackt (werde ich auch spätestens in der nächsten "modfs"-Version mal machen (das wird eine 0.5.0), so etwas gibt es bei mir schon länger) - es braucht halt dann etwas "Infrastruktur" (angefangen bei einem privaten Schlüssel), um die Volumes passend zu präparieren und ohne die rechtzeitige Aufnahme der öffentlichen Schlüssel nutzt das auch alles nichts. Aber das weiß man ja vorher ... und der Gewinn an Sicherheit (ggü.
Freetz mit "autorun.sh") und Flexibilität (ggü. Freetz ohne "autorun.sh" und ggü. der AVM-Firmware) ist es wert (zumindest mir).
- - - Aktualisiert - - -
Ach so ... noch etwas zur 7580/7560 und dem "Boot-Manager": Auch der kann natürlich nichts daran ändern, daß das Branding aus dem "device-tree" (und damit dem finalisierten Bootloader) die Angabe in "/proc/sys/urlader/environment" überlagert. Es sieht jedenfalls so aus, daß eine Änderung von "firmware_version" zwar ins TFFS geschrieben wird, diese aber beim nächsten Start wieder mit der Angabe aus dem OF-FDT überstimmt wird.
Da ich noch keine Möglichkeit kenne, das voraussichtliche Verhalten des Bootloaders an dieser Stelle "vorherzusagen", habe ich die Änderung des Brandings auch bei der 7580/7560 nicht deaktiviert (die könnte man z.Zt. ja noch anhand des Prozessors eindeutig identifizieren) ... aber der Boot-Manager kann da natürlich auch nichts machen und so bleiben entsprechende Einstellungen für den nächsten Start dann auch wirkungslos.
Für das "Debranden" einer solchen 1&1-Box (derzeit nur für die 7580/7560 bekannt als Problem, so weit ich das verfolgt habe) bleibt damit nur noch der Weg, das direkt in der "/etc/init.d/rc.conf" passend zu regeln und dort den Wert für "OEM" einfach noch einmal fix auf AVM zu setzen, nachdem die Daten aus dem Environment gelesen wurden und auch den neuen Wert einfach noch einmal zu schreiben, damit spätere Leseversuche von dieser Stelle dann wieder das erwartete Ergebnis erbringen. Die Alternative ist es, da direkt am Beginn in der S01-head mit zu verankern, daß ein gewünschter Wert den "festen" bei jedem Start ersetzt. Bleibt dann die Frage, woher dieser gewünschte Wert kommen soll, wenn man das dynamisch machen will (weil man irgendwann mal eine deutsche und eine internationale Version gleichzeitig installiert haben will - um nur mal ein denkbares Beispiel zu nennen) - ansonsten kann man das natürlich auch wieder fest verdrahten.