Diskussion:Entwicklung
Aus NAS-4220
Was mich schon länger wundert, ist die Frage, ob die init-Datei nicht ein offenes "Einfallstor" für Viren ist (da man tief in den Startskripten eigene Skripte unterjubeln kann) und was man dagegen machen könnte. Ich könnte mir vorstellen, dass man z. B. zumindest das App-Verzeichnis in Samba mit einem Passwortschutz versieht...
--NasJoe 12:35, 8. Jan. 2008 (CET)
Gute Idee, das sollten wir dokumentieren in einem neuen Hauptmenüpunkt "Sicherheit" (oder so). Übrigens echt gut, Deine Beiträge, man merkt, dass Du Dich auskennst!
PS für die Mitleser: 770 steht für "read, write, execute"-Rechte für den owner und group, 777 zusätzlich auch für alle anderen. Zum Lernen der Codes ist die Selfhtml-chmod-Seite wirklich hilfreich...
--NasJoe 23:19, 8. Jan. 2008 (CET)
Danke NasJoe :-) eigendlich hab ich 0 Ahnung. Deshalb hab ich grad festgestellt, dass wenn man so einfach das Verzeichnis zu macht das Webmenü nicht mehr erreichbar ist. Also alles zurück und doch ein wenig differenzierter rangegangen :-) Die Idee mit der Rubrik Sicherheit ist sehr gut !! Meine Empfehlung für die Rechtevergabe für Verzeichnisse und der init:
./ssh-server: 775
./ssh-server/webroot: 775
./ssh-server/webroot/nav: 775
./ssh-server/webroot/nav/sshserver: 775
./ssh-server/webroot/html: 775
./ssh-server/webroot/html/sshserver: 775
./ssh-server/webroot/cgi: 775
./ssh-server/webroot/cgi/sshserver: 775
./ssh-server/sausalito: 770
./ssh-server/sausalito/handlers: 770
./ssh-server/sausalito/handlers/base: 770
./ssh-server/sausalito/handlers/base/sshserver: 770
./ssh-server/sausalito/conf: 770
./ssh-server/sausalito/conf/base: 770
./ssh-server/sausalito/conf/base/sshserver: 770
./ssh-server/sausalito/constructor: 770
./ssh-server/sausalito/schemas: 770
./ssh-server/sausalito/schemas/base: 770
./ssh-server/sausalito/schemas/base/sshserver: 770
./ssh-server/data: 770
./ssh-server/bin: 770
init 770
770 bedeutet Owner und Group darf zugreifen und verändern, alle anderen dürfen nix
775 bedeutet Owner und Group darf zugreifen und verändern, alle anderen dürfen nur anschaun (webserver zählt dazu)
-rwxrwxr-x 1 admin root 14 Sep 12 13:11 VERSION
-rwxrwx--- 1 admin root 2.1k Jan 6 21:34 init
-rwxrwxr-x 1 admin root 17.6k Aug 15 21:44 COPYING
drwxrwxr-x 5 admin root 4.0k Jan 4 03:26 webroot
drwxrwx--- 6 admin root 4.0k Jan 4 03:26 sausalito
drwxrwx--- 2 admin root 4.0k Jan 4 03:27 data
drwxrwx--- 2 admin root 4.0k Jan 4 03:26 bin
Habs probiert... nach nem Neustart werden die Rechte übernommen und das Webmenü funktioniert auch :-)
--The Chemist 11:48, 9. Jan. 2008 (CET)
Ich sehe noch das Problem, dass man zwar zuverlässige Anwendungen installieren können muss, die mit dem INIT-Skript unter dem Application-Dir eigene Veränderungen vornehmen, aber kein "Virus" sich z. B. über das Application/new_software-Verzeichnis einschmuggeln darf - tgz-Dateien darin werden nämlich von der Firmware beim Neustart automatisch ausgepackt ins Applikation-Dir und ausgeführt! Sinnvoll wäre, das ganze Application-Dir auf Linux-Ebene mit chmod 770 zu schützen, Anwendungen könnten dann aber wahrscheinlich nicht mehr per Samba, sondern nur noch mit SSH installiert werden (dafür kann man ruhiger schlafen ;-)
--NasJoe 22:44, 9. Jan. 2008 (CET)
Beim ssh-Server mag das noch gehn. aber bei anderen Programmen die vielleicht noch folgen werden, müssen die rechte von vornherein unter dem gesichtspunkt der sicherheit vergeben werden. denn nicht alle werden es sich zutraun direkt auf der box rechte zu vergeben auch wenns einfach ist :-) Ich schau morgen das ich die ersten sicherheitshinweise für den ssh-server eintrage. vielleicht bau ich noch ein script was die rechte vergibt. Webserver und streamripper wollt ich nicht installieren....mal schaun.
So alles mal wieder für die Katz.... die Rechte werden nach nem neustart überschrieben. auch unser init trick funktioniert nicht.....
--The Chemist 23:15, 9. Jan. 2008 (CET)
Schade, dass es nicht geklappt hat. Vielleicht hilft ein anderer Ansatz (nicht das OS schützen, sondern das APP-Verzeichnis): Ich denke, man sollte eine einfache Applikation erstellen, die sich ins Admin-Menü einhängt und eine Checkbox anbietet: "Write-Protect Application Folder". Dann hat es der Admin über die GUI selbst in der Hand, den App-Folder vor der Installation von weiteren Apps freizuschalten. Ansonsten ist man hier vor Viren geschützt... Das CGI-Skript müsste einfach alle Dateien zum Owner ROOT zuordnen (oder ADMIN?) und chmod passend ausführen...
--NasJoe 21:27, 10. Jan. 2008 (CET)
Kompilieren gegen Libs der NAS4220-B?
Weiß jemand, wie man die vorhandenen Bibliotheken der NAS zum Kompilieren eigener C-Sourcen verwendet und welche Bibliotheken man üblicherweise braucht (Pfad+Name)? Ich will nicht das komplette Linux neu durchkompilieren ;-) Mein Ziel ist, das nbench-Programm (C-Sourcen) zum Laufen zu bringen, um CPU-Benchmarks durchzuführen...
--NasJoe 23:32, 8. Jan. 2008 (CET)
Kennt ihr diese beisen Links schon? Das funktioniert auf dem IB-NAS4220-B genauso. Die dazugehörige source.rar kann man auch bei raidsonic downloaden. http://www.nas-2000.org/mwiki/index.php?title=Compile_Programs_on_the_NAS http://www.nas-2000.org/mwiki/index.php?title=Compile_Programs_on_your_PC_%28cross_compiling%29
--Daddel80 22:45, 10. Jan. 2008 (CET)
