Skip to content

Tor-Browser in der Sandbox betreiben

Das Tor-Projekt stellt seit langem den Tor-Browser zur Verfügung. Die Entwickler investieren viel Zeit und Energie, um den zugrunde liegenden Mozilla Firefox abzusichern und gegen Angriffe auf die Privatsphäre zu schützen. Seit kurzem ist für GNU/Linux wieder ein Baustein hinzugekommen: die Sandbox. Diese gaukelt dem Browser ein eigenes System vor. Sollte jemand den Browser angreifen, so kann er in die Sandbox vordringen, aber eben nicht auf den Rechner.

In der Ankündigung zur Version 6.5a6 wird kurz darauf eingegangen. Wenn ihr die Variante testen wollt, braucht ihr einen Kernel, der Linux Namespaces unterstützt. Standardmäßig machen das alle neueren Versionen. Weiterhin müsst ihr bubblewrap und ggf. Gtk installieren. Die aktuelle Version 0.0.2 der Sandbox greift noch auf ein Adwaita-Verzeichnis zu. Daher benötigt ihr ggf. das Paket gnome-themes-standard-data unter Debian-artigen Systemen. Spätere Versionen haben diese Abhängigkeit nicht mehr.

Nach all der Vorarbeit ladet ihr die Version herunter, prüft die Signatur und entpackt das Archiv. Darin befindet sich eine ausführbare Datei namens sandboxed-tor-browser. Nachdem die gestartet ist, werdet ihr gefragt, welchen Tor-Browser ihr verwenden wollt. Der wird dann heruntergeladen und ein letzter Konfigurationsdialog erscheint. Dort könnt ihr Bridges und weiteres einstellen. Nachdem dies bestätigt ist, startet der Tor-Browser wie gewohnt und kann benutzt werden.

Im Hintergrund nimmt die Tor-Software über Unix-Sockets eine Verbindung zum Browser auf. Früher wurde eine TCP-Verbindung auf der lokalen Maschine verwendet. Durch die Nutzung einfacher Dateien fällt dies nun weg. Die Entwickler überlegen auch, ob es nicht möglich ist, diverse Netzwerkbibliotheken aus dem Browser zu entfernen. Wozu benötigt ein Browser denn solche Sachen? :-)

Solltet ihr Fehler finden, schreibt eine Meldung in den Bugtracker. Das Wiki von Tor hat weitere Informationen zur Sandbox. Viel Spaß beim Testen!

Keysigning bei den Chemnitzer Linux-Tagen 2016

Am 19. und 20. März fanden in Chemnitz wieder die Chemnitzer Linux-Tage statt. Einer alten Tradition folgend organisierte ich das Keysigning. Das heißt, Leute mit einem OpenPGP-Schlüssel können teilnehmen und sich gegenseitig ihre Identität bestätigen. Durch die Prüfung und Signatur wird das Vertrauensnetz (Web of Trust) gestärkt.

In den letzten Jahren stellten wir uns dazu in einer Reihe auf. Die erste Person bewegte sich dann zur zweiten und anschließend zur dritten, vierten usw. Nachdem die erste Person vorbei war, fing die zweite an. So sah das ungefähr aus:

Startaufstellung:

1 2 3 4 5 6 7 8 9 10

Erste Person startet:

2 3 4 5 6 7 8 9 10
1

Zweite Person startet:

3 4 5 6 7 8 9 10
2 1

Nach einer Weile startet die sechste Person:

7 8 9 10 1
6 5 4 3 2

Das heißt, die erste Person reiht sich wieder ans das Ende ein. Eine Reihe zeigt jeweils den Ausweis und die andere Reihe vergleicht.

Bei dem Verfahren ist nun der Nachteil, dass anfangs sehr viele Leute im Leerlauf sind. Sie müssen warten, bis die erste Person endlich bei denen angekommen ist. Um dies ein wenig zu beschleunigen, haben wir die Reihe dieses Jahr direkt gefaltet. Nach der Sortierung in eine Reihe stellten sich alle gegenüber auf:

1 2 3 4 5
10 9 8 7 6

Die Idee war, dass wieder eine Reihe prüft und die andere den Ausweis zeigt. Leider habe ich das wohl nicht genau genug erklärt und es wurde parallel von beiden Seiten gemacht. Als die Reihe nun zur Hälfte abgearbeitet war, kamen die Teilnehmer bei ursprünglichen Gegenüber wieder an und nahmen an, alle erwischt zu haben. Dies ist aber nicht der Fall:

2 3 4 5 6
1 10 9 8 7

