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.

Congress just sold your online privacy, now what?

The United States Congress just voted on and passed a bill that allows Internet Service Providers to sell your data.  I thought I’d take a moment and first explain why this is “A Bad Thing(TM)”, then tell you what you can do about it.

Given that I’m going to promote this blog post more widely than I normally do, I think it would be a good idea to get everyone who is reading this level-set on some of the technology here.  Your Internet Service Provider, or ISP, is the company that provides you access to the internet.  For example, on my smartphone, my ISP is AT&T.  In my home, my ISP is Comcast (or Xfinity or whatever they are calling themselves these days).  Any time you fire up a web browser and type in a website’s address, two things happen:

  1. A service on the internet called the “Domain Name Service”, or DNS, turns the human-readable website address into a series of numbers or the “IP address” of that website.
  2. Your web browser then connects to that IP address and sends all of the communication between your computer and that site through your ISP.

Unless you have done something to go out of your way to change things, that DNS lookup (think of it as looking up a phone number in a phone book) is performed on a server owned by, you guessed it, your ISP.  Unless you are using HTTPS for your website address, all of the stuff that the site sends you and that you send the site is completely readable by, you guessed it, your ISP.

So if you are going to (please tell me that’s not a real website, I’m afraid to type it in) and browsing the content of that site, your ISP knows (and more importantly saves to a database) all of that “traffic”.  Therefore, the fact that your ISP is now soon to be legally allowed to sell that information to whomever they want to sell it to (they couldn’t before because of this silly little thing called “privacy law”) is a very big deal.

Now you may say, I’m not doing bad stuff, I have nothing to hide.  OK, let’s take a little thought experiment here.  Let’s say that you are looking up articles on weight loss and the bad effects of being overweight and reading them.  Nothing nefarious there, right?  Let’s then say that you have private health insurance – many people do.  Well there’s a revenue opportunity for your friendly neighborhood ISP!  Sell your web traffic to your insurance company!  They’d love to know that you might be overweight.  Then, they can charge you more the next time your premiums change.

Far-fetched you say?  Perhaps, but I think you get the idea.  Privacy is important and, while some folks may take it more seriously than others, bad things can happen if you aren’t legally allowed to protect your privacy.  So what can you, as a regular citizen do about this? First, you can contact your congress person and tell them you don’t like what they did.  Here’s the list of who voted in favor of passing this legislation.  Oh and it also shows how much in campaign contributions they got from the ISP lobbyists.  I’ll leave it up to you to connect the dots there.

Now what can you do to make it harder for your ISP to see what you are doing online?  Given that all of your internet traffic flows through them, it’s kind of hard, right?  Sort of…

First off, install a browser plugin on your laptop or desktop like “HTTPS Everywhere”.  This is a little free tool built by the EFF (an organization I really like and support) that forces as many websites as possible to use HTTPS for connectivity.  What this means is that, while your ISP still knows you went to a particular web page, they don’t know what it said or what you said to it because all of the data is encrypted.  This is the first step in undoing some of this damage.  Unfortunately they still know that you went to the site.

Another thing you can do is to install the Tor Browser Bundle.  What the heck is that?  Well, TOR (the acronym stands for “The Onion Router”) is a technology that routes your web traffic through a series of anonymous computers on the internet so that your ISP doesn’t know where you are heading and the site doesn’t know where you came from.  The only downside to TOR is that it is veeeeerrrrrrrryyyyyy sssssslllllloooooowwwww.  Also, there is some controversy as to who runs these servers on the Internet and what nefarious things they could be up to.  However, it will work in this particular use-case because your ISP won’t know where you went.

Another solution to this problem is to use a piece of technology called a Virtual Private Network (or VPN).  This technology opens a connection from your computer to the VPN service provider’s computer and encrypts all of your traffic before it leaves your machine.  The VPN service provider then forwards your traffic to its final destination and sends the results back to you.  If you used a VPN provider in Dallas TX and your lived in Washington DC, it would look like all of your web traffic originated in Dallas – outside of your ISP’s ability to capture and log.

There are some free ones out there such as proXPN but the free ones generally are slow.  You can purchase a monthly VPN service for typically less than $10 per month.  You do want to make sure you are working with a reputable company and one who doesn’t log all of your traffic (the problem we are trying to avoid) so choose carefully.  I’m a fan of Air VPN but there are others out there who are good as well.  A VPN will slow you down somewhat, but it is way faster than trying to use TOR in my experience.

