Projects

Book Launch : The Field Guide to Hacking

🇭🇰 · DimSumLabs · NP

Book by Michelle Poon from Dim Sum Labs In The Field Guide to Hacking , the practises and protocols of hacking is defined by notions of peer production, self-organised communities, and the intellectual exercise of exploring anything beyond its intended purpose. Demonstrated by way of Dim Sum Labs hackerspace and its surrounding community, this collection of snapshots is of the work generated from an organic nebula, culled from an overarching theme of exploration, curiosity, and output. This book reveals a range of techniques of both physical and digital, documented as project case studies. It also features contributions by researches, artists, and scientists from prominent institutions to offer their perspectives on what it means to hack. Altogether, a manual to overcome the limitations of traditional methods of production. Contributors: Eduardo Alarcón, Mitch Altman, Mathis Antony, Luca Bertini, Sébastien Bourdeauducq, Stephan Brüggemann, Hamish Coleman, Sarah Daher, Scott Edmunds, Sarah Fox, Cesar Jung-Harada, Adam Höse, Daniel Howe, Wilhelm Klein, Lionello Lunesu, Stewart Mackenzie, Luis Felipe Murillo, Manolis Perrakis, Michelle Poon, Folkert Saathoff, Brian Tang, Tom Tobback, Susanne Trumpf, Markus Wernli, Savio Woo, Naomi Wu, and Nicolas Ziegler. Dim Sum Labs | Michelle Poon Foreword by Mitch Altman

Projectbookbook launchGuide to hackinghackinginstructables

News

containers, e.g. with systemd

🇦🇹 · Realraum · xro

The more complex a program or application, the more likely it contains exploitable or otherwise dangerous faults. Containers are a way of limiting the damage by limiting an application access to the bare minimum. Ideally we would have a separate and instantly replaceable computer for every little daemon and service we run. Sadly, even with virtual machines, this would hardly be an efficient use of resources, so containers try to find a middle ground by allowing us to separate applications almost as if they were running on different machines, while actually sharing the same hardware and operating system kernel. Several features come together to make this possible: chroot namespaces cgroups And it is a good idea to augment them with others: seccomp-bpf syscall filter packet filtering (ebtables) virtual network devices apparmor Armed with these keywords, your week should now be filled with interesting and productive reading. :-) If all you want are some opinionated basics however, read on: How to use a container? The more containment and separation between applications, the more secure a system gets. Unfortunately few applications come with ready-to-use definition of what access and other applications it requires to function at a minimum. There are ways of finding this out (makejail, documentation, strace, apparmor profiles), but it will always involve some work. You have to find your own balance between the security one requires and the effort needed to attain it. Furthermore, what even is an application? Is it a single program or daemon? Or a bunch of programs running in parallel and working in concert towards a single purpose? How to NOT use a container? Sometimes (web)developers see the Linux systems that run their (web)applications as a house of card that they better not touch or they don’t want to deal with security and quality policies of various Linux distributions. The reason being, that if it works for them, it should work just like that for the end-user. Conveniently containers now allow us to package an applications plus the whole linux ecosystem around it. Unfortunately this just makes everything worse. It makes it harder to actually secure and separate applications from each other while providing a false semblance of security. What is chroot and what can and can’t it do? A chroot is a root file system (e.g. a whole Linux distribution) inside your host root file system in which a program runs. The idea being that a chrooted application can not access any file outside it’s chroot. Obviously then you have to provide (duplicate) all the tools and applications that will be needed inside the chroot filesystem. Tools like debootstrap help installing a debian linux inside a directory or image. Chroot does not restrict assess to the network, syscalls, hardware devices like usb etc. E.g. The root user inside a chroot can easly read harddisk device or re-mount it inside the chroot and do whatever he/she pleases. Links to some great introduction to cgroups I came across The RedHat-blog has some very good hands-on introduction articles on cgroups called „World domination with Cgroups“ I suggest you read them: Part 1 – Cgroup basics Part 2 – Turning Knobs Part 3 – Thanks for the memories Part 4 – All the I/Os Restrict services using systemd unit files Sometimes you just want to contain a single executable. In that case you might not truly need a full machine, you can chroot a service and restrict it just using it’s .service file. My favorite: SystemCallFilter ! it filters what syscalls a process is allowed to use. e.g. you could run a program or bunch of programs with strace -c — <cmd> and put the list of syscalls at the end in the systemd unit file. Other extremely useful directives you should read up on: ProtectHome=read-only || true ProtectKernelTunables=yes ProtectSystem=strict || full || true ProtectControlGroups=yes PrivateDevices=true #DevicePolicy=closed #DeviceAllow=/dev/urandom r #DeviceAllow=/dev/random r NoNewPrivileges=true ReadWritePaths= ReadOnlyPaths= InaccessiblePaths= PrivateNetwork= MountFlags= AmbientCapabilities= CapabilityBoundingSet= chroot: RootDirectory= What about containers as virtual machines replacement? Enter systemd-nspawn systemd-nspawn is systemd’s tool to run containers like you would a virtual machine. Thus ’nspawn containers are called „machines“ and are managed with the tool machinectl . Actually machinectl interfaces not only with systemd-nspawn but also rkt, docker, libvirt and others, thus providing a convenient place to manage all your running virtualisations at once. Putting our application into an container. Easy! Create a chroot under /var/lib/machines/examplecontainer/ and a permission/network/container configuration-file /etc/systemd/nspawn/examplecontainer.nspawn . Then boot it using machinectl start examplecontainer . Done. Example examplecontainer.nspawn [Exec] Boot=yes PrivateUsers=no [Network] ## put container (together with other containers) ## in a virtual private network-bridge called "examplevlan" Zone=examplevlan

