Code Review auf Sicherheit

Dann mache dafür einen eigenen Thread auf.
Hier geht es um das Code-Review.

Ich tippe drauf, dass du verstanden hast es gäbe einen generellen ssh Zugang zu allen Knoten - das ist nicht der Fall. Andernfalls kann ich mir deine Aussagen nicht erklären.

ssh Zugang per key stellt keine Sicherheitslücke dar.

Zum Thema Nachvollziehbarkeit, wir dokumentieren unsere Firmwareversionen im Wiki und stellen dort die Links zu alles Release Tags zur Verfügung:
https://wiki.freifunk.net/Freifunk_Aachen/Firmware

Die Wiki Seite verlinken wir auch auf unsere Homepage damit sie leichter gefunden wird.

Zum Thema etwas per Autoupdate Unterschieben:
Unser stable Autoupdate verlangt 4 Signaturen (build Server + 3 Personen), das ist mehr als bei manch kommerziellem Produkten erforderlich ist um ein Update auf Geräte in Kundennetzen aufzuspielen.

2 Likes

Es gibt durchaus eine Diskussion um die vom Dropbear (Bestandteil des Standard-Openwrt) genutzten Crypto-Algorithmen.
Und auch bezüglich „SSH deaktiviert wenn kein Passwort gesetzt“ gab in einem der Gluon-Master 2015 mal (kurzzeitig) eine riesige Lücke. War nämlich schlicht nicht der Fall.

Von daher: Ja, es ist sinnvoll, über den Code zu schauen. Und -wie Du erläutert hast- zu erfahren, auf welcher Basis die eigene Community da gebaut hat.

6 Beiträge wurden in ein neues Thema verschoben: Gluon-Dokumentation finden

(Ich habe es ausgelagert, weil es der nächte Versuch war, vom Thema „Codereview“ abzulenken)

dort sieht man zwar was ihr vorgebt gemacht zu haben, aber in der Firmware findet sich ja kein Beweis, dass diese Firmware wirklich mit dem tag des Releases gebaut wurde oder?

Wenn man direkt einen Commit, der einen „annotated tag“ hat baut, dann ist das überhauptnicht mehr beweisbar. dann steht da z.b. nur „Firmware2016.1.5.1 / gluon-v2016.1.5“, ohne commit id und den tag v2016.1.5 könnte ja jeder in seinem privaten repo setzen wenn man nicht auf einem tag baut, dann sieht man wenigstens die kurz-commit-ID am Ende, z.b. v2016.2.1~exp1611111417 / gluon-v2016.2-28-g5ef3d88 ist der commit 5ef3d88
wobei v2016.2 der letzte annotated tag, der vor dem commit in dem repo existierte war.

Schön wäre, wenn in der firmware auf dem Router in einer config datei das benutzte repo und die benutzte commit-id verankert wird. ausserdem noch, welcher commit aus dem site-repo benutzt wurde um zu beuen, dann hätte man alles beisammen um nachzuvollziehen wie die Firmware gebaut wurde.

(Einen „absoluten Beweis“ kann man natürlich eh nie hinbekommen, aber man könnte es ja zumindest so transparent und Nachvollziebar wie möglich machen.)

Stimmen muss dann aber noch lange nicht (wenn man Manipulationen bei der Dokumentation unterstellt). :wink:

Ich denke, wie sollten hier nur über Automatiken reden, die dann funktionieren. Last uns nicht über absichtliche Manipulation reden.

Am besten wäre, wenn automatisch erkennbar ist, wie gebaut wurde.

die idee dahinter ist doch das jemand der nach dem tag xy baut die gleiche FW rausbekommen sollte, das kann aus verschiedenen Gründen scheitern weil gluon/openwrt/linuxtools kaskade, oder allein schon weil man andere Pfade und Nutzer zum bauen benutzt. (die mit in der firmware auftauchen, siehe dmesg |head -n1 )

# sieht man Benutzer@hostname wo gebaut wurde, gcc und timestamp
[    0.000000] Linux version 3.18.44 (fffr@v32412.1blu.de) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r49389) ) #11 Fri Nov 11 20:58:26 CET 2016

aber dein „ultimativer“ beweis wäre eben die prüfsumme der (nach)gebauten FW.
Der rest ist schall und rauch und nachstellbar/manipulierbar

es wäre schön reproduzierbar fw bauen zu können, allein wegen dieser 1. line - dürfte das in der Regel scheitern (gibt bestimmt noch mehr Gründe)

