Code Review auf Sicherheit

Technik
29

wie bereits erwähnt, wer Zugang zu dem Router hat, z.b. via Passwort, sshkey kann alles tun, auch und insbesondere ins lokale „Spender“ Netz gelangen.
Zugang kann hier auch physischer Zugang sein - da der Configmode in der Regel ungesichert ist. Dort kann man Verkehr umleiten, mitschneiden und manipulieren.
Physischer Zugang in Kneipen in der Sitzecke, oder außen unterm Dach an der Regenrinne … alles so gesehen. Da hilft so ein FritzBox Gastnetz schonmal ein kleines (!) bisschen.

Ich würde hier statt einer Aufzählung eher einen kurztext zu vertrauen schreiben. und das Sicherheit letztendlich am ehesten mit selbst gebauter Firmware kommt.
man könnte sich mit den vorgelegten site.mk site.conf und modules zur Kontrolle begnügen - wobei man schon nicht sicher sein kann , das dies die zur Firmware gehörigen Pakete sind. Unter anderem kann man im update Prozess, mit heimlichen Zwischenupdate „ungewollte features“ einbauen, die nirgendwo dokumentiert auftauchen.

Wenn man aber eine kurze Aufzählung nimmt, würde ich die offensichtlichsten Sachen machen : Rootpassword, FastD keys/server und mtu abgleichen, ssh-keys anzeigen, autoupdater (ja, an oder aus? wenn aus fehlen sec. updates, wenn an sind nachträgliche sshkeys trivial, wohin zeigt der … wieviele Leute müssen den sign’en, was sind das für Leute.) und ein blick in die Prozesslist UND cronjobs auf verdächtige programme / einstellungen, ein Blick in Liste der installierten Pakete.
… wie du siehst, das eskaliert so schnell das selber bauen einfacher ist - unter der Vorraussetzung das man den genutzten Programmen a sich vertraut (gluon Zeug, Batman, Alfred, batctl, fastd, openwrt, busybox …linuxkernel, libc)
… oder, statt den Aluhut zu weit ins Geischt zu ziehen - man schreibt über vertrauen und glaubt das die site.mk , site.conf und modules den gebauten FW entsprechen. (daher ein unbdingtes minimal must have !)

anderer Punkt zur „sicherheit“ im Layer 2 Netz und Metadaten : meine Lieblingskritik : Rein aus Proof-of-concept hab ich mal ein Skript geschrieben was die layer2 Struktur Ausnutzt und einzelne MAC im ganzen batman netz tracken kann. → https://cccfr.de/git/viisauksena/toolbox/blob/master/tracker_poc.sh
da es jq nutzt kann das nicht auf knoten laufen, wenn man aber auf die Auflösung von Nodename, geo etc. verzichtet, oder das umbaut, kann man damit MAC bequem Tracken durch das Freifunk Netz - und endgeräte melden sich nur zu gerne überall an bekannten Netzen an.

30

Mea culpa – wenn Du meinst, daß das nicht zum Thema gehört.
Aber der netzweit erreichbare SSH-Zugang ist in meinen Augen die Sicherheitslücke Nummer eins, da braucht es dann auch kein Code-Audit mehr, ob es vielleicht möglich wäre, aus dem FASTD-Tunnel auszubrechen. Man muß schon sehr viel Vertrauen in seinen netten Freifunker vor Ort haben, sich so etwas in den Laden zu stellen. Den wenigsten Ladenbesitzern dürfte das aber überhaupt bewußt sein.

31

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

32

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 „Gefällt mir“
33

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.

34

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)

35

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.)

36

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

37

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.

38

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)

39

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.

40

@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

41

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:

42

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.

43

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.

44

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?

45

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.

46

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…)

47

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.

48

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.)