The only problem with everything we have talked about so-far is that it requires that you have flawless operational security (opSec) 100% of the time.  The one time you forget to use TOR or fire up your VPN client and your data is now captured by the ISP and can be sold to whomever they want to sell it to.  What you really need is something that is always on and more foolproof.

Now you are talking about spending some money.  There are privacy protecting routers you can buy on the internet.  Are they any good?  I don’t know.  Are the companies who sell them any good?  Beats me.  This is the point where I put on my tinfoil hat and suggest a “roll your own” strategy.

What we need is a little computer that sits between your home network and your Internet Service Provider that does all of the encryption, routing, etc. so you don’t have to think about it.  I’m a big fan of the PC Engines APU2 single board computer.  For about $150, you can put together a completely silent (it is air cooled) 2 or 3 “NIC” (network interface card) router that even has its own WiFi capability.  I am a big fan of the OpenBSD operating system because its primary mission is to be secure.  The tagline on the website is “only two remote holes in the default install in a heck of a long time”.

This open source project takes its security very seriously.  I have a blog post that I wrote almost a year ago talking about how to build one of these little gems and turn it into a router/firewall for your home network.  If you start with that, you’ll have something that you can plug between your ISP-supplied cable-modem/router and your home network that will give you some additional security.  It is the launching pad for doing ever better stuff as we will see below.

The next step is that pesky DNS lookup.  Some folks might tell you to use Google’s DNS service or something like OpenDNS and now your DNS traffic doesn’t go to your ISP.  However, we know that Google loves to trade in data so that would probably be “out of the frying pan and into the fire” and OpenDNS is actually owned by Cisco, the largest purveyor of networking equipment in the world – probably not a good place to give that data to either.

This is a job for “DNS Crypt Proxy”!!!!  What this wonderful little open source gem does is take all of your DNS lookups and ship them (encrypted of course) to another country to be resolved.  It adds a tiny (read un-noticable) amount of overhead and gets that data out of the hands of your ISP.  You set this baby up on your APU2 box like I outlined in my blog post above, and your traffic is now significantly more private.

Now, if you want to take it one step further, you can use this wonderful little OpenBSD router you built to route all of your traffic through your VPN all of the time.  Here is a great blog post outlining how to do just that.  You probably want your VPN traffic to exit in a country that is more privacy friendly than the US or our allies.  Do a web search on “fourteen eyes” to understand where you can be more secure.  Some other things you can do are outlined in a website I reference frequently.  Installing the plugins recommended and switching to Firefox instead of Chrome is just good hygiene.

Finally, think about who you are using for web searches.  Don’t use Google if you can avoid it.  They are under no compunctions to protect your privacy.  Look into a search tool like DuckDuckGo (I know, goofy name but whatever).  You can configure your web browser to use that as your search tool by default and they don’t log your searches.  Your web searches can tell the world a heck of a lot about you…

So hopefully this gives you some good tips on how to better protect yourself from your own ISP.  Wait.  What?  Oh, you want to know what to do to help yourself with your smartphone.  Darn.  I was hoping we could skip that part because it’s very hard to do.  Oh well, I’ll give it a shot.

One thing you could do is to carry around a big battery for your APU2 box and duct tape that to your APU2 and your cell phone and only use WiFi to access it with a second cell phone taped to the APU2 to route your traffic to the ISP.  Hmm, while it would work, probably isn’t the most practical thing around.  However, you’d end up with great arm muscles from carrying around the additional weight…

Honestly, the problem with cell phones is that there isn’t a good solution.  For the most part on Android, you can’t install 100% of the plugins that I like for Firefox and there is zero way you can do anything like that on iOS.  The best you can do is to install an “OpenVPN” client “app” on your phone and use a service like AirVPN to route all of your traffic through the VPN.  You are on the hook for remembering to turn it on (because it turns off by itself if you aren’t using it for a period of time).  That’s about all I have right now.  I’ll probably learn more later so stay tuned if I have any better ideas down the road.

Thanks everyone, hope you enjoyed the read.

OpenBSD on Thinkpad X1 Carbon 4th Generation

In previous posts, I’ve detailed my movement away from all things Apple and my configuration of how to get OpenBSD installed on this laptop.  Now that I’ve been using it as my daily driver for a few months, I thought it would be worth revisiting the tweaks and configuration changes I’ve had to make to get really comfortable on this machine.  Given that, here we go…

