Archive for the ‘Debian & Ubuntu’ Category

Newer Entries »

loop-aes and Debian

Wednesday, December 14th, 2005

This post was lying around, but I never actually popped it up on the blog. I was just playing around with loop-aes on Debian, since I had used it in days long since gone by and had a desire to try it out again. Loop-aes served its purpose for a short period, but over a month has now passed since I touched any of the Debian boxes around here.

(On FreeBSD 6, I just quickly hacked /etc/rc.d/gbde script to support encryption of the device mounted as /tmp with random keys, much like is already available for swap via /etc/rc.d/encswap, and I played around with using encrypted memory disks, so maybe I will do a quick post on that.)

The way one of my Debian workstations was configured, all of my personal data was stored in the partition mounted as “/home”, and I wanted all data written to this partition transparently encrypted before write (and, of course, transparently decrypted on read). I also wanted this functionality applied to the parition mounted as “/tmp” and the swap partition. While I used GPG to provide services for encryption my email and files, I needed something more robust and settled on loop-aes. I say this as if I researched it, but the reality was that I had used loop-aes a while back, and, in slightly more recent times, brought that knowledge back for a project at my previous employer.

As has been read numerous times in previous Debian posts on this blog, I fired up “aptitude” and searched for “loop-aes”. Lo and behold, there it was. I installed the “loop-aes-source” and “loop-aes-utils” Debian packages. Now, as described in the previous post, the “loop-aes-source” was the code for kernel module, and so it had to be custom built for the custom kernel I was running. Well, as we saw before, that can be quite easy.

From the “/usr/src” directory, I extracted (“tar -xvjf loop.aes.tar.bz2″). This created the directory “modules/loop-aes” under the “/usr/src” directory, which contained the loop-aes kernel module source code.

Unhappily, as I looked at the readme for loop-aes (“cat /usr/src/modules/loop-aes/README | less”), I found that I would have to rebuild the kernel after editing the kernels configuration (/usr/src/linux/.config). While “CONFIG_MODULES=y” and “CONFIG_KMOD=y” were proper, “CONFIG_BLK_DEV_LOOP=m” was not and needed to be changed to “CONFIG_BLK_DEV_LOOP=n”. I made the change, cleaned up a few other areas I wanted to tweak in the kernel, and proceeded to build the new kernel image.

I ran the following from “/usr/src/linux”.

  • fakeroot make-kpkg clean
  • fakeroot make-kpkg –append-to-version=.03102005 –revision=10.01.Custom –added-modules=loop-aes kernel_image
  • modules_image

This built a kernel-image and loop-aes into Debian packages, which could be installed as root by running “dpkg -i kernel-image-2.6.8.03102005_10.01.Custom_i386.deb” and then “dpkg -i loop-aes-2.6.8.03102005_10.01.Custom_i386.deb”.

The kernel was installed as “/boot/vmlinuz-2.6.8.03102005″, a System.map was created as “/boot/System.map.2.6.8.03102005″, and the configuration for the kernel was installed as “/boot/config-2.6.8.03102005″. I ran “depmod -v 2.6.8.03102005″ and, then, to create the initrd-img, I run “mkinitrd -o /boot/initrd-img-2.6.8.03102005 2.6.8.03102005″. In “/boot”, I remove the symbolic links for “config”, “initrd.img”, “System.map”, and “vmlinuz”, and replaced them with symbolic links to the 2.6.03102005 counterparts. Finally, I ran “update-grub”, which updated “/boot/grub/menu.lst” to include this kernel and set it as the default, and then I rebooted the system.

That was the easy part. Now I needed to configure it.

First, I needed to activate the loops for loop-aes. I ran “modprobe -r loop” and then “modprobe loop”. This loaded the loop-aes module and created devices “/dev/loop0″ through “/dev/loop7″ by default. In order to have loop-aes automatically loaded during boot up, which I needed for mounting “/home” automatically during boot, I added the “loop” on a separate line in “/etc/modules”.

The readme for loop-aes contained all sorts of useful examples for setting up the system exactly as I wanted it. After reading the readme (“zcat /usr/share/doc/loop-aes-2.6.8.03102005/README.gz | less”), I decided to create keyfile encrypted with gpg for use by loop-aes for encrypting “/home”. I did this with the following commands as “root”, based on an example in the readme for loop-aes.

  • mkdir /etc/loop-aes
  • openssl rand -base64 2880 | head -n 65 | tail -n 64 | gpg –symmetric –cipher-algo aes256 -a > /etc/loop-aes/homekey.gpg
  • chown root:root /etc/loop-aes/homekey.gpg
  • chmod 600 /etc/loop-aes/homekey.gpg

