Fast follower post – making OpenBSD UI a bit “prettier” (as I see it)

In my last blog post, I shared how I set up my OpenBSD laptop from the bare metal. In retrospect, there are a handful of UI tweaks that I also perform to make my UI and workflow more consistent between my OpenBSD machines and my Linux (Ubuntu) machine. I know that the purists out there are crying “boo hiss” but then they probably were crying that when I talked about using Gnome instead of cwm and xenodm for my window manager <grin>. Here are some things that I like to do.

First things first, I had forgotten that I prefer to use the “regular” (not dark, not light) version of the Yaru-remix theme from because it keeps the menu bar and window titlebars dark while still leaving things like Evolution’s list of folders, preview pane and list of messages pane with a light background. Again, more like what I see on Ubuntu in my Linux machines.

For my terminal prompt, I had forgotten at the time I did the nuke and re-pave that I had moved away from the old “green screen” look (green on a black background) and went with white on a black background to get the base look set up. I then use the ability to inject color into the PS1 prompt so that the machine name shows up in green and the current working directory shows up in blue with a white dollar-sign prompt by making this change in my ~/.profile file:

export PS1=”\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]$ “

Next, I need to install the colorls package using “pkg_add” and enable a .kshrc file by adding this line to my ~/.profile file:

export ENV=$HOME/.kshrc

In the ~/.kshrc file itself, I add an alias to make a regular issuance of “ls” actually fire the colorls command:

alias ls=”colorls -G”

and just for giggles, I use “pkg_add” to import the vim (non-x11) package and make my old timey SunOS4 muscle memory not betray me when I’m trying to edit a file and mistype “vim” as just straight-up “vi”:

alias vi=”vim”

I also add this line to my /etc/rc.conf.local file (I haven’t figured out the magic syntax for rcctl to do this with no flags):


and then start the NTP daemon:

# rcctl start ntpd

Since I maintain several ports on OpenBSD (yeah, I know, I need to update some of them – I’m working on it! <grin>), I like to set up anonymous CVS access to the ports tree by adding this to my .profile:


and then do an initial checkout of that and the rest of the OpenBSD source code for good measure by running:

# cd /usr
# cvs -qd checkout -rOPENBSD_6_7 -P src ports xenocara

I also make Firefox my default web browser and follow the recommendations at to ensure that I have it configured to maximum privacy mode.

One thing I’ve noticed is that it takes Gnome Evolution 3-4 launches to correctly pick up folder names in my EWS and IMAP mail services. I’m not sure why that is (it seems like some sort of network timeout more than anything else) but it’s just a minor annoyance. Keep re-launching it after it settles down and eventually it will get it right.

The other Evolution annoyance is that it doesn’t correctly identify the SPAM, TRASH and INBOX folders so some of the nice shortcuts you get from the context menu to expunge things (for example) and some of the nice automatic sorting of “Inbox” to the top of the folders list doesn’t happen with EWS accounts. Again, annoying, but it doesn’t limit the basic functionality of the email client.

Since it takes several hours (days?) to sync all of my NextCloud documents and email archive data, I generally try to switch off suspend when plugged in until everything is synced the first time. After that, I go back to a suspend after an hour of inactivity mode for my normal use. While you are in the settings app changing that, it’s a good time to turn off the notifications on both the main screen as well as the lock screen if you find them as annoying as I do.

In conclusion, these little tweaks and configuration allow me to have a pretty consistent workflow across all of my laptops/workstations so that I can continue the programming of my spinal cord that has been ongoing since the 80’s when it comes to working on *nix systems. I hope you found this to be a useful read.

OpenBSD Laptop

Hi, I know it’s been a while. I recently had to nuke and re-pave my personal laptop and I thought it would be a nice thing to share with the community how I set up OpenBSD on it so that I have a useful, modern, secure environment for getting work done. I’m not going to say I’m the expert on this or that this is the BEST way to set up OpenBSD, but I thought it would be worthwhile for folks doing Google searches to at least get my opinion on this. So, given that, let’s go…