Nachvollziehbare Buildumgebungen sind schon lange dank Docker möglich. Hier würde man also erst ein Dockerimage mit den aktuellen Sourcen bauen, mit denen man dann wiederum die Source baut die das fertige Gluon ergeben. Funktioniert einwandfrei (lange man nicht irgendwo noch einen Timestamp einbackt?) und ist auch ideal um es jedem Zu erlauben den Buildprozess nachzuvollziehen.

@Sheogorath - der witz ist doch das man jemanden NICHT gesammelte source in die hände gibt sondern die liste wo und was und wie , und dann muss da dass gleiche rauskommen! … die Sicherheit mit Docker is fürn Arsch - bequem ist das sicher, aber das auch alles.
Worin liegt der Sinn, hier ist die Black box, drückste aufs VM knöpfchen - kommt Freifunk-FW raus , „genau wie bei mir“ … drückste aufs knöpfchen …
… bei docker könnt ich mich in rage schreiben …
der einzige kleine Vorteil wäre das ein bug/backdoor/unintended behaviour foo, dann in den ausgelieferten docker sources liegt, die aber NIEMAND ankuckt

Docker ist und war nie eine Blackbox. Dockerfiles sind Nachvollziehbar. Zumindest bis zu einem Gewissen grad. Wichtig ist, damit man eben eine IDENTISCHE Buildumgebung schafft. Denn was bringen einem Images, die man auf verschiedenen Maschienen mit unterschiedlichen gcc versionen baut? Nichts, denn ggf. wird dort im Detail etwas anders optimiert und schon kannst du nichts mehr vergleichen. Docker ist hier der einfachste Weg konsistent eine Entwicklungsumgebung für alle bereit zu stellen, ohne jemanden einzuschränken.

Du kannst natürlich auch alles in Vargrant packen und hoffen, aber das hilft dir halt auch nur bedingt.

Tipp: Bevor du dich über Docker in Rage schreibst, bedenke, dass der Fehler nicht in Docker, sondern primär in dessen Benutzungsweise liegt. Hier stellt es übrigens keinen großen Unterschied mehr zu den sonstigen Repos da. Denn auch hier müsste man ja die Sourcen lesen um die Anwendung zu verstehen, was ähnlich wenige tun :wink:

Wie auch immer… Wir wollen ja nicht vom Thema abschweifen :wink: Aber wenn du eine Dockerdebatte führen willst, steht dir meine Inbox offen :wink:

ein feiner unterschied liegt darin, das code, den ich mir erst holen muss, auch von anderen benutzt wird und insofern auch von anderen mit gemaintaint wird - und da schaut dann letztendlich irgendwann eher jemand drauf. Einfach weil der potentiell in vielen Projekten steckt, da kann ich auch extern nicht so einfach Dinge hinzufügen oder tun.
In einem vorbereitetem Docker File ist das schlicht nicht der Fall - und wenn man hier unter dem Thema „Code Review auf Sicherheit“ schreibt ist Docker zwar Nachvollziehbar - aber absolut kein Gewinn.

Wo liegt das Problem? Das ist doch sehr einfach möglich. In dem dockerimage wird das git repository zum bauen geclont. Das sorgt natürlich dafür, dass alle commits NACHVOLLZIEHBAR vorliegen. Mit einem git status kann ich nun schauen ob Dateien manipuliert wurden und ob die Commit-ID stimmt. ist das der Fall… Juhu alles super. Wenn nicht, mhm dann sollte da nochmal wer dran. Den Code selbst kann ich dann eben über GitHub, GitLab, eine Repository verwaltung meiner Wahl machen, bzw. einfach klassisch über die Git-CLI und vi oder emacs.

Docker bildet hier nur die Möglichkeit auch die fertigen Builds gegeneinander vergleichbar zu halten.

Edit: Ich kann beim commit sogar noch weiter gehen… Ich kann sogar schauen die Signatur noch hinhaut, wenn der commit denn signiert ist.

Nur weil Du eine reprozierbare und vertrauenswürdige Buildumgebung hast, bedeutet das doch noch lagne nicht, dass die Qualität des Codes steigt.
Ich sehe auch ehrlich gesagt nicht, wie „reproduzierbare Builds“ überhaupt den Codereview untersützten könnten.

Eventuell bringt man damit natürlich mehr Leute ins Boot, klar. Aber sonst?

