@koy:
Ich schreibe absichtlich nichts weiter zu darkstat hier ... der eine Absatz in #14 war die berühmte Ausnahme von der Regel. Wenn wirklich der darkstat-Teil gelöscht wird, nehme ich aber den Absatz auch raus ... andererseits ist das hier tatsächlich "nur" als Diskussion gedacht und der Thread, den ich gerne sauberhalten würde (und auch nachpflege, wenn sich aus diesem hier Erkenntnisse ergeben), ist der andere mit den Beschreibungen - damit kann jemand, der neu in der Thematik ist, sich auf diesen Thread beschränken und muß nicht jede Menge andere Beiträge lesen, bevor er es anwenden kann.
@coolrunning:
Du brauchst Dir ja nur ein eigenes passendes SquashFS-File zusammenstellen, dabei kannst Du auch gleich die passenden Binärdateien für die Zusatzsoftware dort mit aufnehmen. Darin dann noch die Datei "etc/init.d/rc.custom" so abändern, daß sie auch die Zusatzsoftware startet und dieses SquashFS-Image anstelle von "filesystem.image" in das tar-Archiv einbauen - oder natürlich gleich die Datei "filesystem_custom.squashfs" unterhalb von /wrapper gegen die eigene austauschen. Das ist über ShellInABox aber nicht ganz so einfach, weil die alte Datei dabei natürlich in Benutzung ist, da braucht man also noch ein ziemlich ausgefeiltes Skript, das zeitverzögert den ShellInABox-Service beendet, das "dismount" ausführt und dann erst die Datei unterhalb von /wrapper ersetzt.
Von der (dauerhaften) Benutzung von /var/media/ftp und darunter liegenden Verzeichnissen für den Start von Software auf der FRITZ!Box kann man unter Sicherheitsaspekten auch nur abraten, weil diese Verzeichnisse eben über verschiedene NAS-Dienste zugänglich sind und wenn es einem Angreifer gelingt, dort abgelegte Software gegen eigene auszutauschen, ist der schneller in der FRITZ!Box, als einem lieb ist.
Zum Testen ist das sicherlich ein gangbarer Weg ... aber wer dort (ohne Not) komplette Pakete ablegt und regulär von dort startet, der sollte schon noch einige zusätzliche Vorkehrungen zum Zugriffsschutz auf diese Verzeichnisse treffen und das meint nicht nur die Verwendung von "Benutzerberechtigungen" für den Zugriff auf diese Verzeichnisse - auch diese Verwaltung könnte ja einmal löcherig sein, sondern tatsächlich das Abschalten von Diensten.
Eine Lösung dort (die gegen extern "eingeschleuste" Änderungen hilft) wäre es, die eigenen Pakete mit boxspezifischen Daten für den Key zu verschlüsseln und sie dann vor ihrer Benutzung ins tmpfs zu kopieren und dabei zu entschlüsseln. Das vermeidet zumindest generische Angriffe durch den Austausch eines kompletten Pakets (über NAS-Zugriffe), weil das genau für die vorliegende Box verschlüsselt werden müßte. Leider baut AVM trotz der Benutzung von OpenSSL in Bibliotheksform nur zwei spezialisierte CLI-Programme in die eigene Firmware ein (eines zum Generieren eines Schlüsselpaars und eines zum Signieren als "self-signed") und man muß ein/das generische(s) CLI-Programm aus dem OpenSSL-Paket erst einmal selbst nachrüsten.
EDIT: Das bringt mich dann auch gleich noch darauf, daß ich im anderen Thread besser noch den Hinweis aufnehme, daß bei einer zweimaligen Anwendung desselben Prinzips auf einer Box ohne zwischenzeitliche Deinstallation das Austauschen der Image-Datei selten von Erfolg gekrönt sein wird, weil die gemountete Image-Datei normalerweise nicht überschrieben werden kann und man dann entweder ein "umount" machen muß (dann darf da auch kein Dienst mehr laufen, damit das klappt) oder mit Umbenennen der alten Datei und Speichern der neuen dann den doppelten Platzbedarf hat und sich auch überlegen sollte, wie man das alte (nun ja umbenannte) Image irgendwann wieder los wird.