After downloading the install67.fs image from my favorite site ( I write it to a USB drive on Linux with:

$ sudo dd if=install67.fs of=/dev/sdc bs=1M

I then boot off of that USB drive and drop to a (s)hell at the install prompt. From there, I create the full disk encryption container for my install:

# cd /dev
# chmod +x ./MAKEDEV
# ./MAKEDEV sd1
# fdisk -iy sd1
# disklabel -E sd1

Create one big “a” partition for the whole drive but specify RAID as the partition type.

# bioctl -c C -l /dev/sd1a softraid0

I then enter my decryption password and type ‘exit’ to restart the installation. The only tweak I make to the installer is to set up my wifi (it won’t work in the installer or on reboot for me because I have an Intel ‘iwm’ device that needs the firmware installed – I do that later) and make sure that my /usr partition is at least 200g in size (I probably should but I don’t create the subdirectory mount points, just one big /usr).

After the first reboot, I go back to my Linux box with the same USB drive, turn it into a single partition FAT32 drive and download the firmware for my Intel ‘iwm’ device from as a single .tgz file that I place on that USB drive. I then mount the drive on OpenBSD:

# mount /dev/sd2i /mnt

Next, I copy the .tgz file to the /etc directory and expand it there. It will automatically put the right files in the /etc/firmware directory. I then reboot and should have WiFi. I then update the other firmware:

# fw_update

Next, I run syspatch to ensure that I’m fully patched on the kernel and userland I’m running:

# syspatch

That takes a bit of time, just be patient. At this point, it’s best to reboot because so much has changed on the disk from what is running in memory. You should see in the dmesg output that all of your firmware installed successfully and that the kernel relinked to help fight off potential ROP attackers.

First things first, I create an /etc/doas.conf file so that I can run everything in my regular user account:

# echo “permit persist keepenv MY_USERNAME as root” > /etc/doas.conf

Next, I set up power management (because I’m running on a laptop):

# rcctl enable apmd
# rccl set apmd flags -A
# rcctl start apmd

Since I run development tools and the owncloud desktop, I have to tweak some values in /etc/login.conf to make things work the way I want them to. First, I add myself to the “staff” group:

# usermod -G staff MY_USERNAME

I then edit /etc/login.conf in the “staff” section to make the following changes:

# pkg_add vim
# vim /etc/login.conf


I also modify /etc/sysctl.conf to include the line:


I then will typically reboot to pick up the changes.

Next, I want to install the Gnome desktop environment and the Gnome display manager. It’s what I’m most comfortable in and I know it’s a pain in the you know what for the port maintainers to keep it working on OpenBSD because of the Linux-ism’s that keep creeping in so I want to put in a shout out to them for all of their hard work on this.

# pkg_add gnome gnome-tweaks gnome-extras
# rcctl disable xenodm
# rcctl enable multicast messagebus avahi_daemon gdm

Install my favorite applications and utilities:

# pkg_add firefox chromium libreoffice owncloudclient
# pkg_add keepassxc aisleriot evolution evolution-ews
# pkg_add tor-browser shotwell gimp

I will reboot at this point and go into Gnome with the default theme. That needs fixing so I download the yaru-remix-complete theme from and install it manually by doing the following:

$ cd ~
$ mkdir .themes
$ cd .themes
$ mv ~/Downloads/Yaru-remix-complete.tar.xz .
$ unxz Yaru-remix-complete.tar.xz
$ tar xf Yaru-remix-complete.tar
$ mv themes/* .
$ rmdir themes
$ doas mv icons/* /usr/local/share/icons
$ rmdir icons
$ doas mv wallpaper/* /usr/local/share/backgrounds/gnome
$ rmdir wallpaper
$ rm Yaru-remix-complete.tar

Fire up gnome-tweaks and from “Extensions” turn on “user-themes”. Close and restart gnome-tweaks, go to the “Appearance” tab and select “Yaru-remix-dark” for “Applications”, “Icons” and “Shell”. ON “Top Bar”, turn on “Battery Percentage” and “Weekday”. In “Window Titlebars” enable “Maximize” and “Minimize”.

Enable the extension “Dash to Dock” by downloading it from and pick the right shell version and extension version to match your install of Gnome shell. You will have to manually install it because the Gnome shell extension integration doesn’t appear to be enabled for OpenBSD:

$ cd ~/Downloads
$ unzip
$ cat metadata.json

The value for “uuid” is what you want to use next:

$ mkdir -p ~/.local/share/gnome-shell/extensions/
$ cd ~/.local/share/gnome-shell/extensions/
$ unzip ~/Downloads/

Reboot to restart Gnome shell, log in, start gnome-tweaks, navigate to the “Extensions” tab and enable dash to dock. From the settings gear icon, select “extend to edge…” and you should have a very serviceable dock that is quite similar to Ubuntu 20.04’s.

Finally, switch the terminal to “Green on Black” for a better look in the terminal. Pin your favorite apps to the dock and you should be good to go.

Let’s dial it up to 11

So. It’s been a few months since I last posted here. I decided that the best way to sharpen my cyber skills would be to start treating my home environment like an enterprise one. In approaching this thought experiment, I thought:

“What key functions would I have in a production, enterprise network that I don’t have here?”

I have an IDS (Snort) but there are some holes:

  • Vulnerability scanning
  • Log aggregation
  • Centralized identity management
  • Endpoint protection
  • Etc.

In thinking through things, I decided I’ll tackle these one at a time. First things first, let’s get some log aggregation going.

After doing some research, I decided that the open source version of Graylog would be my choice for this function on my pseudo-production network. I thought about running this on my OpenBSD router/firewall, but decided that the stack necessary would just overwhelm the machine. Therefore I spun up a virtual host in my hosting environment of choice (DigitalOcean) and started installing / configuring things.

I decided to run Ubuntu 18.04 LTS for the core OS on the virtual machine and followed this tutorial to get Graylog up and running. Once I had the core server running, I decided to figure out how to get log data pushed to it. Since I want everything I do to be open source, I figured that rSyslog would be my best approach. It appeared to be native (or nearly native) on most of the operating systems I run and integrated nicely with Graylog.

I added a “Syslog UDP” Graylog input on a high numbered port on my server, used UFW to open a hole for the traffic and then started researching the arcane syntax of the /etc/rsyslog.conf file that would be necessary to work this bit of magic and get my log messages pushed to my aggregator. I figured it out in about 30 seconds but thought – “No way. It can’t be that easy!” and dug around for a while until I decided to just try it. Here is the incredibly complex piece of syntax you have to use:


Where the single at sign means to use RDP, the 1234 is the port you are running the Graylog input listener on and “” is the FQDN of your Graylog server. No kidding, it’s that easy!

Slug that in as the last line in /etc/rsyslog.conf on a Linux box, restart the rsyslog service:

sudo systemctl restart rsyslog

and you are cooking with gas. I’ve still not cracked the code with OpenBSD, but with all of my other ‘nix boxes, it’s dead simple. Now to tackle Windows (yes, I have a few Windows machines).

For Windows, the common wisdom on the Internet says you should use nxLog for the listener on the Windows box and you should ship the log data over to Graylog as a GELF format. After installing a GELF UDP input listener on Graylog and playing around for a while, I ended up with the following configuration file for nxLog that worked:

Panic Soft
#NoFreeOnExit TRUE

define ROOT     C:\Program Files (x86)\nxlog
define CERTDIR  %ROOT%\cert
define CONFDIR  %ROOT%\conf
define LOGDIR   %ROOT%\data
define LOGFILE  %LOGDIR%\nxlog.log

Moduledir %ROOT%\modules
CacheDir  %ROOT%\data
Pidfile   %ROOT%\data\
SpoolDir  %ROOT%\data

<Extension _syslog>
    Module      xm_syslog

<Extension _charconv>
    Module      xm_charconv
    AutodetectCharsets iso8859-2, utf-8, utf-16, utf-32

<Extension _exec>
    Module      xm_exec

<Extension _fileop>
    Module      xm_fileop

    # Check the size of our log file hourly, rotate if larger than 5MB
        Every   1 hour
        Exec    if (file_exists('%LOGFILE%') and \
                   (file_size('%LOGFILE%') >= 5M)) \
                    file_cycle('%LOGFILE%', 8);

    # Rotate our log file every week on Sunday at midnight
        When    @weekly
        Exec    if file_exists('%LOGFILE%') file_cycle('%LOGFILE%', 8);

<Extension _gelf>
    Module      xm_gelf

<Input eventlog>
    Module  im_msvistalog

<Output out>
    Module      om_udp
    Port        1234
    OutputType  GELF

<Route 1>
    Path eventlog => out

Make sure to put in your FQDN for your Graylog server and the port number you are running your GELF input on.

At this point, I logged into each machine on my network and the log messages started flowing smoothly! Just for fun I set up an email alert capability and set some thresholds on failed root logins for the ‘nix boxes to let me know if anything funky is happening.

Next up – vulnerability scanning!

OpenBSD Full Disk Encryption with CoreBoot and Tianocore Payload

It has been a while since I have posted here so I wanted to share something that was surprisingly difficult for me to figure out.  I have a Thinkpad T440p that I have flashed with Coreboot 4.11 with some special patches that allow the newer machine to work.  When I got the laptop, the default BIOS was UEFI and I installed two operating systems.

  • Windows 10 with bitlocker full disk encryption on the “normal” drive (I replaced the spinning 2.5″ disk with an SSD)
  • Ubuntu 19.10 on the m.2 SATA drive that I installed using LUKS full disk encryption

I purchased one of those carriers for the optical bay that allows you to install a third SSD and so I did that with the intent of putting OpenBSD on it.  Since my other two operating systems were running full disk encryption, I wanted to do the same on OpenBSD.

Turns out that with a UEFI install, it is surprisingly hard.  My first attempts failed miserably.  Then, I had some inspiration.  I decided to install OpenBSD with no encryption and see if I could get things working with booting that from the Grub2 menu in Linux (where I also had an entry for Windows 10).  If I could do that, I figured I could go back and drop the non EFI partition and replace it with a softraid encrypted partition.

I installed OpenBSD “straight up” and was able to boot the disk from the boot menu in Tianocoare’s implementation of UEFI.  The trick was now to figure out what entry I had to make in Grub2 under Ubuntu to get things working.  I shot in the dark based on one web search after another and got no joy.  I decided to sleep on it.

When I attempted again, I remembered that you could hit the “c” key from the Grub2 boot menu and get an interactive Grub2 command prompt.  From here, I used the ls command to find the Grub2 name of my OpenBSD EFI partition that was created by the installer.  In my case, it turned out to be (hd2,gpt2).  I did an ls like this:

ls (hd2,gpt2)/

and was able to see the efi subdirectory (note the trailing slash!) and then could use ls to further explore and find the /efi/boot/ directory that contained the bootx64.efi bootloader file.

OK.  Now how can I get Grub2 to boot that.  Turns out there is a module you have to load called “part_msdos” (because the EFI partition is an msdos partition secretly).  I tried issuing the insmod part_msdos command (which was successful) and then used:

chainloader (hd2,gpt2)/efi/boot/bootx64.efi

Then I issued the “boot” command and I booted into my unencrypted OpenBSD partition.

Now that I had this, it was a simple matter to edit the 40_custom file in /etc/grub.d on the Ubuntu 19.10 system to create a special entry for OpenBSD:

menuentry “OpenBSD” (on /dev/sdc2) $menuentry_id_option ‘openbsd’ {
insmod part_msdos
chainloader (hd2,gpt2)/efi/boot/bootx64.efi

With that, I was able to boot from the Grub2 boot menu into my unencrypted OpenBSD partition!  w00t indeed!!

Now, to make it an encrypted partition.  I booted up from my USB install media for OpenBSD, dropped to a shell, and used fdisk in interactive mode to delete all of the non swap OpenBSD partitions from the disk – don’t delete the EFI partition!!!!!  After that, I created on single “a” partition and made it’s filesystem type “RAID”.  From there, I issued the bioctl command to turn that partition into a softraid encrypted partition:

bioctl -c C -l /dev/sd2a softraid0

I provided my password to decrypt the partition twice and voila, I had an sd4 encrypted disk.  I went back into the installer with the ‘exit’ command and installed OpenBSD as normal on the new sd4 encrypted partition that was visible.

Now for the acid test.  Without changing anything in Grub2, I rebooted and selected my “OpenBSD” menu entry.  Drumroll… Yep.  Everything worked!  I now have a Thinkpad T440p (hotrodded with a T450 touchpad, a 1080p IPS panel, 16 GB of RAM and an i7 4712MQ processor) running Coreboot instead of the stock BIOS with three SSDs, all encrypted with a nice menu to choose between OpenBSD 6.6, Ubuntu 19.10 and Windows 10 – all with full disk encryption!

By the way, if you are thinking about Corebooting a Thinkpad T440p, remember two things:

  1. You can’t use the stock 4.11 codebase, you need to add the special patches from “Archfan”.
  2. The OctoPerf site has a great breakdown of what you can upgrade with links to the magic necessary to get Windows 10 to allow you to install (and keep!) the driver for the Thinkpad T450 trackpad that replaces the horrific “clunkpad” that came with the T440p.

Happy Corebooting!

The Key to the Kingdom!

Hi everyone.  It’s been a few months since I last posted and I wanted to let everyone (who probably already knows about this wonderful tool) know about something I’ve just started using full-time.  If you aren’t familiar with it, there is a great “physical token” device out there called a “Yubikey.”  The purpose of this device is to use as a second factor (among other purposes) so that even if a bad actor manages to get their hands on your userid and password, they still can’t log into a device / site without also physically possessing the token.

There is similar technology where a text message with a one-time use code is sent to your mobile phone, but I’m not a fan of that given that someone could clone your SIM and have that text message directed at them instead of you.  This famously happened with Krebs on Security a few yearsa ago with his PayPal account.

The Yubikey is basically a USB device that you carry with you and you plug into your laptop’s USB type-A port when you want to log in.  There is a USB type C version (and apparently a two-headed beast that is USB-C and Lightning for iPhone users) but this one works best for me.  There is a little contact circle on it that lights up when the key is active and for some use cases, you touch that lighted circle for it to spit out the secret key associated with the device as if it were a USB keyboard attached to your laptop.  For multi-factor login, you don’t have to do this, you simply have to have a secret installed to the second “slot” on the key using the HMAC-SHA1 algorithm, not FIDO (which requires online access to a centralized server – not the use case I’m looking for).

The Yubikey I purchased is the Yubikey 5 NFC which also includes the ability to do NFC communication with cell phones.  I haven’t found a good use for that capability yet in my workflow, but I figured it was worth the extra few dollars to know that, if I do, I have the technology.

Setting up a Yubikey for multi-factor auth on Windows or Linux login isn’t exactly rocket science, but it is slightly challenging so I thought I’d document the process here.  There are other places you can use your Yubikey such as SSH logins, validating your GitHub connectivity, accessing your password vault in a variety of tools (Lastpass and Keepass), getting into your Facebook account and others.

For Windows 10 on my laptop, I run the “Pro” version.  There is software you can download from the Microsoft Store for Windows 10 Home / Windows Hello (if you have the IR camera capability on your laptop which I do not).  Unfortunately it seems to be not a multi-factor solution but a “skip the login screen if you have your key inserted” which I’m not a fan of.  I want true multi-factor auth in case someone steals my laptop and my Yubikey – I want them to have to know my password too.


To get the multi-factor auth software from Yubico that works in an offline mode with the HMAC-SHA1 secret on Windows 10 Pro, you do have to sign up for access to the early release code.  At the time I wrote this, it was not generally available yet.  However, before you install this software, you do need to configure the “slot 2” secret on your Yubikey.  To do this, install the Yubikey Personalization Tool from their website.  Run it with your Yubikey inserted into your laptop’s USB port.

Click on the “Challenge-Response” tab at the top and select the “HMAC-SHA1” button from the resulting screen.  Select the “Configuration Slot 2” radio button, click the “Generate” button and then press “Write Configuration” to save it.  You have the opportunity to save your key in a text file (which you can then print out if you wish to do so), but regardless, it will write the updated value to your device.  Once you have done this one time, there is no need to repeat the process so please don’t make the mistake of setting up Windows with the key and then replacing the secret in your device when you do Linux.  If you do so, you won’t be able to log into Windows again because you have wiped out the key’s secret when you reprogrammed it a second time.

OK.  Down to setting this up in Windows.  Before you do this, I strongly recommend that you create a local admin account so that if you mess things up, you can use it to log into your machine.  After you have done this (and just for the sake of sanity, reboot and verify that the account works and that you didn’t fat finger something – better safe than sorry), install the software that Yubico sent you a link to when you signed up for the beta.

You will be asked to reboot.  When you do so, your normal user account won’t work any more so you’ll have to log in as your local admin account you created above.  If you aren’t super familiar with Windows, you can use the .\username approach to log in as a different local user.  After logging in, you’ll need to run the Yubico Login Configurator application that you installed.  You will want to indicate slot 2 as your source for your HMAC and to use the existing secret you already programmed into the key.  Once you have selected this and moved to the next screen, you will be presented with a list of users to enable.  Choose your regular user, insert your Yubikey and press “Next” to complete the process.  At this point you should be able to reboot and log in as your regular user using your password and your Yubikey.  If you’d like, delete the admin account so that the only way you can log into your laptop is with your password and your Yubikey (if you are feeling bold / paranoid like me).


To do this on Linux (in my case, Ubuntu 19.04), you’ll first want to install the libpam-yubico and yubikey-manager packages.  On my particular version of Ubuntu, there was no need to add a third-party PPA as these packages were available in the default repositories.  Next, run the command “ykpamcfg -2” from your user account that you want to enable for two factor authentication.  Don’t use sudo for this, you’ll want it done as your regular user.  You should see that it created an initial challenge and expected response file in ~/.yubico/challenge-####### where ####### is the serial number that is unique to your key.

Now, to configure your system to require the Yubikey for login, you’ll want to add the following line to your /etc/pam.d/gdm-password file (your location might be different if you aren’t using GDM as your login manager like I am) right above the @include common-auth line:

auth    required mode=challenge-response

If you make a mistake with this and manage to lock yourself out of your system, you can boot from a rescue CD, mount your filesystem, remove that line (or fix the typo in it like I had to) and then reboot (or you can create another user, add them to the “sudo” group and then delete the additional account when you are sure everything is working).  I run an encrypted filesystem so this ability to boot from a rescue CD doesn’t worry me as a back door, because an attacker would need to know the very complex password I have on my LUKS encryption.  Also, you can secure LUKS with the Yubikey as well (more on that later).  You should be able to reboot now and not log in unless you supply the correct password for your account along with having your Yubikey physically plugged into your machine.

If you’d like to require your Yubikey to use sudo on your account, then you can add that same line in /etc/pam.d/sudo in the same place.  It works great but I personally found it to be a bit much to have to use the Yubikey every time I run a sudo command versus just when I log in or unlock my screen when the screen saver kicks in.  It’s obviously up to you if you find the additional security to be worth the hassle.

If you’d really like to take things to the next level (and you run an LUKS encrypted filesystem like I do), then you can require your Yubikey to unlock your encrypted filesystem.  First, install the package yubikey-luks.  Then, edit the file at /usr/bin/yubikey-luks-enroll and modify the DISK variable to point to your encrypted volume.  After doing that, run the script as root.  You’ll be prompted for a new LUKS passphrase that will require your Yubikey (and you’ll have to provide your existing LUKS passphrase so that the change can be saved).  Once you’ve done that, you should be able to reboot and the LUKS volume will only unlock with that new passphrase if the Yubikey is installed.

Installing Snort on OpenBSD 6.4

As you may recall from previous posts, I am running an OpenBSD server on an APU2 air-cooled 3 Intel NIC box as my router/firewall for my secure home network.  Given that all of my Internet traffic flows through this box, I thought it would be a cool idea to run an Intrusion Detection System (IDS) on it.  Snort is the big hog of the open source world so I took a peek in the packages directory on one of the mirrors and lo and behold we have the latest & greatest version of Snort available!  Thanks devs!!!

I did some quick Googling and didn’t find much “modern” howto help out there so, after some trial and error, I have it up and running.  I thought I’d give back in a small way and share a quickie howto for other Googlers out there who are looking for guidance.  Here’s hoping that my title is good enough “SEO” to get you here!  🙂

As an IDS, the purpose of Snort is to examine all packets coming from the Internet to your network and from your network to the Internet.  The purpose of this inspection, unlike a firewall such as PF which is looking at ports and ensuring that you only expose the attack surface you mean to, is to use a set of know vulnerability (in the form of “snort rules”) to alert you if there is a problem.  The difference between an IDS and an IPS (intrusion prevention system) is that an IPS takes active steps to protect you, while an IPS like Snort just tells you “you have a problem.”

Installing snort from packages is pretty simple:

# pkg_add snort

After it’s done its thing, you now have a new /etc/rc.d/snort init script, a new _snort user and the snort files (along with dependencies) in the appropriate /usr/local directories.  The log files will show up in /var/snort/log and the configuration files are in /etc/snort.  The first thing I tried to do is run snort from the command line and discovered pretty quickly that it needs to know where its DAQ library (the functions that allow Snort to sniff traffic) is located.  To set this up, add the following line to your /etc/snort/snort.conf file:

config daq_dir: /usr/local/lib/daq

Now, we need to tell it which network represents our “internal” network and which represents the untrusted world of the Internet.  Near the top of the /etc/snort/snort.conf file, you will see the definition of “HOME_NET” and “EXTERNAL_NET”.  For HOME_NET you want to set it to use your local network.  For example, let’s say your local network was a class C network (255 possible IP addresses) at 10.0.5.x, you would use:

ipvar HOME_NET

You then want to define EXTERNAL_NET to be everything but that.  Fortunately, the syntax for this is pretty straightforward:


At this point, you need to install your Snort rules.  There is a free “community” rule-set you can use that has all new rules delayed by 30 days, or you can crack open your moldy wallet, let a few moths out of it and spring $29.95 annually for the personal license for all of the latest & greatest rules.  Given that I like this tool and want to see it continue to be supported (and I want to be better protected), I’ll do the latter.  If you want to go the free route, I’ll leave it as an “exercise for the reader” to figure out how to make that happen.

When you subscribe, you get a userid and password that allow you to log into the website and download the latest ruleset.  Once you have pulled down the tarball (mine was called snortrules-snapshot-29120.tar.gz), scp it over to your OpenBSD router and unpack it in the /etc/snort directory.  Be careful – it will replace your snort.conf file so if you are dumb like me <grin>, you’ll have to re-apply your changes to it after you get confused as to why it isn’t working right.

At this point, you can either play around with Snort in the terminal or, if you are feeling particularly adventurous, make some changes to your rc.conf.local file via the beautiful rcctl tool that the wonderful OpenBSD devs created for us.  On my system, firing up Snort takes some time so I needed to set a timeout to a maximum of six minutes and I also have to pass it the interface I’m using (it defaults to your “first” interface but why take the chance):

# rcctl enable snort

# rcctl set snort flags -i em0

# rcctl set snort timeout 360

With that, a quick “doas reboot” and log back in will have you wondering if it worked.  Tail /var/log/messages until you actually see it spawn the daemon.  That will show you that it actually kicked things off.

At this point, Snort is monitoring your traffic and anything untoward will show up in /var/snort/log in either the “alert” logfile or the “snort.log.*” logfile.  You can find tools out there that will monitor your logs and notify you if something bad happens.  In addition, there is a tool that will keep your snort rules up to date as well that you can slap in a chron script if you’d like.

As I said, short and sweet, but I wanted folks who were interested in running this tool to at least have a good launching point on a more recent version of OpenBSD to hopefully leverage this great open source tool.

Well, it’s been a while – falling in love with OpenBSD again

I was checking the other day and was appalled at how long it has been since I posted here.  I had been working a job during 2018 that had me traveling 3,600 miles by air every week so that is at least a viable excuse.  🙂

So what is my latest project?  I wanted to get something better than the clunky old T500 “freedom laptop” that I could use as my daily driver.  Some background here.  My first paid gig as a programmer was on SunOS 4 (predecessor to Solaris) and Ultrix (on a DEC MicroVAX).  I went from there to a Commodore Amiga (preemptive multitasking in 1985!).  I went from there to OS/2 (I know, patron saint of lost causes) and then finally decided to “sell out” and move to Windows as the path of least resistance in the mid 90’s.

My wife bought me an iPod literally just as they started working with computers other than Macs and I watched with fascination as Apple made the big gamble and moved away from PowerPC chips to Intel.  That was the beginning of the Apple Fan Boi years for me.  My gateway drug was a G4 MacMini and I managed somehow to get in on the pre-production, developer build of an Intel-based Mac.  I was quite happy on the platform until about three years ago.

When the Mac laptop came out without an ESC key (it was on this gimmicky little one row display at the top of the keyboard that could be reconfigured based on your application), as a long-time VI user (the commands are programmed into my spinal cord, I really have no choice now) I was disgusted.  That forced me to recognize that I wasn’t Apple’s target market.  They wanted average computer users who didn’t care if they were on the latest and greatest chipset and they were getting more and more closed and “un-upgradeable” every day.

As much as I would have loved to be on OpenBSD for my daily driver, it seems that Skype for Business (or Lync or whatever they are calling it this week) is like a virus infiltrating the modern enterprise.  I ended up being quite happy on either Dell or Lenovo hardware running Ubuntu LTS on my work machine and Lenovo hardware running the latest & greatest version on my personal machine.  To satisfy my work need for Skype for Business, I ran a domain-joined VM of Windows 10 and felt like the dirty old days in the early 90’s on 16-bit OS/2 when you had to click on the “penalty box” and run a Windows program.

Well, the Ubuntu workflow has now gotten ingrained into me and as I was puttering around in my office, I came across my beloved Thinkpad x230.  I consider that to be the height of good, software-engineer oriented design and well balanced from a travel perspective.  Let me tell you what I mean.  The x220 was nice for the mechanical keyboard lovers (it was the last of the line to have that type of keyboard).  Although I’d love to be a “purist”, I have gotten so used to the chicklet keyboards, the one that they put in that x230 is pretty ideal.  Don’t get me started on the short-throw Apple keyboards – I can’t type my way out of a wet paper sack on those abominations.

Furthermore, unlike most modern laptops, the components on the x230 are all end-user upgradeable.  No RAM soldered to the motherboard, no whitelisted WLAN cards, the ability to have two hard drives, it was nice.  Although the CPU is a bit pokey compared to a “modern” one, it is no slouch and with 16 GB of RAM and a couple of 1TB SSD drives (one in the drive bay and an m2 SATA drive), it has more than enough gas in the tank.  Furthermore, with the 12″ screen and small form factor, it travels pretty darned well.  Also it was among the last to use the power connector that had graced Thinkpads for thousands of years (the round barrel one) which ensured that I had about 6.02 x 10^23 power adapters laying around somewhere in the house at any given time.

Seeing the old girl made me decide suddenly that I wanted to get a daily driver that was as secure (remember my Blog’s name!) and freedom-respecting as I could.  I read up on where things stood with Coreboot (now starting to hit more mainstream laptops) and was really impressed with how well the team had advanced the state of the art when it came to scary things like the Intel Management Engine.  Given that, it was time to get started.

I found a great blog post that had incredibly detailed instructions on what I needed to do in order to get a freedom-respecting, secure version of Coreboot built and installed on the x230 so I ordered a decent Pamona clip (don’t skimp on this – buy the brand name) and when it showed up, I spent about an hour and half building the image on my Ubuntu 18.10 Thinkpad T480 laptop (don’t ever buy the “S” models unless you hate upgrading things down the road) and flashing it onto the old girl.  When I was done, I had a great Coreboot, ME-cleaned, SeaBIOS machine that actually booted up first try!

With that behind me, it was time to wipe out the primary 1TB SSD and install OpenBSD.  I have been a continuous user of this incredible operating system (thanks Theo and the other devs!) for a long time now on my APU-2 firewall (see some of my earlier posts) and I ran it off and on over the years on various laptops.  The goal this time was different.  While this may disgust purists who want me to run FWM as my window manager and stick as close to base as possible, I had really gotten used to my Ubuntu workflow and wanted to see how much of that I could reproduce on this machine.

I started out by installing 6.4 on a full disk encrypted drive (the 1TB primary SSD in the laptop).  After the 4 minute “ordeal” (I love this OS) of doing that, I had a machine that would boot, but I needed to get some firmware to get things cranking.  I haven’t had a chance yet to purchase/replace my WiFi card to an Atheros, so I needed the Intel “iwn” firmware in order to ping out.  Once that was in place, it was time to focus on what I needed in order to have a machine that I could use as my daily driver, despite my “impairment” with the Ubuntu workflow. 🙂

First things first, I needed to do the necessary foo to get my user set up with doas support (I actually aliased doas to sudo on my Ubuntu machine, apparently that was something else I have programmed into my spinal cord – ha!), loaded VIM and aliased vi to it in my .kshrc and added colorls (which I alias ls to for some reason – habit on OpenBSD I guess).  With that, I installed the gnome shell to get a baseline going.  After a bit of a wait (it isn’t lightweight or standalone by any stretch of the imagination, but the fact that there are dedicated folks who keep fighting to make it work on OpenBSD despite the continuing downward spiral of systemd dependencies is a minor miracle).

With that in place, a quick reboot had me logged into a very bright-looking Gnome desktop environment.  I quickly put on sunglasses so that it didn’t blind me and started looking for a theme that would tone things down a bit for me.  I found a nice one called “Yaru-light” (Yaru is the new community theme for Gnome on Ubuntu 18.10) that gave me the right balance of contrast and darkness so that I could safely remove the sunglasses.  I added some OpenBSD wallpaper to the lock screen and the desktop as eye candy, used the Gnome Tweak Tool to get minimize and maximize buttons back and I started to feel more comfortable.

My personal email is on Office365 (don’t ask – it’s a long story involving the fact that I have a family member who loves Outlook on the Mac and it won’t open Google calendars) so I installed Evolution and Evolution EWS and got that working.  There is a bit of a bug when it comes to my folder list that I’m going to install the source to and see if I can fix and push upstream, but I have a workaround for it that I can live with for the time being.  After that, I threw on Libre Office and tweaked the UI to give me the infernal Microsoft ribbon UI that I’ve grown used to despite my best efforts to fight it off.

Printing was a bit of a bear until I realized I wasn’t connected to the same network as my infernal HP printer and then it suddenly got easy.  CUPS and a generic color Postscript driver to the rescue.  When that first page rolled off the printer (after fighting against my own stupidity – I mean come on, can you ping the printer dude?) I felt like the Tom Hanks character in “Cast Away” when he made fire for the first time on the beach!

I threw on “DashToDock” next so that I could get that nice sidebar that I never use.  For some reason I missed seeing it though so what the heck.  I had to install it manually because Firefox wouldn’t connect to the Gnome Extensions stuff correctly.  I later discovered that if I installed the chrome-gnome-shell package and the chromium browser (along with the Gnome extensions plugin for it), that I would easily install extensions from the browser in that.  Must have been a Firefox thing.

Next up was starting to lock stuff down from a security perspective.  I use Firefox as my default browser and am a big fan of the modifications recommended by – I wrote a little script that I keep updated with their latest changes so that I can apply it in a few seconds versus spending 10-15 minutes whacking around in the about:config page in the browser.  The only thing I haven’t figured out how to do is to modify the actual things that I tweak in the “settings” page (default search engine, etc.)

Now for the fun part.  Figuring out how to get my “NextCloud” files synchronized to this beast.  That has always been a challenge for me on OpenBSD.  There is no NextCloud desktop client but I have been told the old OwnCloud client should work – although I never could get it there.  I installed it, ran into the problem I had seen before (near immediate crash once it started downloading files to my local disk) and decided to exercise my Google fu.  Guess what, I found an old post of mine begging for help that some kind soul actually answered long after I had given up.  After some tweaks to /etc/login.conf and /etc/sysctl.conf I was off to the races.  Everything pulled down fine and I tested creating a new file in Linux and whammo – it showed up on the x230!

So in conclusion, I now have my primary workflow reproduced on OpenBSD with the exception of the infernal “Skype for Business” that always forced me into a Windows VM.  I’ve decided that my “new years resolution” (a bit late, don’t you think?) is to use that awful program on my mobile device and say to heck with it on my laptop.  Some remaining work that I need to do includes:

  • Buying an Atheros WLAN adapter off of eBay and installing it, thus eliminating one more piece of proprietary firmware that I have to use
  • Moving to -current with snapshots.  I just discovered that the packages there have Gnome 3.30 (bless you devs for continuing to fight the good fight here!) which may clear up my Evolution annoyance.  If not, time to download the source and see if I can fix it myself.
  • Start to do what I really want to do with OpenBSD – get all of the base Kali Linux pentesting tools into the ports/packages on OpenBSD and create a meta-package that installs them all.  Why should InfoSec professionals be forced to use an insecure operating system (Kali runs everything as root!) to do their jobs.  I’m guessing that this will be the content of a future blog post here.


The $25 “FREEDOM Laptop!”

Time to get back to the original intent of this blog – talking about my paranoid obsession with information security!  So break out your tinfoil hats my friends because this will be a fun ride.  I’m looking for the most open source / freedom respecting portable computing experience I can possibly find and I’m going to document my work in real-time so you will get to experience the ups (and possibly the downs) of that path through the universe.  With that said, let’s get rolling.

I’ve always been fascinated with Richard Stallman, not just as a character, but because he tries to live out his life according to his beliefs.  I’m more of a BSD guy than a GPL person, but the laptop he uses has fascinated me to the point that I have been actively searching for one for myself.  After many months searching for that particular Chinese MIPS based laptop, I thought to myself, “there has to be something I can use.”

When I built my OpenBSD router using the APU2 board, I discovered that there are some amd64 systems that use open source BIOS.  This one used Coreboot and after some investigation I discovered that there was an even more paranoid open source BIOS called Libreboot out there.  That started to feel like it might scratch my itch.  From doing more research, I discovered that after the Intel Core Duo chip, all future “Core i” chips have this lovely thing called the Intel Management Engine embedded in them that basically cannot be disabled without making the machine non-functional after a period of time.  The particularly creepy thing about the IME is that it operates at a layer above the CPU which means that its use, if compromised, could allow an attacker complete control over your system.

Well, after playing around with some lower-powered systems like my APU2 board, my Thinkpad x230 and my SPARC64 boxes, I thought, if it runs amd64 code and I can run an open source operating system on it, the thing should be powerful enough for me to do most (if not all) of what I need it to do.  At this point, I started looking for a viable machine.  From a performance perspective, it looked like the Thinkpad x200, T400, T500 and W500 were all viable candidates.  After paying attention on eBay for a while, I saw something that was either going to be a sweet deal, or a throwaway piece of garbage!

I found a listing for a Thinkpad T500 that said it didn’t come with a power adapter and was 100% untested.  From looking at the photos, it seemed like there was nothing that had been molested about it.  All of the outside and bottom panels that should be there in a working system were present.  Obviously, nobody was jumping on something this risky so I thought, “what the heck” and dropped a bit at the opening price of $24.99.  Yes, you heard that right, $25 bucks!  Well, guess what.  I won the auction.  Now to see what I got.

When the laptop showed up, I discovered it was minus its hard drive (but the outside plastic cover was still in place).  I plugged in my x230’s power adapter and hit the button.  I got lights and was dropped to the BIOS screen.  To my eternal joy, I discovered that the machine I had purchased for $25 was 100% functional and included the T9400 2.54 GHz Core 2 Duo CPU and the 1680×1050 display panel.  W00t!

First things first, I need to get this machine a hard drive and get the RAM upgraded from the 2GB that it showed up with to 8GB.  Good news is that these two purchases only totaled $50 for the pair.  An aftermarket 9-cell replacement battery was another $20. Throw in a supported WiFi card that doesn’t require a non-free blob from Libreboot at $5.99 off of eBay and $5 for a hard drive caddy and I’m looking at about $65 in additional parts bringing the total cost of the laptop, fully loaded up at just over $100.  Not bad at all…

Once all of the parts arrived and were installed, now for the fun part.  Disassembling the entire thing down to the motherboard so we can re-flash the BIOS with Libreboot.  The guide looks particularly challenging for this but hey, I have a nice set of screwdrivers from iFixit and a remarkable lack of fear when it comes to disassembling things.  Should be fun!

NOTE:  A very important step you need to take is to ensure that you have updated the machine to the latest & greatest BIOS from Lenovo before you start the disassembly process.  The update not only flashes the BIOS itself but some other firmware on the board.  Additionally, if you ever feel like you will need a VGA option ROM, extract it now before you start disassembling the machine!

Well, fun didn’t even come close.  I wish I had shot some pictures along the way because at one point I had a heap of parts in one corner of my “workbench” (the dining room table) and just the bare motherboard, minus the CPU sitting in front of me.  With the help of a clip and a bunch of whoops wires (patch cables), I connected my Beaglebone Black to the BIOS chip on the bare motherboard and attempted to read the chip.  #fail

I figured out after doing some more digging that you need to use the connector on the left side of the BBB if you hold it with the power connector facing away from you.  In addition, you should probably read the entire process through instead of stopping at the exciting pinout connector diagram because I missed the bit about the 3.3v power supply need to have ground connected to pin 2 of the BIOS chip.

Speaking of that infamous 3.3v power supply, I managed to bend a paperclip into a U shape and jam it into the connector of an old ATX power supply I had in a closet and source power from that.  I felt like MacGyver for that one!

I was able to successfully read the original Thinkpad BIOS and then flash the Libreboot + Grub2 VESA framebuffer image onto the laptop!  I gulped loudly and started the reassembly process.  Other than having some cable routing difficulties because the replacement WiFi card didn’t have a 5Ghz antenna, it all went back together.  Now for the moment of truth!  I hit the power button and everything worked!!!

At this point I happily scurried to download the latest snapshot of OpenBSD – current and install it.  Well, things got a little weird here.  Looks like I have to use GRUB to boot this machine now and GRUB won’t boot an OpenBSD machine with Full Disk Encryption.  That was a bit of a bummer for me.  I tilted against that windmill for several days and then finally admitted defeat.  So now what to do?  Install Arch?

Well, here’s where I think the crazy caught up to me.  I decided to be an utter sell out and install Ubuntu Gnome Edition 17.04 (since that will be the default DE going forward) with full disk encryption.  I figured I could have fun playing around in a foreign land and try to harden the heck out of that operating system.  I called Ubuntu “grandma’s Linux” because a friend of mine installed it on his mom’s laptop for her but I figured what the heck – let’s see how the other half live!

After running that Ubuntu 17.04 install I have to say I was pretty impressed.  Instead of the normal 45 minute setup time for me with Arch using my cheat notes, I was rebooting into the OS with a nice graphical full disk encryption prompt inside of five minutes.  I love to eat crow so I sent my friend a quick email saying that maybe I was too hard on mee-maw’s laptop OS of choice!  🙂

Now came the fun part of hardening things. I downloaded my new favorite starting point, a tool called “lynis” that sniffs out your system and determines what you can do to improve the security footprint on it.  I did find out that the version that you get from the default package repos on Ubuntu was a bit out of date so I downloaded the latest from the lynis website, built it and installed it.  Problem solved.  I love open source!

After tweaking everything that I thought was reasonable to be tweaked on a non-server OS running a desktop (including adding an encrypted master password to Grub2), I had a reasonable well-hardened system.  Next step was to turn the dial to eleven!  I use a non log-keeping VPN service with an egress point that is outside of the fourteen eyes nations, so I set that up as an on-demand thing for me to switch on in NetworkManager and it worked just fine – with the one exception that I always forget about – IPv6 leaks your actual IP address on the VPN!  So I did some searching and found out to to 100% disable IPv6, did a quick reboot and test and all was well!

I then ran nmap on the localhost interface and found some ports open I didn’t like (SMB, etc.)  Just to avoid my paranoia driving me into a catalepsy, I hopped onto my OpenBSD router and did an nmap scan of the laptop from the outside (still on the LAN though).  Sure enough, the default firewall configuration was not exposing those ports so I was OK.  Now I installed the latest version of the TOR browser and configured my default Firefox to how I like it from the great guide at so that I had a minimal footprint even when running outside of the limited protection that TOR gives you.

Now for the thing that most of my security brethren will laugh at me for doing – installing ClamAV with on access scanning.  Even though I am quite careful about what I click on, I figure it never hurts to have that extra layer of protection.  I set up ClamAV with FreshClam to automatically refresh my subscriptions, made the necessary tweaks to the /etc/clamav/clamd.conf file and voila – I had something that automatically detected and deleted and suspected viral-infected files with a nice Gnome3 popup showing what happened.

At this point, while I didn’t have what I originally set out to do – build a laptop with Libreboot and OpenBSD, I did have a nice compromise that is as well hardened as I can possibly make it and very functional in terms of being able to do what I need to do on a day to day basis.  Do I wish it was more portable?  Of course.  This thing is like a six or seven pounder.  However, I feel much more secure in knowing that the vast majority of the code running on this machine is open source and has all the eyes of the community on it, versus something that comes from a vendor that we cannot inspect.  My hope is that someone with the talent (unfortunately I lack those skills) takes an interest in getting FDE working with Libreboot on OpenBSD and I will most happily nuke and repave this “ancient of days” machine to run that!

Let me know if you enjoyed this post please!  Keep the cards and letters coming.  🙂

DragonFlyBSD Desktop!

If you read my last post, you know that I set up a machine (Thinkpad x230) with UEFI and four operating systems on it.  One, I had no experience with – DragonFlyBSD (other than using Matthew Dillon’s C compiler for the Amiga back in the day!) and so it was uncharted territory for me.  After getting the install working, I started playing around inside of DragonFlyBSD and discovered to my delight that it was a great operating system with some really unique features – all with that BSD commitment to good documentation and a solid coupling of kernel and userland that doesn’t exist (by design) in Linux.

So my goal for my DragonFlyBSD desktop experience was to be as BSD as I possibly could.  Given that (and since I’m the maintainer of the port on OpenBSD <grin>), I went with Lumina as the desktop environment and XDM as the graphical login manager.  I have to confess that I really like the xfce terminal application so I wanted to make sure I had that as well.  Toss in Firefox, libreOffice and ownCloud sync client and I’m good to go!

OK.  So where to start.  First, we need to get WiFi and wired networking happening for the console at login.  To do that, I added the following to /etc/rc.conf:

ifconfig_wlan0=”WPA DHCP”

I then edited /etc/wpa_supplicant.conf to put in the details of my WiFi network:


A quick reboot showed that both wired and wireless networking were functional and automatically were assigned IP addresses via DHCP.  Next up is to try getting into X with whatever DragonFlyBSD uses for its default window manager.  A straight up “startx” met with, shall we say, less than stellar results.  Therefore, I used the following command to generate a simple /etc/X11/xorg.conf file:

# Xorg -configure
# cp /root/ /etc/X11/xorg.conf

With that file in place, I could get into the default window manager, but I had no mouse.  After some searching and pinging folks on the mailing list, I was able to figure out what I needed to do.  I added the following to my /etc/rc.conf file:


I rebooted (I’m sure there is an easier way to get the changes but I don’t know it… yet) and was able to get into a basic X session and have a functional mouse.  Next up, installing and configuring Lumina!  To do that, I went through the incredibly torturous process of installing Lumina:

# pkg install lumina

Wow!  That was really, really hard.  I might need to pause here to catch my breath. 🙂

Next up, jumping into Lumina from the console.  To do that, I created a .xinitrc file in my home directory with the following:

exec start-lumina-desktop

From there, I could “startx” until my heart was content and bounce into Lumina.  That wasn’t good enough though!  I want a graphical login (specifically xdm).  To do that, I had to do a little research.  The trick on DragonFlyBSD is not to add anything to /etc/rc.conf like you do in other BSDs, it’s a bit more old school.  Basically you need to edit the /etc/ttys file and update ttyv8 to turn on the xdm daemon:

ttyv8    “/usr/X11R6/bin/xdm -nodaemon”    xterm    on    secure

The other thing you need to do is set it up to use your desktop environment of choice.  In my case, that’s Lumina.  To do that, I needed to edit /usr/local/lib/X11/xdm/Xsession and change the next to the last line in the file to launch Lumina:

exec /usr/local/bin/start-lumina-desktop

I then crossed my fingers, rebooted and lo and behold had a graphical login that, when I actually didn’t fat finger my password from excitement, put me into the Lumina desktop environment!

Next up – I need a cool desktop wallpaper.  Of course that’s way more important that installing application or other stuff!  After some searching, I found this one that met my needs.  I downloaded it to a local ~/Pictures directory and then used the Lumina wallpaper preference application to add the directory containing the picture and set it to automatic layout.  Voila!  I had a cool DragonFlyBSD wallpaper.

Next I installed the xfce4 terminal program by doing:

# pkg install xfce4-terminal

I then went into the Lumina “All Desktop Settings” preferences, found the applet for the “Menu” under “Interface Configuration” and swapped out “terminal” for “Xfce Terminal”.  I then configured Lumina further to have a 26 pixel thick, 99% length bottom center panel with the following gadgets in it (in this order):

Start Menu
Task Manager (No Groups)
System Tray
Battery Monitor

I then went into my Appearance | Window Manager gadget and set my Window Theme to “bora_blue” (my favorite out of the defaults supplied).  I then installed my remaining applications that I needed in order to have a functioning desktop:

# pkg install owncloudclient qtkeychain evolution evolution-ews firefox libreoffice

After that, I really had a nicely functioning desktop environment!  By the way, the performance of DragonFlyBSD is pretty impressive in terms of its day to day usage.  Keep in mind I’m not doing any official benchmarking or anything, but it sure feels to me to be just as fast (if not faster) than OpenBSD and FreeBSD.  I know that the kernel team has done a lot to unlock things (which FreeBSD has done and we are starting to do on OpenBSD) so perhaps I can attribute the “snappiness” to that?

As you can see, although there isn’t as much documentation on the Internet for this BSD, you can get a really nice, functional desktop out of it with some simple (and intuitive) configuration.  I’m really looking forward to living in this system for a while and learning about it.  Probably the first thing I’ll do is ring up the port maintainer for Lumina and see if we can’t collaborate on getting Lumina 1.3 moved over to it!  Give this one a try – I think you’ll find that its a very nice operating system with some very cool features (the HAMMER filesystem for one!).

Boot All The Things!

Frequent readers of this blog probably know I’m a big fan of free and open source software and also that I have a warm spot in my heart for the BSDs – especially OpenBSD.  Unfortunately, some of the tools I need to do my job just simply aren’t available on the BSDs and rather than sully myself with some nasty proprietary operating system from some company in Washington state, I will typically use Arch Linux to get work done.  On those rare occasions where I absolutely have to run the NSA endpoint known as Windows, I will run it in a VM and quickly shower afterwards.  🙂

Sometimes getting dual booting working can be a bit of a pain.  But, as a guy who likes to turn his guitar amplifier to 11, I started wondering how much self-inflicted pain I could take if I wanted to set up the most massively over-engineered laptop that would use rEFInd to partake of ALL of my favorite operating systems just by simply rebooting.  Well, not one to back down from an entirely self-imposed challenge, I decided to give it a go with my trusty old test laptop, a Lenovo Thinkpad x230 with a 1 TB SSD drive and 16 GB of RAM.

I’ll note that along the way I managed to trip over my own shoelaces several times and wiped out up to 4 working operating systems with one poor choice so this path isn’t for the faint of heart!

NOTE:  Pro tip here – I spent a fair amount of time chasing my tail with UEFI problems until I pulled my head out of… well, let’s just say a dark and smelly place <grin>, and checked the age of my Thinkpad x230’s BIOS.  Turns out it was created somewhere along the same time that the Battle of Hastings.  I found this great resource that pointed out how I could update to the latest BIOS without having to install Windows and it solved SOOOOO many problems for me.  Save yourself some pain and make sure your BIOS is updated, regardless of what hardware you are using.

The Goal

Be able to multi-boot the following FOSS operating systems using rEFInd to select between them:

  1. Arch Linux
  2. DragonFlyBSD
  3. FreeBSD
  4. OpenBSD
  5. NetBSD

So without further ado, lets download the install images, burn them to thumb drives and get started feeling the pain!

Arch Linux

I decided to start by installing Arch with EFI support and the bootctl bootloader using an encrypted partition.  I downloaded the latest media and put it on a thumb drive:

# dd if=archlinux-2017.06.01-x86_64.iso of=/dev/sda bs=1M
# sync

It kills me to have to use that uppercase M (in BSD-land it is lowercase!) but I then had a thumbdrive I could boot from on the x230 and start the Arch install.  It’s always a good idea to start with the lsblk command to ensure you know what disk names were picked at boot time as they can vary.

# timedatectl set-ntp true
# gdisk /dev/sda

The commands I issued in gdisk were first ‘o’ to create a new GPT partition table for the drive, then ‘n’ to create a 200M /boot partition of type ef00 (EFI), and finally ‘n’ again to create a 180G data partition with the standard Linux partition type. Then I create the encrypted volume and slice it up into /root, /home and swap:

# cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -i 5000 -y luksFormat /dev/sda2
# cryptsetup luksOpen /dev/sda2 crypt
# lvm pvcreate /dev/mapper/crypt
# lvm vgcreate lvmpool /dev/mapper/crypt
# lvcreate -L 100GB -n root lvmpool
# lvcreate -L 32GB -n swap lvmpool
# lvcreate -l 100%FREE -n home lvmpool
# mkfs.fat -F32 /dev/sda1
# mkfs.ext4 /dev/mapper/lvmpool-root
# mkfs.ext4 /dev/mapper/lvmpool-home
# mkswap /dev/mapper/lvmpool-swap
# swapon /dev/mapper/lvmpool-swap

Now it’s time to mount all of that and install the base system:

# mount /dev/mapper/lvmpool-root /mnt
# mkdir -p /mnt/boot
# mount /dev/sda1 /mnt/boot
# mkdir -p /mnt/home
# mount /dev/mapper/lvmpool-home /mnt/home
# pacstrap -i /mnt base base-devel

Create the /etc/fstab for the new system and chroot into it:

# genfstab -U /mnt >/mnt/etc/fstab
# arch-chroot /mnt /bin/bash

Go ahead and install Arch as you normally would.  Uncomment en_US.UTF-8 in /etc/locale.gen, run locale-gen, add LANG=en_US.UTF-8 in /etc/locale.conf and:

# tzselect
# ln -sf /usr/share/zoneinfo/Zone/SubZone /etc/localtime
# hwclock –systohc

Edit /etc/mkinitcpio.conf and insert encrypt and lvm2 between block and filesystems hooks:

# mkinitcpio -p linux

Install the bootloader:

# bootctl install

Edit the /boot/loader/entries/arch.conf file and put in the following:

title   Arch Linux

linux  /vmlinuz-linux
initrd  /initramfs-linux.img
options cryptdevice=/dev/sda2:crypt ro root=/dev/mapper/lvmpool-root rw

Change the hostname of your system by editing /etc/hostname then install the necessary wifi software:

# pacman -S iw wpa_supplicant dialog

Use the passwd command to set the root password and then finally enable the dhcpcd service:

# systemctl enable dhcpcd.service

Now, we need to install rEFInd:

# pacman -S refind-efi
# refind-install
# efibootmgr –create –disk /dev/sda –part 1 –loader /EFI/refind/refind_x64.efi –label “rEFInd Boot Manager”

Hit CTRL-D to exit the chroot environment, unmount the /mnt partitions using umount -R and reboot the new system.  NOTE:  Don’t forget to set your BIOS settings to boot UEFI first or you won’t be able to pull anything up.

If you did everything right, you should be presented with a password prompt to decrypt your volume.  If you did what I always do and fat finger the /boot/loader/entries/arch.conf entry for initrd as “initrc” then just boot off of your thumb drive, decrypt the volume, mount things up, chroot into it and fix your typo.

When you boot up, start the dhcpcd service so you have access to the Internet:

# systemctl start dhcpcd.service

Reboot to verify that everything is working and then install the rest of your packages and configure everything the way you like it.


Now I’m back in my element!  So, I pulled down the install61.fs image from my favorite mirror site in Toronto, dd’ed it to a thumb drive and booted.  On the x230, you have to modify the firmware to boot in legacy mode first or it won’t properly boot.  To save me the trouble of doing math to calculate what sector I wanted my OpenBSD partition to start in, I just used gparted and created a 180G unformatted partition that I’ll repurpose on the OpenBSD side of the world.

After booting the installer thumb drive I immediately dropped to the shell to modify the partition to type A6 using fdisk:

# fdisk -e sd0
fdisk: 1> edit 2
Partition id:  A6
Partition offset: [enter]
Partition size: [enter]
Partition name: OpenBSD
fdisk:*1> write
fdisk:  1> quit

Now that we have an OpenBSD partition on the drive, we need to use disklabel to create an encrypted slice:

# disklabel -E sd0
> a
partition: a
offset: [enter]
size: [enter]
FS type: RAID
> w
> q
# bioctl -c C -l /dev/sd0a softraid0

After entering and confirming my passphrase, I exited back to the installer, making note that my encrypted volume was mounted as sd3.  I told the installer to install to sd3 using the whole disk and modified the auto layout to be the way I like it.

Now I needed to do some voodoo in order to get rEFInd to work properly.  Since I didn’t let OpenBSD have its way with the disk, it has no knowledge of my EFI partition and thus couldn’t put its EFI loader into it.  To work around this, I booted back into Arch, downloaded the BOOTX64.EFI file from the mirror and plopped it down into the EFI directory:

# cp /tmp/BOOTX64.EFI /boot/EFI/BOOT/bootx64_openbsd.efi

Let’s take a second to clean up rEFInd so that we get an Arch icon and an OpenBSD icon. To do that, either boot Arch (which will mount the EFI partition under /boot) or just mount the darned thing in OpenBSD (doas mount /dev/sd0i /mnt) and navigate to the EFI/refind folder.  In there, edit the refind.conf file and add the following:

hideui hints
scanfor manual
menuentry “Arch” {
icon \EFI\refind\icons\os_arch.png
loader \EFI\systemd\systemd-bootx64.efi
menuentry “OpenBSD”
icon \EFI\refind\icons\os_openbsd.png
loader \EFI\boot\bootx64_openbsd.efi

Stick this icon in the EFI/refind/icons directory as os_openbsd.png and you’ll be good to go.

Testing it worked just fine.  I rebooted and was able to see the entry on the screen in rEFInd and selecting it presented me with the drive password prompt which, when entered allowed me to boot to a login prompt.  I logged in as root and configured /etc/doas.conf to allow anyone in the wheel group to escalate their privileges and then added my local user to the wheel group:

# echo “permit keepenv persist :wheel as root” > /etc/doas.conf
# usermod -G wheel <my_user>

I added /etc/installurl to point to my favorite mirror ( and ran syspatch to patch me to the latest level for my release.  At this point, I logged out and back in as my local user and installed the gnome desktop environment:

# pkg_add gnome
# rcctl enable avahi_daemon
# rcctl enable gdm
# rcctl enable messagebus
# rcctl enable apmd
# rcctl set apmd flags -A
# echo ‘multicast_host=YES’ >> /etc/rc.conf.local

Wow.  That was hard, wasn’t it?  Reboot and you should be staring at the GDM login screen.  You can now install the rest of the package you want for OpenBSD.  My favorites are libreoffice, firefox, chromium, evolution and evolution-ews.


Interestingly enough, the first dozen times I tried this (lol – I made a lot of mistakes and wiped out previous work) I discovered that DragonFlyBSD will try to boot my FreeBSD partition if it has a lower partition number on the disk.  I’m still looking for a workaround for that but in the meanwhile, I solved the problem by just installing DragonFlyBSD first and then FreeBSD next.

Since DragonFlyBSD 4.8 supports EFI, I downloaded the installer, dd’ed it to a thumb drive and booted it up.  The installer for DragonFlyBSD is interesting in that you are actually booting a live image.  Depending on who you log in as you are either in a shell (user=root) or the installer (user=installer).

I logged in as root and once I was at the shell prompt, I started poking around in man pages and discovered to my delight that it feels very much like OpenBSD so I was much more at home than I expected to be.  After some research, I discovered that there are two disk partition management tools: fdisk for MBR partition schemes and gpt for GPT schemes.  Since my disk is a GPT scheme, that’s the one I use.  By issuing the following command, I was able to show my GPT partitions on the disk:

# gpt show da0

Sure enough, there were my six partitions numbered 0 through 5:

  • 0 – EFI partition
  • 1 – Linux encrypted container
  • 2 – OpenBSD encrypted slice

I will be adding a fourth partition for DragonFlyBSD and will then be using disklabel to create the necessary filesystems to install things.  To do that, use the following gpt command:

# gpt add -s 377075713 da0

The command returns the name of the partition created.  In my case that was da0s3.  Now I use disklabel to create the filesystems:

# disklabel -B -r -w da0s3 auto
# disklabel -e da0s3

The -e switch pulls up a file in vi that you need to add the following lines to:

a:    1g    0    4.2BSD
b:    32g    *    swap
d:    *    *    HAMMER

Save the file and you should be good to move on to the next step.  I tried multiple times to get an encrypted filesystem working by following these instructions; however, I kept running into panics on boot and my search of the mailing list archives was fruitless so I ended up going with an unencrypted setup.

First, set up the filesystems for your DragonFlyBSD slice, mount them and copy the contents of the install thumb drive’s filesystems over to the new filesystems:

# newfs /dev/da0s3a
# newfs_hammer -L ROOT /dev/da0s3d
# mount /dev/da0s3d /mnt
# mkdir /mnt/boot
# mount /dev/da0s3a /mnt/boot
# cpdup /boot /mnt/boot
# cpdup / /mnt

Update your /mnt/boot/loader.conf to include a reference to your disk:


Update your /mnt/etc/fstab to include:

/dev/da0s3a /boot ufs rw 1 1
/dev/da0s3b none swap sw 0 0
/dev/da0s3d / hammer rw 1 1

Now we need to set up the EFI bootloader for rEFInd.  To do that mount the EFI partition and do the following:

# mkdir /tmp/boot
# mount_msdos /dev/da0s0 /tmp/boot
# cd /tmp/boot/EFI/BOOT
# cp /boot/boot1.efi bootx64_dragonflybsd.efi

I tried editing the refind.conf file in DragonFlyBSD but I got a bunch of unprintable characters in it so I rebooted to Arch and finished.  Add the following to /boot/EFI/refind/refind.conf:

menuentry “DragonFlyBSD” {
icon \EFI\refind\icons\os_dragonflybsd.png
loader \EFI\boot\bootx64_dragonflybsd.efi

Download the png file from here and put it in /boot/EFI/refind/icons.  Finally, unmount your partitions and reboot:

# cd /
# umount /tmp/boot
# umount /mnt/boot
# umount /mnt
# reboot


If you intend to run DragonFlyBSD as well, STOP!!!  Please go back and read my note at the top of the DragonFlyBSD section.  You have to install it first and THEN install FreeBSD if you want things to work ok.  Back to your regularly scheduled programming…

OK.  Time for some uncharted territory for me.  I’ve installed one FreeBSD box that I use as a webserver and a mailing list server but I did it up in DigitalOcean so now I get to actually go through the nitty gritty of creating a similar setup that I have in Arch and OpenBSD.  I want to have encrypted swap and an encrypted filesystem and run Gnome 3 as my desktop environment.  But hey, its a BSD so how hard can this be?

First off, I downloaded the latest production memstick image file from the FreeBSD master FTP site.  I dd’ed it onto a thumb drive and booted from it.  (What a fancy installer you guys have BTW!)  I started the install process and when I got to Partitioning, I dropped out to a shell.  This being a BSD, I expected (and received) very detailed man pages on the commands I was about to run.

My boot drive was ada0 so a simple gpart list ada0 showed me the four partitions I already expected to be there (my EFI partition, my Linux encrypted container, my OpenBSD encrypted slice and my DragonFlyBSD encrypted slice).  Leveraging a HOWTO on the FreeBSD forums, I did the following to set up a swap partition, a boot partition (unencrypted and UFS) and my main encrypted ZFS filesystem partition:

# gpart add -t freebsd-swap -s 32G -a 1M -l FreeBSD-swap /dev/ada0        #(creates ada0p5)
# gpart add -t freebsd-ufs -s 10G -a 1M -l FreeBSD-ufsboot /dev/ada0        #(creates ada0p6)
# gpart add -t freebsd-zfs -s 170G -a 1M -l FreeBSD-enczroot /dev/ada0    #(creates ada0p7)

The next step was to set up the ufs boot partition and mount it so I can access it:

# newfs -L ufsboot -S 4096 /dev/ada0p6
# mkdir /tmp/ufsboot
# mount /dev/ada0p6 /tmp/ufsboot

Now I need to create and attach to my encrypted GELI container:

# mkdir -p /tmp/ufsboot/boot/geli
# dd if=/dev/random of=/tmp/ufsboot/boot/geli/ada0p7.key bs=64 count=1
# geli init -e AES-XTS -l 128 -s 4096 -b -K /tmp/ufsboot/boot/geli/ada0p7.key /dev/ada0p7
# cp /var/backups/ada0p7.eli /tmp/ufsboot/boot/geli/
# geli attach -k /tmp/ufsboot/boot/geli/ada0p7.key /dev/ada0p7

Next, it’s time to set up and configure the ZFS pool:

# zpool create -R /mnt -O canmount=off -O mountpoint=none -O atime=off -O compression=on zroot /dev/ada0p7.eli
# zfs create -o canmount=off -o mountpoint=none zroot/ROOT
# zfs create -o mountpoint=/ zroot/ROOT/master
# zfs create -o mountpoint=/usr/jails zroot/ROOT/master/jails
# zfs create -o mountpoint=/usr/local zroot/ROOT/master/local
# zfs create -o mountpoint=/usr/ports zroot/ROOT/master/ports
# zfs create -o mountpoint=/var zroot/ROOT/master/var
# zfs create -o mountpoint=/var/log zroot/ROOT/master/log
# zfs create -o mountpoint=/usr/home zroot/home
# zfs create -o mountpoint=/usr/obj zroot/obj
# zfs create -o mountpoint=/usr/ports/distfiles zroot/distfiles
# zfs create -o mountpoint=/usr/src zroot/src101
# zfs create -o mountpoint=/tmp zroot/tmp
# zfs create -o mountpoint=/var/tmp zroot/vartmp

The next step is to mount our filesystem where the installer can find it.  To do that do the following:

# mkdir /mnt/ufsboot
# umount /dev/ada0p6
# mount /dev/ada0p6 /mnt/ufsboot
# ( cd /mnt && ln -s ufsboot/boot boot )

Now, create the /tmp/bsdinstall_etc/fstab file for the installer with the following content:

# Device    Mountpoint    FStype    Options    Dump    Pass#
/dev/ada0p5.eli    none    swap    sw,ealgo=AES-XTS,keylen=128,sectorsize=4096    0    0
/dev/ada0p6    /ufsboot    ufs    rw    1    1

At this point, type exit to get back to that fancy installer so we can finish the OS installation.  During the install, I chose to add all of the security hardening options and created a non-root user who I added to the wheel group.

When given the ability to drop to a shell in the new system and make manual changes, choose to do that.  First, edit /boot/loader.conf and add the following:


Next, edit /etc/rc.conf and add this line to mount all ZFS filesystems at boot:


Finally, you need to add the first stage FreeBSD bootloader to your EFI partition:

# mkdir /tmp/efi
# mount -t msdosfs /dev/ada0p1 /tmp/efi
# cd /tmp/efi/EFI/BOOT
# cp /boot/boot1.efi bootx64_freebsd.efi

Edit the refind.conf file on your EFI partition to include the following:

menuentry “FreeBSD” {
icon \EFI\refind\icons\os_freebsd.png
loader \EFI\boot\bootx64_freebsd.efi

At this point, exit back to the installer and reboot.  If you did things correctly, you should see a third icon in rEFInd that allows you to boot to your new encrypted FreeBSD install!

NOTE:  When I was figuring all of this out, I ran into a really weird EFI Framebuffer problem using my ancient BIOS (this went away when I updated it) where it was trying to squash everything into one line of text at the top of the screen that I fixed by adding the following to /boot/loader.conf:


The first thing to do after booting the new system is to update it:

# freebsd-update fetch
# freebsd-update install

After that you should probably reboot and log back in.  Next, I need to give my local user the ability to escalate privileges using sudo so I need to first install that:

# pkg install sudo
# visudo

To set up Gnome as my desktop environment, I first have to install xorg:

# pkg install xorg

This installs approximately 200 packages that make up the dependencies.  Next, install gnome itself:

# pkg install gnome3 gnome-shell-extra-extensions

The gnome package has almost 500 dependencies so it will take a while.  After that is complete, it’s time to do the necessary system configuration.  Gnome apparently requires that the /proc filesystem be mounted at boot time so add the following to /etc/fstab:

proc    /proc    procfs    rw    0    0

Now you need to enable dbus and HAL (required by Gnome).  To do this, add the following lines to /etc/rc.conf:


A dependency of the gnome-tweak-tool is python and it isn’t installed by default.  You should add that now as well:

# pkg install python

Reboot at this point to let all of these changes take effect.  You should be at the gdm login prompt if all went well!  Install any interesting packages you’d like to use on the system (I’d recommend firefox, chromium, libreoffice, evolution and evolution-ews as a start.)


OK.  If FreeBSD was uncharted territory for me because I had only set up one server, NetBSD is going to be another planet as I’ve never used the operating system.  But hey, its a BSD so how hard can it be?

Guess what?  NetBSD as of 7.1 doesn’t support EFI.  However, 8.0 is right around the corner and it does.  Given that, I downloaded the latest nightly build (pro tip – look in the images directory for the install images not the amd64 one) and dd’ed it to a thumb drive. I spent a ton of time (and many wrecked partition tables) trying to get this onto my existing drive and wasn’t successful.  Given that, I’ll wait for 8.0 to be released and save space at the end of the drive for this operating system when it is released.