Note: The GPG command above prompted for a password to be entered. This password will be derived into a symmetric key that GPG will use to AES encrypt the keys that will be used to encrypt the “/home” partition. This is one of the weakest links in the chain of this setup, so choosing the longer and more random the password, the better.

After this was completed, I rebooted the system into single user mode. On Debian with the grub bootloader, this was simply a matter of selecting the “Recovery” boot up variant for the kernel desired (2.6.8.03102005 in this case).

My goal was to encrypt swap, “/tmp”, and “/home”. Once in single user mode, I backed up the contents of home (“cd /home; tar -cvjf /root/home.tar.bz2 *”), and then unmounted “/home” (“umount /home”), unmounted “/tmp” (“umount /tmp”), and turned off swap (“swapoff -a”). Next, I edited “/etc/fstab”, placing the configurations for our encrypted partitions at the bottom of the file and commenting our their previous “unencrypted” variants.

    /dev/hda5 none swap sw,loop=/dev/loop1,encryption=AES128 0 0
    /dev/hda6 /tmp ext2 defaults,loop=/dev/loop2,encryption=AES128,phash=random/1777 0 0
    /dev/hda9 /home ext2 defaults,loop=/dev/loop3,encryption=AES128,gpgkey=/etc/loop-aes/homekey.gpg 0 0

Now that the partition for “/home” was going to be encrypted, I needed to reformat it with the following commands.

  • losetup -F /dev/loop3
  • mkfs -t ext2 /dev/loop3
  • losetup -d /dev/loop3

Note: When running this first command, I was prompted to enter the password for the “/etc/loop-aes/homekey.gpg” file. Anytime an attempt to mount “/home” is made, a password prompt appears to enter the password for the “/etc/loop-aes/homekey.gpg” file.

After this was completed, I was turned swap back on (“swapon -a”), mounted “/tmp” (“mount /tmp”), and mounted “/home” (“mount /home”). Next, I extracted my backup of the contents of “/home” into “/home” (“cd /home; tar -xvjf /root/home.tar.bz2 ./”).

Then, I rebooted the system and was good to go.

The negative side effect here was that during boot up, I was prompted to enter the password for the “/etc/loop-aes/homekey.gpg” file as this was required to mount “/home” and mounting of “/home” was configured to happen automatically at boot. I preferred this extra layer during boot, but there are ways to avoid it; however, this avoidance might not be good for the overall security of the configuration.

Note: If this is done on a laptop, beware of suspsend, as it could suspend to disk the plaintext keys for any mounted encrypted partitions. There are steps that can be taken here, such as making sure to manually unmount encrypted partitions and turn off swap before letting a laptop suspend, shutting down a laptop rather than letting it suspend, or having the laptop unmount encrypted partitions and turn off swap automatically as part of the suspend process. The latter can be accomplished using using suspend scripts, but it has the disadvantage of needing a forced unmount that could be problematic to open files contained within the encrypted partition; however, if suspend is configured such that it can occur automatically, then I typically do this as having the plaintext keys written to disk essentially nullifies all of the previous efforts.

—

What reminded me of this lingering blog post was a quick discussion that occured on the Practical Security mailing list. My minor post was bounced, so I will just pop it in down here. (x’s used below so the email addresses are not harvested.)

Date: Tue, 13 Dec 2005 00:07:44 -0500
From: lists <xxxxxxxx@xxxxxxxx.xxx>
To: Alexander Klimov <xxxxxxxx@xxxxxxxx.xxx>
CC: Hagai Bar-El <xxxxxxxx@xxxxxxxx.xxx>, xxxxxxxx@xxxxxxxx.xxx
Subject: Re: [PracticalSecurity] Not-different-enough IVs?

On 12 Dec 2005 12:42:48 +0200, Alexander Klimov wrote:
> On Sun, 11 Dec 2005, Hagai Bar-El wrote:
>> The authors claim that (without encryption) adjacent sectors will
>> have IVs that are just a few bits apart from each other. However,
>> does this matter? Does anyone see the motivation for “hashing”
>> addressed before using them as IVs?
>
> First of all CBC with a non-random IV gives away information about
> plain text: if, say, one (even) sector starts with ‘x…x0′ and the
> next one (odd) starts with ‘x…x1′ (IV is the sector number), then
> the first block of both sectors will be the same.

This made me remember an implementation issue in loop AES (and others),
and a quick Google (loop aes watermark) popped up a post [1] and a paper
[2].

[1] http://www.uwsg.iu.edu/hypermail/linux/kernel/0402.2/1137.html
[2] http://mareichelt.de/pub/notmine/wisa2004.pdf