Das ist richtig, aber hierum ging es bei der Debatte die ich zuletzt mit fuzzle hat auch nicht. Hierbei ging es darum die resultierenden Images vergleichen zu können. Dafür ist eine solche Buildumgebung die richtige Variante.

Die Codequalität kann nun mit den gängigen Mitteln gesteigert werden. Reviews, Refactoring, noch mehr reviews und nicht zuletzt reviews. Diese macht man basierend auf den Commits und ggf. in einem üblichen Refacotoring-Schritt den man ohnehin macht.

Es muss darum gehen, mehr Leute ins Projekt zu bringen.
Gluon (und auch LEDE) sind viel zu schmal aufgestellt, um der Forderung nach „sicherem und gutem Code“ gerecht zu werden.

Irgendwelches Nitpicking in Richtung „die GITs und Buildumgebungen sind inkonsistent“, meinetwegen auch von @fuzzle (oder @rubo77) bringt uns in diesem Problem nicht weiter.
Was wir hier nun besprechen ist doch eher ein Sicherheitsaudit der jeweiligen Build-Umgebungen und der von den Community genutzten Repositories und Toolchain, würde am eigentlich Gluon/LEDE-Code wenig ändern (hoffentlich…)

na, @rubo77 hat den thread hier ausgegraben, und unwichtig ist das thema an sich ja nicht. Er fing die Diskussion um code und commits und deren Verfügbarkeit an.
… darauf eingehend fing der kleine Exkurs dazu an.

nur um das nochmal in Erinnerung zu rufen - bzw zusammenzufassen.

@adorfer - deinen letzten beitrag versteh ich semantisch nicht, da fehlt nen komma oder irgendwas

Sinnvoll halte ich auch das mehr Menschen sich proaktiv mit Code und Netzwerken auseinander setzen. Das dient der Diversität, verteilt Last auf Schultern. Das erfindet das Rad ggf mehrfach neu und führt zu „evolutionärer“ codequalität(sunterschieden). Survival of the fittest - mit ohne bugs.

Danke, ich hab’s mal editiert.

Wir brauchen in jedem Fall mehr Leute, die testen und sich einbringen. (Und sich auch nicht von den bisweilen rustikalen Umgangsformen auf der Gluon-Mailingliste abschrecken lassen.)

Zusammenfassung:

1.

Ein externer Prüfer sieht, welche firmware auf einem Router installiert ist, dabei sieht er im Moment nur in der internen config files in /lib/gluon/gluon-version, release und site.json. In den ersten beiden steht z.b.

  gluon-version:v2016.1.6
  release:2016.1.6

Die gluon-version anthält die commit ID nur, wenn man nicht genau auf einem annotated tag gebaut hat, dann steht dort sehr genau z.b.

2016.2~exp1611131432 / gluon-v2016.2.1-3-g0f9a1a9

also commit-id 0f9a1a9 genau 3 commits nach dem tag gluon-v2016.2.1

Außerdem enthält die site.json die exact benutzte site config, anhand der könnte ein Prüfer die Firmware genau so nachbauen.

2.

Hier kommt die Docker Diskussion ins spiel: Wenn man mit einem vorgegebenen Docker image gebaut hätte, dann könnte der Prüfer jetzt das selbe Docker Image nehmen und anhand der site.json und dem gluon-commit die Firmware selbst auch bauen und dann die resultierenden images binär vergleichen.

Damit sieht der Prüfer, dass die Firmware wirklich mit diesem Docker image gebaut worden ist.

3.

Das verschiebt aber natürlich den Angriffsvektor auf das Docker-Image, das jetzt überprüft werden müsste auf Hintertüren:

Dazu könnte man eine Anleitung, wie man das Docker Image aus Standard-Paketen erstellt hat veröffentlichen, nachbauen und dann die Docker-Images überprüfen.

Ich hab das wichtigste hier ergänzt: https://wiki.freifunk.net/Sicherheit

Ehrlich gesagt halte ich das für overpowered.

Sinnvoller wäre es wenn die commits der genutzten Grundlagen nachvollziehbar wären. Sonst könnte man auch einfach den build Ordner 7zippen, hashen und zum DL anbieten. Das hätte den selben Effekt wie Docker.

Ergänzung zum Wiki:
Jede Community die den AU nutzt bietet Hash Werte zum überprüfen an. Sie stehen im Manifest.

1 Like