For my particular model, I decided to turn all of the dials up to 11 in the configuration screens on the Lenovo website.  I have the 1TB NVMe drive, 16 GB of RAM and the 2560×1440 HiDPI display.  The latter has made things a bit interesting but since this is the future, I have been pressing on and solving the problems it has brought about!

The first thing I had to configure, based on some very nice work by Reyk was my /etc/xorg.conf file to turn on the efifb driver since we don’t have Skylake support yet in OpenBSD.  My particular configuration looks exactly like his:

Section "Monitor"
Identifier "default monitor"
DisplaySize 311 170

Section “Device”
Identifier “default device”
Driver “wsfb”

Section “Screen”
Identifier “default scren”
Device “default device”
Monitor “default monitor”

Once you have that in place, you can do a “startx” from the command line to ensure that you have graphics working correctly.  After that, I installed my favorite BSD-licensed desktop environment, Lumina and configured my .xinitrc file to start it for me:

exec start-lumina-desktop

Now we have the fact that the trackpad gets a little wonky (a technical term) using the defaults.  Through some trial and error, I found the following line, added above the “exec start-lumina-desktop” in my .xinitrc gets things working the way I would like them to:

synclient VertScrollDelta=-107 HorizScrollDelta=-107 ClickFinger2=3 PalmDetect=1 PalmMinWidth=5 PalmMinZ=100 HorizHysteresis=50 VertHysteresis=50 ClickTime=50

Next, we have the HiDPI stuff to contend with.  I installed the xcursor-themes package and used the “whiteglass” theme.  By adding the following to your .profile, you will get the “desired” behavior (fonts big enough you can read, etc.) out of the HiDPI setup:

export GDK_SCALE=2
export XCURSOR_SIZE=36
export XCURSOR_PATH=/usr/local/lib/X11/icons
export XCURSOR_THEME=whiteglass

For Lumina, I configured the Lumina Glass color scheme and the Glass (System) theme with a 10 point font size.

With all of this done, you end up with a very usable desktop!

Say my Blog’s name!

Given that the title of this site is “functionally paranoid”, I noticed it had been a while since I had written anything focused on information security.  I thought about what would be a good topic and it hit me – how about my uber paranoid home networking setup?  So, put on your tinfoil hats my friends and buckle up – it’s going to be a wacky ride!

Physical Security

What’s the one thing that everyone forgets when thinking about information security?  Well, one is that there is always some guy named Bob who will mess things up (i.e. humans are the weak link because we can be socially engineered, etc.)  The other thing is that if you have physical access to anything, you can eventually brute force it.  However, there are things you can do to make things more difficult.  Here are some of the pros and cons:

  1.  BIOS passwords – Not something I’m typically impressed with.  Most can be avoided by opening up the machine, closing a jumper and powering it up to reset the NVRAM to factory defaults.  I don’t even bother with them.
  2. Full disk encryption – This one really rings my bell in a positive way.  If you can kill power to the box (either because the bad actor has to physically steal it and they aren’t carrying around a pile of car batteries and an inverter or because you can interrupt power to it some other way), then the disk will be encrypted.  The other beauty of this is that if a drive fails (and they all do eventually) you don’t have to have any privacy concerns about chucking it into an electronics recycler (or if you are a bad, bad person, into a landfill) because that data is effectively gibberish without the key (or without a long time to brute force it).
  3. Two factor auth for logins – I like this one as well.  I’m not a fan of biometrics because if your fingerprint is compromised (yes, it can happen – read about the department of defense background checks that were extracted by a bad agent – they included fingerprint images) you can’t exactly send off for a new finger.  Things like the YubiKey are pretty slick.  They require that you have the physical hardware key as well as the password so unless the bad actor lifted your physical key, they would have a much harder time with physical access to your hardware.

I use full disk encryption and two factor auth via a YubiKey on every piece of gear in my secure home network.

Network Segmentation

This is an area where I could get way more creative, because keeping network traffic isolated to particular subnets or VLANs is a great mechanism to prevent “island hopping”  (thank you Alan Jude and Chris Fisher for TechSnap!) when a bad actor gains access to one of your network resources; however, I’m keeping it simple for now.  The first thing I did was change the default password for administrative access to my ISP-supplied router.  There are some pretty interesting attacks that don’t compromise your machine, but instead use it to run Javascript to log into your non WAN exposed ISP router using the default userid and password and then do things like DNS hijacks, etc. to be able to maliciously impact every device on your network.