-Andrew

Posted in Crypto, Debian & Ubuntu | 4 Comments »

Custom kernel build on Debian

Wednesday, September 14th, 2005

Before we begin, we recommend this page for some information on how to build the kernel on a GNU/Linux Debian system. We are just describing the steps we went through for this particular system, but that tutorial is more generic and explains some of the options in more detail.

In our previous post, we fixed two problems someone was having with Debian on the Dell Inspiron 8500. With the screen resolution clean in Gnome and surfing the web over our wireless connection, we got started on building a custom kernel.

When we installed the “kernel-sources-2.6.8″ and “ndiswrapper-source” Debian packages on the system previosuly, two files were created in the “/usr/src” directory, “kernel-source-2.6.8.tar.bz2″ and “ndiswrapper-source.tar.bz2″. “kernel-source-2.6.8.tar.bz2″ contained the source code for the GNU/Linux 2.6.8. kernel in a bzip2 compressed tar archive, and that was what we dealt with first.

To extract the source code, we ran “tar -xvjf kernel-source-2.6.8.tar.bz2″ in the “/usr/src” directory. This created a directory “kernel-source-2.6.8″. We removed the old “/usr/src/linux” symbolic link (“rm -rf /usr/src/linux”) and added a new one (“ln -s /usr/src/kernel-source-2.6.8 /usr/src/linux”). By default, virtually everything would be enabled in the kernel configuration and almost all of these enabled features would be loaded as kernel modules (i.e., not compiled directly into the kernel, but rather, compiled into their own object files and loaded as needed by the kernel). If the kernel was built this way, there would be a large number of kernel modules, many of which would never be needed for the system we were running on. For us, we wanted to configure the kernel in order to support the hardware of the laptop and potential additions to the laptop, but not everything under the sun.

To do this, we ran a “dmesg | less” to see what the output from the kernel was during boot up, including the hardware detected. With this information, we could go in and configure the kernel specifically for the system it was running on. The easiest way we found to configure the kernel was to run “make menuconfig” from the “/usr/src/linux” directory. This presented us with a clean menu for walking through the kernels features. From there, we took the output of “dmesg” and determined what could be safely enabled/disabled. For example, we were configuring this kernel for a laptop and the Dell Inspiron 8500 contains a mobile Pentium 4 with speedstep, so we wanted to turn on power management features and cpufreq. Additionally, for this laptop in particular, most of the main hardware functionality was provided by Intel components, the video card was an nVidia, and the onboard NIC was a Broadcom.

Once we had completed configuring the kernel options, it was time to build the kernel. Since this was a Debian system, we did this the Debian way. If not already installed, we needed to install the Debian “kernel-package” package. (Fired up “aptitude”, and searched for and installed “kernel-package”.) Since we were not going to be running as “root” during our build, we needed to use “fakeroot” to build the kernel image package correctly, so, if not already installed, we installed it. (Fired up “aptitude”, and searched for and installed “fakeroot”.)

Now, you may be wondering why we also extracted “ndiswrapper-source” in our previous post. Well, this kernel module was specific to the kernel it was built for but was not part of the main kernel tree, so it would not automatically be built as part of our kernel build. However, Debian made it easy for us to build this as we build our kernel. When we extracted “ndiswrapper-source.tar.bz2″, it was placed in “/usr/src/modules/ndiswrapper”, which was where it needed to be for the command we were about to execute.

Ok, so we had configured the kernel, and we were now ready to build. The following command wes what we executed to create a custom kernel image and “ndiswrapper” Debian packages.

  • fakeroot make-kpkg clean
  • fakeroot make-kpkg –append-to-version=.11092005 –revision=10.00.Custom –added-modules=ndiswrapper kernel_image kernel_headers kernel_doc modules_image

What did this do?

  • “fakeroot make-kpkg clean” cleaned out the kernel source tree from the last build so that no conflicts or other mismatchings came up. For example, we have seens posts about there being a revision conflict detected in the Debian changelog during build when using “–revision” – this could be solved by doing a make clean.
  • “fakeroot make-kpkg –append-to-version=.11092005 –revision=10.00.Custom –added-modules=ndiswrapper kernel_image kernel_headers modules_image” built a kernel (“kernel_image”) labeled with the version number 2.6.8.11092005 (“–append-to-version”) and created a Debian package (“make-kpkg”) for it, generated kernel headers (“kernel_headers”) Debian package (“make-kpkg”) for this kernel labeled with the version number 2.6.8.11092005 (“–append-to-version”), and built the ndiswrapper source (“–added-modules”) for the ndis kernel module (“modules_image”) labeled for kernel version 2.6.8.11092005 (“–append-to-version”) and created a Debian package for it (“make-kpkg”). All of the Debian packages included the revision identifier (“–revision”) in their filenames, which was the extent of the use of “–revision”.

