Encrypted persistent ubuntu livecd (16.10) redux

Posted in Uncategorized on January 9, 2017 by voline

In a previous post I show how to re-master an Ubuntu raring livecd to allow for a LUKS encrypted persistent storage area.  These instructions will not work for Ubuntu 16.10, so I’m writing this blog post to show what needs to be done differently. For a more thorough review of the issue, please see the previous post.

TLDR;

If you just want to patch the iso, I’ve generated an xdelta for the encrypted persistence modifications against the ubuntu-16.10-desktop-amd64 iso.  First make sure you have the xdelta program installed.  Then download this patch, and run the following command:

xdelta patch ubuntu-16.10-desktop-amd64-persist.xdelta \
             ubuntu-16.10-desktop-amd64.iso \
             ubuntu-16.10-desktop-amd64-persist.iso

Updates for allowing encrypted persistence

The following instructions are specific to Ubuntu 16.10, but I suspect that they will work for 16.04 and probably for a few editions after 16.10 (basically until they change the initrd image again).  They are basically the same as in the post on 13.04, except we need to add cryptsetup and and the dm-crypt kernel module to the initrd.

      1. clone this git repository
      2. $ edit_iso.sh ubuntu-16.10-desktop-amd64.iso
      3. Choose yes to editing the initrd
      4. Update the initrd using the following commands. I am assuming that you are running on the ubuntu-16.10-desktop-amd64 livecd.  This matters because your kernel must be the exact same as the kernel on the iso your editing (otherwise you’ll need to get the kernel modules from the filesystem.squash in the iso).
        1. patch -p1 < ubuntu-16.10-desktop-amd64-encrypt-persist.patch
          1. This patch adds in the hook that allows the iso to find and use our encrypted persistence file.
        2. MODDIR=$(ls -1d lib/modules/*)
          cp -vp {,.}/$MODDIR/kernel/drivers/md/dm-crypt.ko
          rsync -uavSP {,.}/$MODDIR/kernel/crypto
          mkdir -p $MODDIR/kernel/arch/x86/crypto
          rsync -uavSP {,.}/$MODDIR/kernel/arch/x86/crypto
          depmod -a -b .
          cp -vp /sbin/cryptsetup sbin/
          cp -vdp /lib/x86_64-linux-gnu/libcryptsetup* \
                  /lib/x86_64-linux-gnu/libgpg-error.so.* \
                  /lib/x86_64-linux-gnu/libgcrypt.so.* \
                  /lib/x86_64-linux-gnu/libpopt.so.* \
                  lib/x86_64-linux-gnu/
          mkdir -p lib/cryptsetup
          cp -vp /lib/cryptsetup/askpass lib/cryptsetup/
          1. Here we are adding dm-crypt and the cryptsetup binary to the initrd.  They used to be included, but apparently were taking out.
      5. Exit the editing shell.Edit both grub.cfg and loopback.cfg so that there is an entry with the kernel parameter persistent.

Now you should have an iso with encrypted persistence capabilities!  Note that I have only tested that the iso works when loopback mounted via grub2.  If you have trouble booting it from a cdrom let me know.  Also, this iso will not likely work when copied to a raw partition, unlike the official isos.  It looks like I need to use isohybrid, but I haven’t looked much further into it.  If anyone knows what needs to be done to add this, a comment would be welcome and I’ll update the xdelta.

Setting up the encrypted persistent file

This was not made explicit in my previous post, so I’ll include how to setup the encrypted file to be used as a backing store (more indepth coverage can be found on this wiki page).  The first thing to keep in mind is that this file must be at the root of an unencrypted partition and I believe that the filesystem on which the file is located must be a FAT filesystem.  I keep my persistent file on the same FAT partition that holds the iso file.  Here’s a command sequence that illustrates how to create the persistent file assuming your current working directory is where you want the file to be located.

# Create file with the size you want to have for storing your data.
# I choose 1Gb here.
dd if=/dev/zero of=casper-rw bs=1M count=1K

# Format as a LUKS encrypted device
cryptsetup luksFormat casper-rw

# Create decrypted device mapper device
cryptsetup luksOpen casper-rw cpersistent

# Create filesystem, it can be any filesystem supported by the initrd.
# In this case I use BTRFS, though XFS or EXT4 should work as well.
mkfs.btrfs -L casper-rw /dev/mapper/cpersistent

# Close LUKS device
cryptsetup luksCLose cpersistent

Setup 32-bit Google Earth on 64-bit Ubuntu/Debian

Posted in Uncategorized on November 4, 2013 by voline

I remember the Google Earth 6.0 days.  It was rock solid.  Worked as advertised.  Then 7.0 rolls around and all I get is grief.  To be fair it may have less to do with the version number than the fact that I’m now trying to run the 64-bit version.

So, why can’t one just run 64-bit Google Earth on 64-bit Ubuntu?  That would be ideal.  However, it is my experience and has been widely reported that the 64-bit version is highly unstable.  I can’t get it to run for longer than 10 seconds.  Its also well reported that the 32-bit version is fairly stable.

Installation

Ok, so installing a 32-bit should be easy if it were packaged well.  Namely, it only depends on lsb-core, which is not architecture dependent.  So when one uses dpkg to install the 32-bit deb on 64-bit Debian, everything will install without complaint.  But then Google Earth will refuse to run because it can’t find the 32-bit libs (mostly x11 libs).

Luckily, its pretty easy to install the 32-bit version of a package with apt, just append :i386 to the end of the package name when using apt-get.  The next trick is figuring out exactly which packages are needed for the binary to run, not difficult.

Solution

So, finally, here’s the simple solution:

apt-get install libglu1-mesa:i386 libgl1-mesa-dri:i386

After which, Google Earth should run just fine.  Make sure that you’ve installed the 32-bit deb and removed the 64-bit one if necessary.

Encrypted, persistent storage on Ubuntu livecd (13.04)

Posted in Uncategorized on September 12, 2013 by voline

When my system fails to boot, I have a rescue usb stick with an Ubuntu livecd which can be loopback booted to be used as a rescue system. Sometimes fixing the issue requires trial-and-error and several boots.  This can cause headaches as the livecd is not persistent by default.  So if there’s several web pages I’m perusing to help solve the problem, they’re gone on the next boot.

Persistent livecd

Good news is that the Ubuntu livecd already supports persistence for a livecd session; the bad news is you have to configure it.  And while its a slight pain in the ass, I’ve not found it too difficult.  I like the method where by a file named casper-rw formatted as an ext3 partition is written to the FAT filesystem on the usb stick.  This makes it easier to resize the persistent storage should I run out of space (I abhor manipulating partition tables, and with they would just go away!).  The biggest pain is that the newer livecds don’t have a grub entry which tells the livecd to boot with persistence, so it must be added each time you boot the livecd.  This is old news though and been known abut and done for a long time.

No Encryption

Now lets say you’re in the middle of trying to figure out why your computer isn’t booting, and determine you need to buy a new harddrive.  Since you’re in your persistent livecd session you can just got to your favorite online retailer and order one up.  That’s all find an good, until several days later you realize that your usb has been lost and it has the password to your online account stored in the firefox profile on the persistent storage.  We wouldn’t want that getting into the wrong hands.  It would be nice if the persistent storage was encrypted so that regardless of whether there was important data on there it  wouldn’t be accessible to the world, should it fall into the wrong hands.

Encryption

There are two obvious methods for encrypting the persistent data:

  1. Use encryption at the filesystem layer, such as ecryptfs, which Ubuntu uses for its “Encrypt Home” feature
  2. Use block-level encryption to encrypt the whole casper-rw block device.

I won’t go much into the first method because I dislike filesystem encryption vs. block layer encryption, partly because there is some information leakage (such as number of files).  However in this context, ecryptfs does have some potential benefits over block layer encryption.    For one, it requires no additional support in the livecd.  All you need to do is follow one of the many recipes for using this feature in Ubuntu.

The second method, involves encrypting the whole block device with a block-level encryption system such as LUKS, which is the linux standard for such things.  Unfortunately, this required additional support in the livecd to support unlocking the device at boot.  Fortunately, the heavy lifting has already been done in this patch to the initrd of the raring desktop iso (ubuntu bug).

The Solution

So until Ubuntu can get this integrated into their iso, here’s how to modify the current iso to add encrypted persistence support.

  1. Download the Ubuntu iso and initrd patch.
  2. Download edit_iso.sh and edit_initrd.sh and chmod +x them.
  3. $ edit_iso.sh <iso file>
  4. edit the initrd
  5. $ patch -p1 < <initrd patch>
    1. Make sure that the patch applies successfully!
  6. add extra crypto modules if desired (the iso by default only comes with aes)
    1. $ rsync -uavSP {,.}/lib/modules/*/kernel/crypto
    2. $ rsync -uavSP {,.}/lib/modules/*/kernel/arch/x86/crypto
  7. $ exit ### to build the new initrd and resume editing the iso
  8. edit grub config
    1. Add “persistent” to the linux command.
  9. finish the other edit_iso questions, with defaults if desired.

Now you should have another iso that you can loopback boot from as you did the original iso, except that this one will boot with luks-encrypted, persistent storage.

NOTE: The luks-encrypted device must have a password slot.  Currently there is no way to use keyfile, and storing a keyfile on the USB would effectively nullify the encryption.  Also, the device must be a file named casper-rw.  It can not be a partition on the usb stick.  This is because there would be no way for the livecd to know which luks-encrypted partition to use (in the case of multiple).  Without encryption, the livecd will search for the persistent storage by looking for a file named casper-rw or a partition with a filesystem with a filesystem label of “casper-rw”.  LUKS devices do not allow tagging or adding of labels (unless you count some UUID scheme).

Connecting to Freenode via Tor using Irssi+SASL

Posted in Uncategorized on July 21, 2013 by voline

Freenode has pretty good instructions on how to connect to their IRC network via Tor with Irssi.  It requires SASL which seems to imply that you can’t use Tor if you haven’t registered via the clearnet.

Anyhow, the current version of the irssi plugin script linked on that page requires an abandoned and inefficient (not that it matters in this case) perl package Crypt::DH if you want to send your password in encrypted form.  If you’re just sending the password as plaintext, then it won’t matter.

Ubuntu doesn’t carry the package for Crypt::DH anymore, but it does have the newer Crypt::DH::GMP, which comes with a compatability module.  The problem is that this compatibility module isn’t 100% backwards compatible.  So I’ve modified the out-dated script from Freenode to support using this newer module, but to fallback to trying to use the old Crypt::DH.

To use, just follow the same instructions on freenode’s tutorial using the script below.  This is a drop in replacement.

cap_sasl.pl

Encrypted filesystem on Mega.co.nz

Posted in Uncategorized on May 18, 2013 by voline

In this article, I will describe a method for creating and sharing on different systems an encrypted directory in a mega.co.nz account (henceforth “mega”).

Why?

You might be asking why one would want to store encrypted files on a system that provides for end-to-end encryption and stores the file data internally encrypted.  The problem boils down to trust.  I’m not ready to trust mega, despite that they might be trust worthy.  Their encryption design is relatively new and this is a reason to be wary, as it hasn’t been time tested.  I’d prefer to use solutions that have been around a while and used by many.

How?

The idea behind the implementation is to use a FUSE filesystem to access mega and then layer an encrypted filesystem on top of that.  This is basically the technique I use for encrypting files I store on dropbox (see here and here).  There is a key difference in how I currently use dropbox, which gives me 2GB, and how I plan to use mega, 50GB.  I’d like to backup large amounts of data to mega encrypted and be able to access that from potentially any computer around the world.  However, I don’t want to delete the originals and to keep them unencrypted on the local disk where the currently reside.  Since I don’t want to keep two copies of the data locally (an encrypted version and the originals), I want a solution that takes the existing unencrypted directory of originals and gives me an easy way to map that into the cipher text of the encrypted filesystem.

In linux there are two major layerable encryption filesystems: ecryptfs and encfs.  I currently use ecryptfs with dropbox and it seems like the more mature and efficient solution.  However, it does not provide the reverse (plain text -> cipher text) functionality mentioned in the paragraph above.  This was requested as a feature in 2009, but the author expresses little interest in the feature and has since closed as “WON’T FIX”, despite offering to help motivated volunteer.  So that discounts ecryptfs.  Luckily encfs does have reversible functionality with the –reverse option.

The other loose end here is a fuse filesystem for mega.  For this, I will be using the megatools (ppa) utilities.

Putting it all together

Here’s a step-by-step procedure.  I assume an mega account is already setup.

Create the reverse mapping on the computer with the originals

mkdir /tmp/MegaDir.enc
encfs --reverse /path/to/data/to/backup /tmp/MegaDir.enc

Sync the encrypted files to mega

megasync -u  <username> -p <password> \
         --local /tmp/MegaDir.enc --remote /Root/<some subdir>
  • You can sync only a subset of fs tree rooted at /tmp/MegaDir.enc and may sync to any directory under the mega /Root directory

Retrieving unencrypted files

Now you want to view these files unencrypted on some other computer.  First install the megatools programs.  Then you may use the megafs program to mount the mega account to the local filesystem and then layer the encfs filesystem over the encrypted diretory to decrypt the files. You will also need the encfs configuration file that was automatically generated above.

scp :/path/to/data/to/backup/.encfs6.xml \
    ~/megafs-encfs6.xml
mkdir /media/megafs /media/megafs.encfs
megafs -u  <username> -p <password> \
       --reload /media/megafs
export ENCFS6_CONFIG=$HOME/megafs-encfs6.xml
encfs /media/megafs/path/to/encrypted/directory \
      /media/megafs.encfs
  • Currently megafs does not support read/write on files.  So you can only get a directory listing.  Not so useful.  However there is an ubuntu ppa with packages patched to allow read support for megafs (source).

And presto!  You’ve got decrypted access to your data.  Make sure you store your password in a safe place and backed up!

NOTE: The process is very similar for ecryptfs.

Running Rebtel One-Click application in wine

Posted in Uncategorized on May 11, 2013 by voline

This was tested on wine 1.5.29 with the Oct 12, 2012 snapshot of winetricks.  Download the Rebtel PC application installer at: http://www.rebtel.com/en/Get-Rebtel

  1. WINEARCH=win32 WINEPREFIX=$HOME/.wine-rebtel winetricks dotnet40
    • The wine install instructions say to install .NET Framework 4.0 in a clean wine prefix using winetricks and must be 32-bit (thus the use of WINEARCH).
  2. WINEARCH=win32 WINEPREFIX=$HOME/.wine-rebtel wine <path to setup installer>/Rebtel-PC-setup.exe

Next comes the problem of starting the application again.  The downloaded exe file is stored in some horrendous path, which probably changed each time an updated exe is downloaded.  If you can find the exe, you can give that to wine and it will run the application.  Not so nice though.

There are reports that using wine to run “rundll32.exe dfshim.dll,ShOpenVerbShortcut C:/users/crass/Start Menu/Programs/Rebtel/Rebtel.appref-ms" should open the application.  However this always gives an error about the url being invalid.  Likewise, if I do “rundll32.exe dfshim.dll,ShOpenVerbApplication <application url found in appref-ms file>", I get another error about the config being different than the installed config (which probably has something to do with the params in the appref-ms file that I’m not using).

Then I figured out I could first run “explorer” and then double click on the desktop icon created. Still this was more steps than I felt necessary. So I tried passing the appref-ms shortcut file on the desktop to explorer and voila!  Here’s the exact command which can be put into a wrapper script to easily run from the command line (changes needed for your specific installation of course).

WINARCH=win32 WINEPREFIX=$HOME/.wine-rebtel wine explorer '%USERPROFILE%\Start Menu\Programs\Rebtel\Rebtel.appref-ms'

Now the problem I’m having is that the rebtel app consistently crashes non-deterministically.  It seems to be related to the use of the gui. But I’ve successfully made an uninterrupted call for a couple minutes without the app crashing.

Another unresolved issue is that the program will not close.  Clicking the close button and selecting the close menu item for the window properties causes the window to disappear and reappear.  I think its trying to minimize to the tray, but I can’t get it to show up there in Unity.

Fix: Session Manager extension missing menu items in Firefox

Posted in Uncategorized on April 5, 2013 by voline

For some time now, most of my Firefox profiles have been missing menu items for the Session Manager extension.  When going to the sub-menu Tools -> Session Manager, the usual menu items like “Load Session”, “Save Session”, “Delete Session”, etc. were not there.  Thus severely limited my session management ability.

Curiously, this wasn’t happening for my main profile.  I looked into a bit, but didn’t find a solution and decided to live without it on my other profiles.

Then I ran across a this bug as I was searching the session manager bugs site.  I tried turning off the Ubuntu Firefox integration extension to see if that would fix it, but it didn’t.  Then I tried setting the extension property “extensions.{1280606b-2510-4fe0-97ef-9b5a22eafe30}.no_splitmenu” to true.  Lo and behold that did the trick!

I still can’t explain why my main profile has the menu items because that setting is false on it.  And its a PITA to remember to do this on newly created profiles.