Just change the darned password to something else already!  Also, validate that your administrative interface for the thing isn’t exposed to the WAN side of the link.  Believe it or not, some of them ship that way.  I leave the ISP-supplied WiFi access point to provide a network I make available to my guests because it sits entirely outside of my secure network.

The next thing I do is connect the LAN side of the ISP-supplied router to the WAN side of my own router.  I use an APU2 box that I built for around $150 running OpenBSD as my router for my secure network.  I use the wonderful pf firewall that is supplied with OpenBSD to filter packets and map ports as I want to.  It has a very understandable syntax and has great performance.  The LAN side of this router goes to my managed switch (which I hope to replace with switchd running on an OpenBSD box at some point) which serves as the core backbone of my secure network.  Plugged also into this switch is my WiFi access point running in bridge mode for my network so that I can have WiFi access (with a very secure WPA2 password) to my secure network.

I know that any true security expert will scoff that I go to all of this trouble and then hook a WiFi access point up, but this is an area where I tilt the scales away from security towards convenience.  A good long WPA2 password isn’t ideal, but it isn’t crackable in a short period of time without a determined attacker who has lots of horsepower.  For example, a 16-character randomly generated password that uses uppercase, lowercase, numbers and special characters would have so many permutations, that it would take a freakishly long time to brute force.


So security is good, but privacy is good as well.  You might not get hacked, but if you aren’t careful about privacy, you will be leaving breadcrumbs all over the internet – which is not good.  To that end, think about who probably knows the most about your online traffic – that’s right, your ISP.  Even if you do everything over HTTPS and use a VPN, you are probably still using them (or heaven forbid Google!) for your DNS resolution.  Enter DNSCrypt Proxy!  This little jewel takes all of your DNS traffic and egresses it to the Internet outside of your ISPs network.  I actually use a public resolver in Europe for mine.

I use Unbound as my DNS resolver on my local network (with all UDP port 53 traffic redirected to it by pf so I don’t have to configure anything on the clients) and then forward the traffic to DNSCrypt Proxy, caching the results in Unbound.  I notice ZERO performance penalty for this and it greatly enhances privacy.  This combination of Unbound and DNSCrypt Proxy works very well together.  You can even have redundancy by having multiple upstream resolvers running on different ports (basically run the DNSCrypt Proxy daemon multiple times pointing to different public resolvers).

I also use Firefox exclusively for my web browsing.  By leveraging the tips on this page, you can lock it down to do a great job of privacy protection.  The fact that your laptop’s battery drain rate can be used to fingerprint your browser completely trips me out but hey – that’s the world we live in.