englishrandomthoughs

Solidarität mit den Zwiebelfreunden

🇩🇪 · Maschinendeck

Abb. 1: eine “Atombombe”, Quelle: SPON Wie wir heute erfahren mussten, fanden vor zwei Wochen Hausdurchsuchungen im OpenLab Augsburg sowie in Privatwohnungen von Aktiven im Verein Zwiebelfreunde e.V. statt. Dieser Verein betreibt Aufklärung in Sachen Tor und Anonymität im Netz. Darüber hinaus betreibt der Verein Tor-Server und sammelt Spenden für deren Betrieb, aber z.B. auch für den alternativen E-Mail Provider riseup.net . Genau hier setzt die vorgeschobene Begründung der Hausdurchsuchungen an. Im Zusammenhang mit dem Parteitag einer faschistischen Partei, der vor Kurzem in Augsburg stattfand, gab es ein Blog, das zu Aktionen gegen eben diesen Parteitag aufrief. Als Kontaktaddresse war auf dem Blog eine E-Mail Adresse von besagtem Provider angegeben. Die Betroffenen sind im Verfahren gegen die Verfasser*innen des Blogs lediglich Zeugen. Was die Polizei des Freistaats jedoch nicht davon abhält um 6 in der früh auf der Matte zu stehen und die Betroffenen und ihre Familien aus dem Bett zu klingeln. Zum Nachlesen der ganzen Story hier ein paar weiterführende Links: Pressemitteilung des CCC Interview mit den Betroffenen bei netzpolitik.org Spiegel online berichtet Golem berichtet Heise berichtet Wir verurteilen das repressive Vorgehen der bayerischen Polizei gegen Bürgerrechtler*innen und Aktivist*innen Solidarität muss Praxis werden Die aktuellen Geschehnisse sind nur ein Beispiel für ein zunehmend repressives Vorgehen gegenüber Journalist*innen, Bürgerrechtler*innen und Aktivist*innen. Wir finden es deshalb um so wichtiger uns selbst und Andere mit den Werkzeugen der digitalen Selbstverteidigung vertraut zu machen. Dazu zählen die Verschlüsselung von Chats und Festplatten, das anonyme Surfen im Netz sowie der Schutz persönlicher Daten. Aus diesem Grund wollen wir am 31.7.2018 um 20:00 Uhr eine Cryptoparty im Maschinendeck (Eurener Str. 14) veranstalten um dieses Wissen mit Interessierten zu teilen. Wie immer ist die Cryptoparty kostenlos und richtet sich besonders an Menschen, die bisher keine Erfahrung mit digitaler Selbstverteidigung haben. Weitere Informationen, auch über weitere Termine unter cryptoparty.in/trier . Update (5.7.2018) Wie wir gestern während des Chaostreffs erfahren mussten, wurde gestern Abend auch das Haus des Kulturvereins “Langer August” in Dortmund durchsucht [1] . Ziel der Durchsuchungen war offenbar ein Server im Serverraum des WissenschaftsLaden Dortmund. Dies hielt die Beamt*innen des Landeskriminalamts, Abteilung “CyberCrime” jedoch nicht davon ab, auch sämtliche anderen Räume im Haus zu durchsuchen. In dem Haus befinden sich unter anderem auch der Chaostreff Dortmund . Auch die Webseiten und Mailingliste von Chaos West waren vermutlich aufgrund der Durchsuchung am gestrigen Abend nicht erreichbar. Wir sind erschreckt über die Häufung von Vorfällen dieser Art im Umfeld des CCC und verurteilen auch hier das repressive Vorgehen des LKA Zum Abschluss noch ein Terminhinweis: Am Samstag den 7.7. findet in Düsseldorf eine Demo gegen das neue Polizeigesetz in NRW statt. Weitere Informationen dazu findet ihr hier Abb. 2: Ein Zwiebelfreund