add soft blog entries 004 through 006.

This commit is contained in:
yafox 2020-11-25 21:47:24 +00:00
parent fbc52a5e9b
commit 3d54a6b82f
No known key found for this signature in database
GPG Key ID: B501C30B37F4806C
6 changed files with 245 additions and 0 deletions

22
soft/004-a-preface.md Normal file
View File

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

16
soft/004-a-preface.md.asc Normal file
View File

@ -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-----

101
soft/005-stack-zero.md Normal file
View File

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

View File

@ -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-----

74
soft/006-lix-os.md Normal file
View File

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

16
soft/006-lix-os.md.asc Normal file
View File

@ -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-----