For times I am not connected to my secure network, I use a non US-based VPN provider (I like and choose an endpoint that isn’t in a Fourteen Eyes country for egress.  I  have given thought at various times to doing that using pf on my home network but the performance hit is still a bit too much for me.  Likely that will improve over time.  The nice thing about AirVPN is that it uses the OpenVPN client meaning I can run it on my mobile devices as well.

You can get even more secure with things like the TOR browser bundle, but be careful how you configure it.  You can actually make yourself less secure than you think if you aren’t educated on how everything works.

The Cloud

This is where it starts to get weird for most folks.  They have pretty good security hygiene and maybe are fairly good about privacy, but they end up storing everything in a cloud service.  Remember, another way of saying “the cloud” is “some other guy’s computer”.  If you really to care about your privacy, then you should avoid cloud services like the plague.  However, that starts to get really hard and you have the good old balancing act between security and convenience.

I recently decided I would try to live a cloud-free life and I’ll give you a bit of a synopsis on it.  I discovered a wonderful OpenSource project called FreeNAS.  What this little gem does is allow you to install a FreeBSD/zfs file server appliance on amd64 hardware and have a slick administrative web interface for managing it.  I picked up a nice SuperMicro motherboard and chassis that has 4 hot swap drive bays (and two internal bays that I used to mirror the boot volume on) and am rocking the zfs lifestyle!  (Thanks Alan Jude!)

One of the nicest features of the FreeNAS is that it provides the ability to leverage the FreeBSD jail functionality in an easy to use way.  It also has plugins but the security on those is a bit sketchy (old versions of libraries, etc.) so I decided to roll my own.  I created two jails – one to run OwnCloud (yeah, I know about NextCloud and might switch at some point) and the other to run a full SMTP/IMAP email server stack.  I used Lets Encrypt to generate the SSL certificates and made sure I hit an A on SSLLabs before I did anything else.

OwnCloud includes the ability to install plugins and there are some dandy ones out there.  I installed a notes one that had iOS and Android clients (buh-bye Evernote with your attempted changed privacy policy which you rolled back but I see how you really are now).  I also installed a Calendar plugin that had CalDAV support (see ya’ Google Calendar!) and a CardDAV contacts plugin (later Google Contacts).  I got all of them up and running (along with the mail server Jail – use mxtoolbox to check your work here) and can now stop using the main cloud services I had previously been running.

How did I get around my ISP blocking common IMAP/SMTP ports you ask?  I set up a relay server on a VPS server that I rent for $8 per month.  I started out on one based in the US but my better thinking prevailed and I found a provider in a non fourteen eyes country.  Everything seems to be working OK once I got all of the right security / anti-spam bits in place but only time will tell.

This path isn’t for everyone because you are now fully in charge of the security and reliability of your mail / calendar / contact / note infrastructure.  Also, you just increased your attack surface so be extra careful there!


This is another fun one.  You go to all of this trouble and then you store your offsite data backup (you DO back up your data offsite, right?!??!?!!) in some cloud service like Carbonite or CrashPlan.  As convenient and cost-friendly as that is, you have no idea how many copies of your data they make in their datacenter operations and even if you leave them, they are probably still floating around in their cloud infrastructure somewhere.

Enter TarSnap – a company that advertises itself as “Online Backups for the Truly Paranoid”.  It brings a tear to my eye – a kindred spirit!  🙂  Thanks again to Alan Jude and Kris Moore from the BSD Now podcast for turning me onto this company.  It has a very easy command syntax (yes, it isn’t a GUI tool – suck it up buttercup, you wanted to learn the shell didn’t you?) and even allows you to compile the thing from source if you want to.

The way it works is that it encrypts the data on your machine before ever sending out to the network.  As long as you keep your private key on the encrypted drive on the machine you are backing up, it’s pretty darned safe although you might want to keep a copy of it somewhere that is physically secure and preferably offsite (perhaps a GPG encrypted file on your mail relay VPS).  The cost is based on the amount of data you store and the network traffic to get it to/from their service.  However, for the type of data I’m storing up there, it isn’t crazy expensive and it de-dupes the heck out of it to further reduce your costs.

Internet of Things

This is an easy one – avoid any “internet of things” device that connects to anything outside of your network!  That way you avoid these poorly implemented security nightmare devices becoming a public menace and joining a DDOS botnet.

OK, if you absolutely can’t live without your internet connected ice cube tray, the best way to secure these devices is to put them completely outside of your secure network.  Hook them up to the WiFi made available by your ISP supplied router (where I put my guest traffic).  It’s still (theoretically) sitting behind a “secure” router but it sure as heck isn’t on your secure network.

You could do other things like having a VLAN dedicated to them and locking them down by MAC address.  The problem is there is always some clever 8th grader in Germany who will still find a way to exploit them and island hop to your other machines.  Best keep them at arm’s length on the outside of your real router (you do run an OpenBSD router, right!?!??!?!)


There are other things that I’ll want to do eventually (perhaps putting my WiFi traffic on its own network segment with host isolation mode, switching to certificates for my WiFi access, or installing an IDS tool like snort), but for now, this is where I stand.  I’d appreciate any feedback or suggestions from folks out there with ideas on how to lock things down more.

Where the rubber meets the road (part two)

So in my last post, I detailed what it took to get Arch Linux running on my brand spanking new Thinkpad X1 Carbon (4th Generation) and was getting ready to install OpenBSD on the same disk.  In the intervening time, I banged my head against the wall over and over again trying to figure out what my problem was on OpenBSD with not seeing the partition structure correctly on the disk and have finally given up.  Time to NUKE AND PAVE baby!

I backed up my data from Arch to an external drive, downloaded the latest snapshot installer for OpenBSD, burned it to a thumb drive and booted the laptop from it.  My goal is to reverse the approach I took last time and install OpenBSD first.  I’m going to GPT partition the disk and then, once I have it working correctly, reboot into the Arch installer and install Arch second.

After booting the OpenBSD installer, I bailed out to the (s)hell at the prompt and rewrote the partition on my 1TB NVMe drive with:

# fdisk -gi -b 4096000 sd0

This repartitions the drive with GPT and creates a boot EFI volume that is 2G in size.  I then used:

# fdisk -e sd0

to edit the drive and resized the OpenBSD partition to 490 GB in size.  Next, I used disk label to create my encrypted partitions for swap and data:

# disklabel -E sd0

I created an “a” partition (don’t forget to make it RAID type)  hat took the rest of the OpenBSD area for my encrypted data drive.  I then used bioctl to create the encrypted volume:

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

The crypto volume was now available as /dev/sd2 so I used “exit” to get back to the installer and installed OpenBSD on that volume as I normally do.  To be safe, I mounted the EFI partition (/dev/sd0i in my case) and copied the /efi/boot files into /efi/openbsd.  I vaguely recall a Linux installer overwriting the OpenBSD files at some point in my checkered past so it never hurts to be safe.

I then reformatted my thumb drive as FAT32 and grabbed the missing firmware tarballs I needed to, rebooted the new OpenBSD install, and untarred them into /etc/firmware.  After rebooting and verifying that everything was working fine, I downloaded the latest Arch installer, burned it to the thumb drive and booted from that.

I installed Arch as I detailed in my last post; however, when I fired up gdisk I got a weird error message:

“Warning! Disk size is smaller than the main header indicates! Loading secondary header from the last sector of the disk! You should use ‘v’ to verify disk integrity, and perhaps options on the expert’s menu to repair the disk.”

Immediately after this, I saw a second warning:

“Caution: Invalid backup GPT header, but valid main header; regenerating backup header from main header.”

And, not to be outdone, there was a third:

“Warning! Main and backup partition tables differ! Use the ‘c’ and ‘e’ options on the recovery & transformation menu to examine the two tables.”

Finally (not kidding), there was a fourth:

“Warning! One or more CRCs don’t match. You should repair the disk!”

Given all of that, I thought to myself, “This is probably why I couldn’t see the disk properly when I partitioned it under Linux on the OpenBSD side.  I’ll let it repair things and I should be good to go.”  I then followed the recommendation and repaired things, using the primary GPT table to recreate the backup one.  I then installed Arch and figured I was good to go.

Now I was ready to put on rEFInd as my boot manager for switching between the two.  I installed the “refind-efi” package using pacman:

$ sudo pacman -S refind-efi

I then ran refind-install and had what I needed working.  I rebooted to OpenBSD and was greeted with a kernel panic because it couldn’t find my root volume.  Uh oh.

I repeated this process a couple of additional times (starting from scratch, partitioning under OpenBSD, installing Arch, repairing the disk, etc.) and not surprisingly got exactly the same results.

OK.  What to do now.  I decided to rock this old school and dump the whole crazy GPT thing and do this MBR.  After all, I only need three partitions anyhow (the EFI one, the luks encrypted partition for Linux and the softraid encrypted partition for OpenBSD).

I booted up off of the OpenBSD installer thumb drive, jumped out to the (s)hell and did:

# fdisk -i -b 4096000 /dev/sd0

I then resized down the default OpenBSD partition (#3 by the way) to half its size using fdisk, and used disklabel to create a single “a” slice that took up the entire area (make it RAID for the type).  Then, bioctl and I created the encrypted softraid container and I rejoined the installer and installed normally on the new virtual device (sd2 in my case).

Installing Arch was slightly tricker this time because apparently very few people use EFI and MBR together, let alone with luks and lvm.  🙂

The trick was realizing that I couldn’t use systemd-boot as my boot manager because it doesn’t work with MBR nor do they apparently have plans to make it work (I get it, this is the true definition of a corner case).  I dropped back to GRUB for my boot manager with the only trick being that I changed the GRUB_CMDLINE_LINUX variable in /etc/default/grub to be:


I then ran the configuration file generator:

# grub-mkconfig -o /boot/grub/grub.cfg

At this point, I crossed my fingers and booted back and forth (using the F12 boot menu on the Thinkpad and choosing the nvme drive booted OpenBSD and I could choose “grub” from the boot list to boot Linux) between OpenBSD and Arch multiple times to ensure there wasn’t any funny business going on.


Now that I have everything working, I’ll restore my config and data to Arch, configure OpenBSD the way I like it and get moving.  I’ll take some time and drop a note on the tech@ mailing list for OpenBSD to see if they can figure out what the GPT problem was I was running into.  Hopefully it will make that part of the code stronger to get an edge-case bug report like this.