Linux on Joel Beckmeyer's Blog

Moving Back To OpenSSL

joel@beckmeyer.us (Joel Beckmeyer) — Mon, 22 Mar 2021 11:00:00 -0400

Void Linux recently announced that they were going to move back to OpenSSL after originally switching to LibreSSL in 2014. It seems that there are a lot of things at play here.

It seems that the main focus of the recent announcement is on the maintainability and other difficulties of not using the one true SSL/TLS library. To me, this pragmatically makes sense. However, every time something like this happens I get this lingering feeling of worry…

Microsoft moving their default browser from their own implementation to Chromium, and other browsers following suit.

Linux distributions moving en masse to systemd.

Distributed email being slowly crushed and killed by Google with GMail.

And many other examples that aren’t immediately coming to mind.

I think it’s great that OpenSSL as a project has made a comeback from the Heartbleed fiasco, and that it is apparently more actively developed nowadays, but the fact that we are even at the point of moving back to OpenSSL due to difficulties with building software is worrying. To me, it looks like a symptom of software becoming too entrenched and dependent on a single piece of software.

This kind of accusation coming from anyone is going to be hypocritical, since we all depend on Linux, X11, Wayland, systemd, or some common piece of software that we take for granted and don’t lose sleep over. However, I think what’s categorically different about this one is that an alternative was adopted, worked on, but eventually “failed” (at least for Void, but also possibly for Linux as well).

I don’t know what the fix for this specific issue would be. I’m not nearly familiar enough with SSL/TLS or how you would develop software to be agnostic of dependencies like this. But I think in order to honor principles like the Unix philosophy, the KISS principle, and countless others, we need to figure out a way to be more modular for dependency issues like this.

OpenWRT + Unbound + adblock

joel@beckmeyer.us (Joel Beckmeyer) — Fri, 05 Feb 2021 19:03:15 -0500

I decided to do some work on my Linksys WRT32X running OpenWRT to make it a little more useful.

Unbound is a DNS resolver which I like because it’s recursive, meaning it directly queries the root servers instead of relying on existing DNS servers run by Google, Cloudflare, your ISP, or the like. I already have it running on several of my servers and computers, but I figured it would be great if everything on my network can use Unbound and be, well, unbound from all of those intermediary DNS servers.

Luckily, OpenWRT already has Unbound packaged, and also has a useful LuCI app that goes with it (LuCI is the graphical web interface that comes with OpenWRT). All I had to do was install luci-app-unbound, which pulls in all of the necessary dependencies to run unbound.

After that finished installing, I refreshed LuCI/OpenWRT and went to “Services” on the top, and there it is!

At this point, you’ll have to get your hands dirty. You can either dig through some LuCI menus or SSH in and make some edits. For reference, I’m using “Parallel dnsmasq” section from the README for unbound in the OpenWRT packages (which has a lot of other useful information as well!). Essentially, I made the edits to /etc/config/unbound and /etc/config/dhcp after SSH’ing in. However, you can make the same edits through LuCI.

For the /etc/config/unbound edits, you can make the edits to the file in LuCI directly at “Services -> Recursive DNS -> Files -> Edit: UCI”:

For the /etc/config/dhcp edits, you can make the edits by finding the same fields under “Network -> DHCP and DNS”:

However, the field names are different from the lines in the config, so they would need to be researched to determine which fields in LuCI map to which lines in /etc/config/dhcp.

At this point (or maybe after restarting unbound and dnsmasq, which is a lot easier using SSH and /etc/init.d ... restart as well), OpenWRT should now be using unbound for resolving all DNS lookups, while dnsmasq is only used for DHCP-DNS.

Bonus: you can also enable a nice status dashboard in LuCI under “Services -> Recursive DNS -> Status”, but this requires installing several more software packages: unbound-control and unbound-control-setup. You will also need to change a line in /etc/config/unbound:

...
option unbound_control '0'
...

becomes

...
option unbound_control '1'
...

A word of warning: there is another section on “Unbound and odhcpd” which tries to cut out dnsmasq completely. However, when I tried to set this up, I got myself into a lot of trouble (had to reset OpenWRT, re-install any extra software packages, and restore configuration from backup). It is also possible that if you mess up the configuration for the “Parallel dnsmasq” method, you could end up in a similar error state and have to start over. Please be careful when doing this and don’t change anything you’re not supposed to.

Now, moving on to adblock, which should be much simpler to setup. First, install luci-app-adblock and refresh. Navigate to “Services -> Adblock”:

Check the settings at the bottom. The only thing you need to get going is to go to the “Blocklist Sources” tab and choose your blocklists.

The adblock readme has some more info on what each list is. After that, make sure “Enabled” is checked under the “General Settings” tab:

and click the “Refresh” button above:

Then you’re good to go; adblock should work out of the box with unbound; cheers!

ADDENDUM: Another word of warning: once you’ve setup adblock, it will download the blocklists, merge them into a single file at /var/lib/unbound/adb_list.overall, and try to restart unbound. I recommend not trying to view/interact with adblock or unbound during this restart, which can take anywhere from 30 seconds - 2 minutes. Just leave them alone in LuCI for a little bit…