These packages were all placed in the “/usr/src” directory ending with “.deb”. To install them (you must be root), we ran “dpkg -i <.deb package name>”, where “<.deb package name>” is the name of the package to be installed, and started with the kernel image. Since the software was packaged with the custom version numbers appended to their names, there was no need to put the packages on hold.

The laptop we were using used “grub” as its bootloader. When the kernel-image was installed from the Debian package, it automatically updated “/boot/grub/menu.lst” using “update-grub”; however, not everything was setup correctly for this to work properly.

Since we installed our custom ndiswrapper kernel module, we wanted to be sure all of our kernel module dependencies are configured. In order to do so, we ran “depmod -v 2.6.8.11092005″.

Our kernel was installed as “/boot/vmlinuz-2.6.8.12092005″, a System.map was created as “/boot/System.map.2.6.8.11092005″, and the configuration for the kernel was installed as “/boot/config-2.6.8.11092005″. There was no “initrd-img” created for this kernel. To create the “initrd-img”, we ran “mkinitrd -o /boot/initrd-img-2.6.8.11092005 2.6.8.11092005″.

Next, we ran “update-grub” and rebooted, selecting our new kernel 2.6.8.11092005. All went well, but if it had not, we would have booted into an older kernel, uninstalled the packages, reconfigured our custom kernel, rebuilt the packages, reinstalled the packages, and rebooted.

We are good to go.

Posted in D-Kriptik, Debian & Ubuntu | 1 Comment »

Two issues with Debian on Inspiron 8500

Tuesday, September 13th, 2005

We were recently enlisted to help with the post-installation issues of a Debian distribution (v3.1 Sarge – 2.4.7 kernel) of GNU/Linux on a Dell Inspiron 8500. The install went cleanly enough for the person, and everything was generally working. We were asked to fix two things, the screen resolution (15.4 UXGA) in X Windows (Gnome desktop) and to get the wireless card (Dell TrueMobile 1300) working (with WPA). Also, the person wanted a simple firewall setup.

So, in we dived. First things first, lets do an update/upgrade. We checked “/etc/apt/sources.list” just to be sure the “deb http:security.debian.org/ stable/updates main contrib” was in there, and then we ran “apt-get update” followed by “apt-get upgrade” to update the list of versions for the installed packages and then to perform the upgrade of those packages that had new versions available.

Once that was completed, we added “deb http://http.us.debian.org/debian stable main contrib” to “/etc/apt/sources.list” to increase the list of available packages to include all of those at debian.org rather than just those provided on the installation media used. Now, using “aptitude”, we see a huge set of software available for installation. Debian packages are an amazing way to install and uninstall software on a Debian system, and the application “aptitude” provides a clean interface for doing so.

