Ralf's Ramblings: Sysadmin
Sandboxing All The Things with Flatpak and BubbleBox
A few years ago, I have blogged about my approach to sandboxing less-trusted applications that I have to or want to run on my main machine. The approach has changed since then, so it is time for an update.
Outlook.com Considered Harmful
I am administrating the server that hosts this blog myself, and this includes running and maintaining my own mail server. Email is a messy and complicated bit of infrastructure, born in a more innocent age where everyone connected to the internet trusted each other. Over time, is has grown many layers of band-aids to provide at least some level of security. Email is also beautiful, it is the most widely used example of federated infrastructure: in principle, anybody can set up a mail server and communicate with everyone else, no matter which provider they are using. This is an amount of organizational resilience and user freedom that most messenger services can only dream of.
Perhaps surprisingly, I have had very little trouble with my own server; most big email providers do a good job blocking spam while permitting small independent mail servers to operate smoothly (this includs even Gmail, to my astonishment). There is just one exception: Microsofts Outlook.com (formerly Hotmail.com) and the other services using the same underlying infrastructure (such as live.com).
Sandboxing All The Things with Firejail
Sometimes, I run software that I trust less. All software I use on a daily basis is open-source, but there is still closed-source software I run occasionally, like video games. Unfortunately, the usual Unix security model does not protect against such software misbehaving, as illustrated by this XKCD. There is no good reason that these applications should have access to all my personal information and secret keys that I have stored on my system, but without proper application isolation (like we are used to on mobile devices nowadays) nothing stops them from leaking all this data. I didn’t want to wait until such technology becomes the default on Linux desktops, so I did some research for ways to sandbox existing applications and ended up with Firejail.
Fighting Mailman Subscription Spam: Leveling Up
Last week, I blogged about my efforts to fight mailman subscription spam. Enabling
SUBSCRIBE_FORM_SECRET as described there indeed helped to drastically reduce
the amount of subscription spam from more than 1000 to less than 10 mails sent
per day, but some attackers still got through. My guess is that those machines
were just so slow that they managed to wait the required five seconds before
submitting the form.
So, clearly I had to level up my game. I decided to pull through on my plan to write a simple CAPTCHA for mailman (that doesn’t expose your users to Google). This post describes how to configure and install that CAPTCHA.
Fighting Mailman Subscription Spam: The Easy Way
I recently noticed that both of the Mailman setups that I am running are being abused for subscription spam: Bots would automatically attempt to subscribe foreign email addresses to public mailing lists, resulting in a subscription notification being sent to that address. I am still extremely saddened by the fact that this is a thing—whoever sends this spam has no direct benefit and no way of selling anything (they don’t control the content of the message); the only effect is to annoy the owner of that email address, the victim. That seems to be enough for some. :(
Oh, and my servers’ reputation goes down because people mark these emails as spam. So, more than enough reasons to try and stop this.
Syncing Contacts Without Exposing Them to the Cloud
I finally have a setup that I am happy with for syncing contacts between my phone and my laptop. Most would probably consider that a solved problem, but I have an extra requirement that rules out most existing solutions:
The data of my contacts must not be exposed in clear text to any machine I do not physically control.
I’m not happy about my own personal data being shared with third parties, and consequently, I will not share the personal data others entrust to me with third parties. This obviously rules out all of these “free” cloud services out there that Apple, Google and others offer—services that are paid with data, and in the case of contact sync frequently paid with the data of others. (This leaves me wonder whether under the GDPR, it is even legal for someone else to consent to my contact data being shared with a cloud provider. I certainly never consented and still my data sits in multiple synced address books. But that’s a discussion for another day.) Moreover, this also rules out putting them e.g. into an ownCloud or Nextcloud hosted on ralfj.de, because that is a VPS that I do not have any physical control over.
Let's Encrypt Tiny
I think all HTTP communication on the internet should be encrypted – and thanks to Let’s Encrypt, we are now much closer to this goal than we were two years ago. However, when I set up Let’s Encrypt on my server (which is more than a year ago by now), I was not very happy with the official client: The client manages multiple certificates with different sets of domains per certificate, but I found it entirely unclear which commands would replace existing certificates or create a new one. Moreover, I have some special needs: I’ve set up DNSSEC with TLSA records containing hashes of my certificates, so replacing a certificate has to also update DNS and deal with the fact that DNS entries get cached. Lucky enough, Let’s Encrypt is based on open standards, so I was not forced to use their client!
To make a long story short, I decided to write my own Let’s Encrypt client, which I describe in this post.