From 3d54a6b82fab6858c7f11bdadc7a69ae7813a28e Mon Sep 17 00:00:00 2001 From: yafox Date: Wed, 25 Nov 2020 21:47:24 +0000 Subject: [PATCH] add soft blog entries 004 through 006. --- soft/004-a-preface.md | 22 ++++++++ soft/004-a-preface.md.asc | 16 ++++++ soft/005-stack-zero.md | 101 +++++++++++++++++++++++++++++++++++++ soft/005-stack-zero.md.asc | 16 ++++++ soft/006-lix-os.md | 74 +++++++++++++++++++++++++++ soft/006-lix-os.md.asc | 16 ++++++ 6 files changed, 245 insertions(+) create mode 100644 soft/004-a-preface.md create mode 100644 soft/004-a-preface.md.asc create mode 100644 soft/005-stack-zero.md create mode 100644 soft/005-stack-zero.md.asc create mode 100644 soft/006-lix-os.md create mode 100644 soft/006-lix-os.md.asc diff --git a/soft/004-a-preface.md b/soft/004-a-preface.md new file mode 100644 index 0000000..a0f6ee6 --- /dev/null +++ b/soft/004-a-preface.md @@ -0,0 +1,22 @@ +# a preface + +before entering into the details of building a secure foundation for one's +digital self, a caveat and a suggestion: + +1) security is not a "set it and forget it" affair. it is active and constantly + changing. assumptions turn out to be wrong. people make mistakes, even if + they have good training. expect to make mistakes. have plans in place for + when (not if) that happens. at the very least, make sure you have tools in + place to notify you when your perimeter, whatever it may be, is breached. my + focus in the next few entries will be on strengthening the perimeter around + one's keys, but know that no perimeter is unbreachable. the goal is always + to make breaching the perimeter so expensive or difficult that it doesn't + justify the payoff. + +2) one might consider taking up an art form as a way to believably produce + original cover messages. (being a meme lord _does_ count. the "seriousness" + of one's art form is irrelevant, for our purposes.) art can always be as + "noisy" as one likes, and an artist may always have their own reasons for + creating an artwork one way or another. having a hobbyist's level of + knowledge of electronics may also be very beneficial, as bespoke electronics + are unlikely to have well-known noise signatures. diff --git a/soft/004-a-preface.md.asc b/soft/004-a-preface.md.asc new file mode 100644 index 0000000..89bde5c --- /dev/null +++ b/soft/004-a-preface.md.asc @@ -0,0 +1,16 @@ +-----BEGIN PGP SIGNATURE----- + +iQIzBAABCAAdFiEE0ZVR9dPnC9rIvgC+tQHDCzf0gGwFAl++vEQACgkQtQHDCzf0 +gGyvhg//YMt4F0RVzFgelnLc3d2+ePXx6wD5+jA9Y1jUf3blcnk4SYHPmbQ8PVrY +YsSjQ/NhyxlTiNXEboGiMhgNTEwk7LK5jA+ASsIlYUwju/33v+pvNl8cLMrcj8+b +LGZGMte4f1ZK9SD6A/pmQU4F9QFaJ0j/ijQi5CPF2IRGnXEzu7bz0LmKR0X1nl4G +Gyrk2uixv8tQ91LxaPzQRWdbWvQ7eaZmHtX4ENHDamnn6SmSCEYtlxPish/IdirI +htCQ5+e+DUWqVn2SWoIhXFnbXFM5BrLAXCkVEk0IKhzBs35qeGYZQ6ReKx0UYs2O +WSrBG+0Ua4Wmio00WSOMkd9WyhbopcgsFf2V3Py+iii+MnZN8FK5UbCScRdo4IW0 +BYt/4W4CIrAQnLj5mKIEXKjt49qmZIwnlJhqgrs8G8WfFZGLCOoVorLZJPwl+9FQ +Smhl12fKlSs8aGgeQHHSe5GYVVF+G5zJ2oqYopdtZDZWxuDKnWT+rxXT9AF0+2cl +WUxzXTeM07eYZpLk4zDhmRlqmUSKMxMJGP981BMev6QyUIh1HMkE6o3A9Xj5SRF/ +heeGn1ArKxQFNt+iviuF6po1U2xBwHpVzonRWyNDBGAsDpGynp2dn5dtLKp5UqjU +o/mgagW2VvoXK0dmFYoDGnVja8ouAC14NQNlvukg5/7GyLtJTqQ= +=EID+ +-----END PGP SIGNATURE----- diff --git a/soft/005-stack-zero.md b/soft/005-stack-zero.md new file mode 100644 index 0000000..0e35cd9 --- /dev/null +++ b/soft/005-stack-zero.md @@ -0,0 +1,101 @@ +# stack zero + +i will share first the components of my stack and what each is for, and then +some things i would like to improve in the not-so-distant future. this is a +bootstrapping stack; it is not perfect, but it does seem to be more supportive +of end user control and security than most technology stacks. + +## components and rationales + +1) a "hardware random number generator" (hrng). optional. i just happened to +have one lying around, so i decided to use it. good for generating a lot of +high-quality entropy very quickly. makes creating new keys much faster. + +2) a ledger hardware wallet. this cryptocurrency wallet plays the role of a pgp +smartcard, allowing me to sign things without revealing my private keys to my +online computer. i like that this is a self-contained device with a screen, and +that it has a "plausible deniability" function. it seems to strike a good +balance between security and convenience. + +3) a safe means of transferring data to and from an airgapped computer, such as +a good usb stick. if one uses a usb stick, one should be careful to choose one +with signed or locked firmware, to protect against unknowingly ferrying an +attacker's code between one's "online" computer and one's airgapped computer. +one might also consider turning off hotplugging, to keep the device from +emulating other devices in the event it _does_ harbor malicious code in its +firmware. + +if no such stick can be obtained one might use a +[tinfoil chat](http://git.fuwafuwaqtlkkxwc.onion/yafox/tfc-mirror)-like data +diode system instead. +(original clearnet repository: https://github.com/maqp/tfc ) + +in a pinch, if one's online and airgapped computers have headphone and +microphone jacks, one could also just use an audio cable and +[minimodem](http://git.fuwafuwaqtlkkxwc.onion/yafox/minimodem-mirror). +(original clearnet repository: https://github.com/kamalmostafa/minimodem ) + +4) an old luks-encrypted thinkpad with libreboot, to be kept airgapped after the +initial setup. used for provisioning everything and for interacting with +sensitive material (such as encrypted backups of private keys). libreboot might +have been unnecessary, but as this is the most foundational element in the +stack, i thought it would be better to be safe. for extra security, i set up +libreboot so that it only boots kernels signed with my pgp private key. + +this laptop should at least be loaded with gpg, pcscd, and the tools necessary +to flash the firmware on one's "online" computer. it should also have whatever +software one needs to use one's hrng, if applicable. + +5) an openpower pc from raptor computing systems. this serves as an "online" +computer. all its firmware (except the onboard broadcom nic; there is a +whiteroom re-implementation effort on for that) is open source, so every chip +requiring firmware can be flashed with custom firmware. the system can also +require that all firmware be signed by one's own private keys, and the firmware +can in turn require a signed kernel and initramfs to boot, and the kernel can +_then_, in theory, require that all executable binaries be signed as well. + +so it is possible to lock down this hardware with one's own keys such that +_nothing_ which is not explicitly signed off on by oneself can run on it. + +of course, since this only applies to binaries, any script at all can be run +without having been signed first. there is always a way around whatever +security measures one puts in place. the goal is simply to make it difficult +enough to get around one's defenses that the attacker moves on to another +target, and to escape (as much as possible) mass surveillance. + +regardless, assuming there are no fatal bugs in the implementation, an attacker +would have to gain physical access to one's computer to load their own firmware. +being able to reasonably trust one's own hardware is invaluable. + +6) a simple linux distribution. whatever one understands intimately is fine. +i am building my own and have finally got it to the point where it's not too +embarassing to share. the goal is simply to have a system on which there is +nothing running or installed which one has not consciously chosen, and which can +readily support things like experimenting with different kernel configurations. + +## caveats + +the first caveat here: i am trusting IBM to be truthful about the properties of +their openpower chips, and i am trusting raptor computing systems to be truthful +about the properties of the mainboard they sold me. i am also trusting everyone +involved in the production of these chips and boards. (attacks in manufacturing +[do happen](https://www.bbcnewsv2vjtpsuy.onion/news/technology-47800000).) + +second, this stack is hardly innocuous! the hrng, ledger, and openpower system +are all rather unusual pieces of equipment. + +i have made some compromises along the way in the name of expedience. i would +rather not have to trust IBM, but the alternative is trusting that libreboot has +managed to dig all the backdoors out of the old thinkpads. it comes down to a +bet, though i am not wagering everything on that one bet. if my online machine +fails me, my digital person is at least safe for a time because my keys are not +on my online machine. detecting that failure then becomes paramount. + +this is not a bet i would like to have to make if my life were in danger. i +share all this not because i am confident that it is the best that anyone can +come up with, but because i think it may be a good starting point for some. +experimenting, thinking through things, and customising one's own stack is +encouraged. for example, the ledger might be swapped out with some sort of + +at the very least, i hope this starting point provides a strong enough +foundation for the work ahead. diff --git a/soft/005-stack-zero.md.asc b/soft/005-stack-zero.md.asc new file mode 100644 index 0000000..00f9aec --- /dev/null +++ b/soft/005-stack-zero.md.asc @@ -0,0 +1,16 @@ +-----BEGIN PGP SIGNATURE----- + +iQIzBAABCAAdFiEE0ZVR9dPnC9rIvgC+tQHDCzf0gGwFAl++0LUACgkQtQHDCzf0 +gGxO7Q/+PL14+Sy2agS+nAcSihZrMJRcZo0DHuf0gCv5vE+4R7fXvO6URV1RZgTo +iQpiE/JEKB0/vL+mc5yaQuPJPJbmW9qP0BjGEbHnnMMLnPi4YDbuokdHEvPFYm06 +/aYhR9sjp38FyphZoKDtQKuArRdbNlAfZIIf5bGRo7sK3vQGFhsxOzDzYrgVEXPZ +rEtvzQ1r3WqztBKFnQuIl8/ZMRVYmqE0dOr3BGWqYRZXO+sd8s5Ib8UTT5Uhyp7g +4fDNP/8ezC66nt7+fgwVVJm+6RRCRPIfUG6OUje8cU2aKNkFwiee6V70SBaWYBL6 +sOVhbSFw07Ca0Pcisz8y4atLCZOn4rBN8WCdy37LpIv5u40Zc7b6bWu9Nhq8WHm6 +ZsotWMtd9UuRsXlxmDfW0+J4nctK/1rvfZ0S202GqLFvsBGEn1Z3DMe01Nba37GZ +5/Nl5b7H0S6jkYvYZqzbYmWvUDnf1d3tuN1scCGlBhwDRvPT5oK/fd+6H4qoBzal +4DjhEsdzbM8WmIuUo9DAHPOhEF7Khhu/8UXBcuXUtfwt2Abnvi/me7NGoO1/g3iV +yjufAqjhAwWizxIrVd8hb7hAI1mMV6C2Xzga4/q6Q3yx22V5nSLe/eF+RgjK3otZ +xsRtWF18Qe3kVJ/M+Hasm+ezVnjazwuEfx6gfYdNyrgd+E4Lg/I= +=2FZp +-----END PGP SIGNATURE----- diff --git a/soft/006-lix-os.md b/soft/006-lix-os.md new file mode 100644 index 0000000..7716a4d --- /dev/null +++ b/soft/006-lix-os.md @@ -0,0 +1,74 @@ +# lix os + +in order to have a system which both minimised trust dependencies and allowed me +to explore my ideas around securing my system unimpeded, i decided to design and +compile my own linux from source code. + +i had done this before, years ago, by following the "linux from scratch" guide. +my goal now was to build a system i could use to birth my more-than-reasonably +secure digital identity. the goal was a statically linked linux based on musl +and suckless tools. i wanted an inflexible system that would do nothing without +my explicit, cryptographic permission, along with a tiny codebase that would be +easy to examine and modify. + +my first attempt i named "mu linux," unaware that the name was already in use. +it was essentially a scripting of the linux from scratch approach, with a strict +"filesystem-as-database" approach. every discrete field was a file, so nothing +more than "cat" was needed to read package details. it had no ability to set +redundant urls for fetching source code, though, and no sandboxing at all. the +whole thing was also written as one, tightly coupled piece. + +having proven that it was possible to build a static suckless userland with musl +on my openpower computer, i decided to start using some fancier linux features +to create some separation of state and concerns. i took note of what seemed to +me the discrete "units" of mu linux and began writing standalone utilities that +did only one thing each and which i hoped might prove useful to others tackling +the same problems. i built a package manager that used overlayfs and chroots to +keep filesystem changes from the build process and from the installation process +in their own directories, facilitating insight into each step of package +development. + +as i went, i started having to make compromises. gnu tools were the first. +getting a c compiler toolset set up with musl proved difficult. only two +compilers seemed to have support for the powerpc64le platform: gcc and clang. +clang took an age to compile and gave me some trouble early on. musl-cross-make +provided a canonical set of patches for enabling muslc support, as well as some +other nice features. autotools, gnu-sed, and gnu-grep followed soon after. + +then dynamic linking began creeping in. the first dynamically linked packages +were gpg and pcscd. i needed smartcard support, and gpg uses dlopen to load +smartcard drivers dynamically. rewriting portions of gpg would have resolved +the problem, but it seemed simpler to just allow this one package to use dynamic +linking. i also ended up making exceptions for perl and python, as they needed +dynamic linking to be able to load certain modules. i absolved myself by making +sure statically linked versions of those packages were the default. those +compromises got me a console userland with tmux, tor, lynx, and the ability to +display images to the framebuffer. + +then i tried to start building an identity on tor and quickly discovered i had +no way to solve captchas! i tried building a copy of netsurf targeting the +framebuffer and learned i had to choose either wayland or sdl2 as middleware. +i chose wayland, thinking i could just use michael forney's wld and swc, both of +which were built with static linking in mind, and get a desktop environment out +of the deal. after quite some time wrestling with these packages, i ultimately +gave up: netsurf would launch, but then shortly thereafter lock up the whole +system, and i could not figure out why. i was losing patience with the whole +endeavor, so i decided to just use more common components for my desktop and +revisit the problem later. + +so i made another compromise and built an almost entirely dynamically-linked +desktop system: sway as the window manager, foot as the terminal emulator, +netsurf with gtk3 as the web browser, and webkit2gtk as an alternate web browser +for when netsurf wasn't cutting it. + +along the way i tried to bootstrap rust using mrustc in order to get firefox +built and then the tor browser, but no luck there. yet another problem to +revisit. in the meantime i've come up with new ideas for a third linux +distribution better able to manage runtime dependencies, but lix os works and +has been working for me now for a couple months. + +today i've released my work so far. i have not yet purged the false starts and +half-working packages from their respective repositories, but at present it is +possible to set up the desktop system i have described here. my work is spread +out across several repositories, but the entry point for lix os is +[here](http://git.fuwafuwaqtlkkxwc.onion/yafox/lix-os). diff --git a/soft/006-lix-os.md.asc b/soft/006-lix-os.md.asc new file mode 100644 index 0000000..cb7b78f --- /dev/null +++ b/soft/006-lix-os.md.asc @@ -0,0 +1,16 @@ +-----BEGIN PGP SIGNATURE----- + +iQIzBAABCAAdFiEE0ZVR9dPnC9rIvgC+tQHDCzf0gGwFAl++0L4ACgkQtQHDCzf0 +gGw78g/+I8Cet09ZuTjIyIaI5prB9XI6gAbIA4BSeKgJQ8gG1X1kHEUuSEDIhNcd +nR2RwAtfQHmCzDkJ254K+9qEua9qi6jWusX9joYLYxPtAiKfgt+zPf/czzEXKHC3 +pvyBxogG9ANo7Oe3rFWucHCUjyu9Lp9wIo0XIIjPkgGfS5z9fcAJNgjecCUrDLzx +1LBeAYqA4c1rn0lGuqFcD0GIim+GFlEcozvb0iCXK9xPam9d6+04z3lELH+LNCXH +c5QLlzEDapXgI3FNc6tvhRnmUmSNj9grJHhTzU9pIZ5CXoBrYtgau+4ayFMK0+89 +hg8xlUnnc5S/I2a9rZxunsIi+RDN/i6VS6IIpRg9bHoIfpudimWwlM9ZfkVNpxdT +QRCE21DTyTiDn0reRaLZTQBLxGENcAMkGlGqkJ1hoyrLwcWzCmNH9NzlEDTE07aZ +ozWB0edG5zmdOkILZn5OEvIkY4CnIym7mVU0AnaKAyDJzR5VySdvIdlmrrKhuPzu +EuBo/fNyD+rR3LmLCfyIxMRO49IrugNrQRYqAfZvmSFuvFGf8U4mS0FQQiLKpCLs +F5ZxkcRWa4lhIq2KftS/7cp/uYd3fPuejCOJa0td0KNGUTdTeEEdDl5j48GMWkt4 +oJGDONyHbOC4UZaBg09XWFrj7nu2MrYU+QlkQGF9DwHtAA2teDM= +=CmJ5 +-----END PGP SIGNATURE-----