Buildroot > gehärtetes, minimales Linux als Firmware?
Hallo Linux-Benutzer,
ich möchte eine eigens entwickelte Software auf einem Raspberry PI für Systemhäuser anbieten. Die jeweligen Systemhäuser wären bei Gelingen entsprechend meine Kunden, die diese installierten RPIs bei ihren Kunden verbauen und aus der Ferne administrieren würden. Ich würde meine Software vorinstalliert auf einem Image zum Download anbieten, das die Systemhäuser nachher auf SD-Karten flashen können.
In dem Zuge habe ich mich mit Buildroot beschäftigt, da ich eine Art unabhänge Firmware anbieten will. Damit will ich umgehen, dass irgendjemand in dieser Kette an einen Linux Distibutor und dessen Updates gekoppelt wäre oder mehr Software auf dem System vorhanden wäre, als notig. Dieses Grundsystem wird nur alles Notwendige enthalten und muss nachher gehärtet werden. Nach jetzigem Plan wäre nur der TCP Port 80 durch einen Nginx geöffnet. Ich würde auch keine Shell, kein SSH oder Sonstiges starten. Nun die Fragen...
- Kann ich mich beim Härten des Systems auf den Nginx beschränken, wenn das der einzig laufende Service ist, und jede Kommunikation theoretisch da hindurch muss?
- Ich würde Updates für meine Software anbieten, die auf diesem Grundsystem läuft und erwarten, dass meine Kunden bei etwaigen Problemen mit dem Nginx entprechend ein neues Image ziehen müssen. Ist das okay?
Dazu gesagt; die eigentliche Software kann aus meinen Quellen immer neu eingerichtet werden. Die RPI Clients sollten somit jederzeit mit einem neuen Grundsystem geflasht werden können, ohne dass das eine großartige Neueinrichtung zur Folge hätte. Mein Problem ist eben, dass ich für das minimale Linux unten drunter, keine Paketverwaltung mit anbieten möchte. Ähnlich wie bei so einem TP-Link Router, den man notfalls selbst flashen muss.
Danke.
1 Antwort
1. Kommt drauf an, aber wenns wirklich gehärter sein soll nein.
Jede Software hat Fehler, Sinn des härtens ist es das Ausbreiten eines Exploits zu erschweren nicht diesen gänzlich zu verhindern.
Ein gehärteter Kernel, SELinux usw tragen dazu bei, dass ein Exploit im Nginx nicht zu einem Backdoor aufgeweitet werden kann.
2. Prinzipiell ja.
Zu Buildroot ist das nicht das selbe wie Härten, es ist eben nur ein System mit welchem du ein Image erstellen kannst, ob du nun aber Buildroot, Yocto oder ein LFS verwendest um das System aufzubauen ist egal und es ist dadurch nicht automatisch gehärtet.
Du musst natürlich immer dahinter bleiben wenn du selbst Systemupdates anbietest
Root Login ist für die Sicherheit aber relativ schlecht. Das System sollte gar kein Root für eine User erlauben.
Alles raus ist ein erster Ansatz aber nicht das Ende. So Dinge wie Bufferoverflow Mitigation, Prozess Isolation usw. Tragen auch dazu bei.
Wenn der Angreifer nicht aus dem Nginx raus kommt kann er auch nicht mehr machen.
Ich meine, dass ich den Root ausstelle. Also weder Prompt, noch Login.
[ ] Enable root login with password
│ /bin/sh (busybox' default shell) --->
│ [ ] Run a getty (login prompt) after boot --->
Der Nginx läuft unter www-data und darf erstmal gar nichts. In Buildroot gibt es ein Taxtfile mit einer Tabelle, in der ich jede Dateiberechtigung für den Nginx einzeln einstelle. Also der darf auch nicht im Quellcode vom Webroot schreiben.
"So Dinge wie Bufferoverflow Mitigation, Prozess Isolation usw. Tragen auch dazu bei." -> Da werde ich mich jetzt reinlesen. Danke für den Hinweis und die Ermutigung :)
Habe nochmal über "Root Login ist für die Sicherheit aber relativ schlecht. Das System sollte gar kein Root für eine User erlauben." nachgedacht. Du meinst, dass "nicht einloggen dürfen" den Root nicht gänzlich sperrt? Also Sudo oder sowas gibt es natürlich auch nicht. Bis auf die zwei obigen Checkboxen habe ich innerhalb Buildroot nichts gefunden. Ich frage noch mal nach, nicht dass es noch andere Möglichkeiten gibt Root-Rechte zu erlangen?
Ich meine damit nur dass es nicht möglich sein sollte für nginx oder von außen zu root zu werden.
Dann bleibt nur Privileg Escalation übrig und da hilft eigentlich SELinux bereits weiter.
Für nginx sollte es zudem keine Möglichkeit geben Shellscripte von seinem user aus zu starten.
Okay, danke. Das Image + Overlay FS usw., das mir ermöglicht das Webfrontend des PIs zu benutzen ist fertig. Ich würde dann noch entsprechend die Console und den das Root Login ausmachen.
Und verstehe; ich werde mich jetzt damit beschäftigen, wie ich den Kernel und dessen Features am besten einstelle. Das Motto ist, dass alles raus muss, was man nicht braucht.