Die Aufstellung oben ist nach dem ersten Wechsel. In der initialen Aufstellung verglich beispielsweise Teilnehmer 3 mit Teilnehmer 8 die Daten. In obigem Schritt vergleicht 3 mit 10 usw. Nach fünf Schritten stehen sich 3 und 8 wieder gegenüber. Teilnehmer 3 hat dann die Identität der Teilnehmer 8, 10, 2, 4 und 6 verifiziert. Was ist mit 1, 5, 7 und 9? Diese fehlen offensichtlich. Es kostete mich einige Mühe die Teilnehmer zu überzeugen, dass der Lauf noch nicht beendet ist. Hoffentlich kann ich alle dann im nächsten Jahr auf diese Seite verweisen und die Überzeugungsarbeit wird einfacher. :-)

Wer sich für den Stand des Web of Trust interessiert:

Web of Trust @ CLT 16

Spam-3.7688

In meiner Inbox fand ich heute dieses nette Stück Spam:

<html>                                                                                                             
<head><title>401 Authorization Required</title></head>                                                             
<body bgcolor=“white”>                                                                                             
<center><h1>401 Authorization Required</h1></center>                                                               
<hr><center>nginx/1.2.1</center>                                                                                   
</body>                                                                                                            
</html>

 

Wenn man das HTML interpretiert, kommt dann sowas raus:

401 Authorization Required


nginx/1.2.1

Ich verstehe nicht, warum man sowas als Spam in die Welt hinaus schickt. Die Nachricht wurde von einer IP-Adresse aus Südafrika eingeliefert. Neben der From:-Adresse hat der Spammer keine weiteren Header-Zeilen übermittelt. Vielleicht wollte derjenige einfach, dass ich das blogge. :-)

Wie gut erkennen Menschen Gesichter?

Wie gut schätzt ihr euch in der Gesichtserkennung ein? Würdet ihr beliebige fremde Personen wieder erkennen? Ich vermute die meisten denken, dass sie gut in der Erkennung von Gesichtern sind.

Bruce Schneier verweist auf eine Studie über Grenzbeamte. Diese sollten ein Foto mit einer Person abgleichen. In etwa 15 % der Fälle dachten die Grenzer, dass die Person vor ihnen dem Foto entspricht, obwohl beide verschieden waren.

Das entspricht der Diskussion aus dem Datenkanal zur Gesichtserkennung. Unser Gesprächspartner Jürgen Kaufmann erklärte uns, dass wir gut im Erkennen bekannter Gesichter und sehr schlecht im Erkennen fremder Gesichter sind. Das geht so weit, dass sogar gleiche Gesichter auf demselben Blatt aufgenommen mit unterschiedlichen Kameras als verschieden wahrgenommen werden.

Platzprobleme beim Update

Ich stelle gerade wieder fest, dass ich das Linux wegen seiner Flexibilität mag. Gerade eben war ich dabei, die Software auf dem Rechner auf den neuesten Stand zu bringen. Unterwegs meinte apt-get, dass die Festplatte voll ist. Debian lädt alle Updates zuerst in das Verzeichnis /var/cache/apt/archives. Der Update umfasste mehr als zwei Gigabyte und im Verzeichnis waren weniger als ein Gigabyte frei. Tja, was tun?

In meinem Home-Verzeichnis gab es genügend Platz. Also habe ich mittels dd if=/dev/zero of=vcaa.img bs=$((3024*1024*1024)) eine drei Gigabyte große Datei angelegt. Diese wurde dann durch mke2fs -j vcaa.img zu einem ext3-Dateisystem und mit mount -o loop -t ext3 vcaa.img /var/cache/apt/archives habe ich die Datei ins Dateisystem eingebunden.

Nun werden die Dateien heruntergeladen, installiert und wenn alles abgeschlossen ist, lösche ich die Datei wieder und der Rechner ist aktualisiert. :-) Ich frage mich, wie man sowas unter Windows anstellt.

In Zukunft sollte ich darauf achten, entweder schneller Updates auf dem Rechner durchzuführen oder mal über die Struktur des Dateisystems nachzudenken.

19. Datenkanal über Buffer Overflows

Woher kommen eigentlich Viren, Würmer und andere Schadsoftware? Über welchen Weg brechen Angreifer in Computersysteme ein? In vielen Fällen heißt die Antwort »Buffer Overflow« oder Pufferüberlauf. Jörg und ich sind der Frage nachgegangen, was so ein Buffer Overflow eigentlich ist. Wir versuchen anhand einer Analogie mit Kisten und deren Inhalten das Wesen des Überlaufs zu erklären. Anschließend bieten wir einige Lösungen für das Problem an. Neugierig geworden? Dann hört mal in den Datenkanal 19 rein:

Durch Bitlove könnt ihr beide Dateien über BitTorrent herunterladen.

Viel Spass beim Anhören und, falls ihr mögt, könnt ihr flattrn. :-)

tweetbackcheckcronjob