Anyway, after confirming with the person there was no reason to be running the 2.4.7 kernel, we fired up “aptitude”, searched for and installed the “kernel-image-2.6.8-2-686″ Debian package, and rebooted the system with that kernel. We also installed the “kernel-source-2.6.8″ Debian package for use in the near future. This later kernel makes life easier for things like sound and network drivers.

  1. Screen resolution

    So, problem 1 was the screen resolution on the LCD. The video driver installed out of the box worked fine, but the XF86Config had bizarre settings. So, we had to update the “Monitor” and “Screen” sections of the “/etc/X11/XF86Config-4″ to have proper settings for the widescreen liquid crystal display (LCD) provided by the laptop, and we found a good sample “XF86Config-4″ for this laptop here.

    With that taken care of, we moved on to problem 2, the wireless card.

  2. Wireless Card

    Once again, using “aptitude”, we searched for and installed the “wireless-tools” Debian package. The person was using a wireless access point (AP) with the SSID of “D_dash_KRIPTIK_dot_COM” configured for WPA-PSK and providing DHCP. The wireless card was esentially built into the machine and was not going to be removed or changed, so we went in and edited “/etc/network/interfaces” to include an entry along the lines of:

      auto wlan0
      iface wlan0 init dhcp
      wireless_essid D_dash_KRIPTIK_dot_COM
      wireless_mode Managed

    You could also configure a (blech) WEP key here, but this was not necessary for our purposes. These settings might get overriden by future configuration, especially that involved for WPA, and could also be modified on the fly using “iwconfig”.

    Dell had recently issued a new driver for the TrueMobile 1300 mini-PCI wireless card, which can be found here, and we downloaded this on a machine running Windows XP. We ran this file on the Windows machine, and it automatically extracted a set of files and then ran the install program for the driver. The installation cancelled the installation as all we needed were the extracted files. By default, these files were placed in “C:\Dell\Drivers\R102320″ directory. We copied the files “bcmwl5.inf” and “bcmwl5.sys” to a USB drive for easy transport to the laptop, but this could have just as easily been a floppy disk, CD, and transferred via the network (on the Ethernet port provided by the laptop). We plugged the USB drive into the laptop and this was mounted as “/media/usbdisk”.

    Now, obviously, the drivers we just downloaded from Dell are for Windows and there are drivers released for GNU/Linux. However, with a nifty piece of software called “ndiswrapper“, we can use these Windows network drivers on our GNU/Linux machine. But, first, we need to install “ndiswrapper”. We fire up “aptitude”, search for “ndiswrapper”, and we find the necessary Debian packages for installing “ndiswrapper”. We install the “ndiswrapper-modules-2.6.8-2-686″, “ndiswrapper-utils”, and “ndiswrapper-source” Debian packages.

    After installing “ndiswrapper”, we needed to configure it. First, we installed the wireless card’s driver onto the system from the USB drive by running “ndiswrapper -i /media/usbdisk/bcmwl5.inf”. Next, we needed to find the device ID for the wireless card. We did this by running first “lspci”, which indicated that “0000:02:03.0″ was our wireless card, and then we ran “lscpi -n”, which gave the device ID of “14e4:4320″ for “0000:02:03.0″. “14e4:4320″ was what we needed to know. With this information, we ran “ndiswrapper -d 14e4:4320 bcmwl5″ to properly install the driver for the wireless card. We then ran “ndisdriver -m” and “ndisdriver -hotplug” to make tie any remaining loose ends.

    If you do not have WPA turned on for your AP or other wireless device, you could have a wireless card with a working connection at this point. However, for our setup, the wireless card was still useless. We needed one additional piece of software to provide our support for WPA, “wpasupplicant“, which is useful for cases such as these where the wireless card does not normally change or get removed. The usual routine – “aptitude”, search for “wpasupplicant”, and install “wpasupplicant”.

    We created a directory “/var/run/wpasupplicant” by running “mkdir /var/run/wpasupplicant”. We took the example “wpa_supplicant.conf” file provided with wpasupplicant and edited it to suit our needs. Essentially, we left the defaults in the example alone until “# network block” section. There, we removed all of the example entries and put in the following.

      network={

             ssid="D_dash_KRIPTIK_dot_COM"
       proto=WPA
       key_mgmt=WPA-PSK
       pairwise=CCMP
       group=CCMP
       psk="*****************************************"
       priority=1

      }

    Of course, the “*****************************************” should be replaced with the actual pre-shared key as configured on the AP. We placed our “wpa_supplicant.conf” in “/etc”.

    There was now a script in “/etc/init.d” that could be invoked during the various runlevels to startup the “wpasupplicant” software during boot. Before we configured this, we needed to modify “/etc/default/wpasupplicant” to properly reflect our configuration. We needed to edit “/etc/default/wpasupplicant” to include the proper options for when “/etc/init.d/wpasupplicant” was invoked. So, we opened “/etc/default/wpasupplicant”, and changed “ENABLE” to equal “1″ and “OPTIONS” to equal “-Bw -c /etc/wpa_supplicant.conf -Dndiswrapper -iwlan0″. Next, we created a symbolic link in “/etc/rcS.d” before the standard networking scripts were invoked by running “ln -s ../init.d/wpasupplicant S38wpasupplicant” from the “/etc/rcS.d” directory.

    We rebooted, and watched as “wpasupplicant” was invoked, “wlan0″ was brought up, and then “wlan0″ was assigned an IP via DHCP. Beautiful, www.google.com loaded perfectly in Firefox.

  3. Simple Firewall Configuration

    Well, we were connected to the AP, so what about that firewall? “netfilter” was built into our kernel, and “iptables” was installed on the system, which provides a way to configure “netfilter”. However, we needed a simple interface for configuring “netfilter” through “iptables”, so we decided to install “lokkit”. We ran “aptitide”, searched for “lokkit”, and installed both the “lokkit” and “gnome-lokkit” packages. We then ran “gnome-lokkit”, walked through the configuration options with the person, and we were all set.

Whew.

Remember when we grabbed the “kernel-source-2.6.8″ package a minute ago? Our next post will discuss what we did we that.

Posted in D-Kriptik, Debian & Ubuntu | 4 Comments »

Newer Entries »