Hello doas

joel@beckmeyer.us (Joel Beckmeyer) — Sat, 30 Jan 2021 15:15:55 -0500

Today, I switched my workstation from sudo to doas. I’m running Void Linux, and the process was fairly easy.

First, I needed to figure out how to remove sudo (yes, I realize I could have installed doas first, then removed sudo, but I decided to do it the hard way.) As it turns out, the advanced usage section of the XBPS manual details how to use the ignorepkg entry in xbps.d with nothing other than this exact use case! I created the file /etc/xbps.d/20-ignorepkg-sudo.conf with contents

ignorepkg=sudo

and then ran sudo xbps-remove sudo (an ironic command).

After that, because I was stupid and removed sudo before I had set up doas, I had to use plain-old su to change to the root user and run xi opendoas. I also configured doas in /etc/doas.conf with the following:

# see doas.conf(5) for configuration details
permit nopass keepenv :admin

I ran groupadd admin, usermod -aG admin joel, and then logged out so that my user account would see the new group perms.

And just like that, I can now run doas xbps-install ... and all of my other commands, just substituting doas for sudo.

The one thing I immediately missed was sudoedit. Before I accidentally tried to use sudo for the first time, I had already accidentally tried to run sudoedit at least 5 times. I had to fix this. I saw a discussion on Reddit where one user suggested writing a script to replace the sudoedit functionality. I quickly starting hacking together something like that. I started with:

#!/bin/sh
mkdir -p /tmp/doasedit
doas cp $1 /tmp/doasedit/tmp_file
$EDITOR /tmp/doasedit/tmp_file

And quickly ran into my first road-block. The script is going to have to change the permissions of that file before the user can edit it. But if the script changes the permissions, how can I restore it to the original location with the right permissions? cp /tmp/doasedit/tmp_file $1 won’t work. I thought about just using cat to overwrite the file contents in-place (cat /tmp/doasedit/tmp_file > $1). That could create some issues if a program has the file open. Instead, a better option is to create two copies of the file–one for editing, and one for preserving file attributes:

#!/bin/sh
mkdir -p /tmp/doasedit
doas cp $1 /tmp/doasedit/edit
doas chown -R $USER:$USER /tmp/doasedit/edit
doas cp $1 /tmp/doasedit/file
$EDITOR /tmp/doasedit/edit
cat /tmp/doasedit/edit | doas tee /tmp/doasedit/file 1>/dev/null
doas mv -f /tmp/doasedit/file $1
rm -rf /tmp/doasedit

Of course, the issue with this is that it only works with absolute paths. I want to make it work for relative paths as well. I’m going to take advantage of realpath, which is part of the coreutils package from Void. As a bonus, this will also take care of the edge case where the given file is a symlink (IIRC, sudoedit didn’t follow symlinks, so I may be diverging here):

#!/bin/sh
mkdir -p /tmp/doasedit
srcfile="$(realpath $1)"

doas cp $srcfile /tmp/doasedit/edit
doas chown -R $USER:$USER /tmp/doasedit/edit
doas cp $srcfile /tmp/doasedit/file

$EDITOR /tmp/doasedit/edit

cat /tmp/doasedit/edit | doas tee /tmp/doasedit/file 1>/dev/null
doas mv -f /tmp/doasedit/file $srcfile

rm -rf /tmp/doasedit

At this point, it works…okay-ish. It can only be used in one instance currently since I hard-coded /tmp/doasedit/file and /tmp/doasedit/edit, but that’s easily fixed:

#!/bin/sh

destfile_pfx="$(cat /dev/urandom | tr -cd 'a-f0-9' | head -c 32)"

while [ -d "/tmp/doasedit/$destfile_pfx" ]; do
	destfile_pfx="$(cat /dev/urandom | tr -cd 'a-f0-9' | head -c 32)"
done

mkdir -p /tmp/doasedit/$destfile_pfx
srcfile="$(realpath $1)"

doas cp $srcfile /tmp/doasedit/$destfile_pfx/edit
doas chown -R $USER:$USER /tmp/doasedit/$destfile_pfx/edit
doas cp $srcfile /tmp/doasedit/$destfile_pfx/file

$EDITOR /tmp/doasedit/$destfile_pfx/edit

cat /tmp/doasedit/$destfile_pfx/edit | doas tee /tmp/doasedit/$destfile_pfx/file 1>/dev/null
doas mv -f /tmp/doasedit/$destfile_pfx/file $srcfile

rm -rf /tmp/doasedit/$destfile_pfx

At this point, the only thing missing is the check to see if the file was actually edited:

...
cat /tmp/doasedit/$destfile_pfx/edit | doas tee /tmp/doasedit/$destfile_pfx/file 1>/dev/null

if cmp -s "/tmp/doasedit/$destfile_pfx/file" "$srcfile"; then
	echo "Skipping write; no changes."
else
	doas mv -f /tmp/doasedit/$destfile_pfx/file $srcfile
fi
...

I put this in a repo on GitHub if anyone is interested. I know that a major weakness of this script is the number of times it calls doas, which could break flows where password is required every time doas is run.