Lars Strand's blog: 2009

26 Nov 2009

Network monitoring with MRTG

If you work with any kind of networks, the chances are you've heard of, or even used, MRTG. There are not active development of MRTG today, but bugfix patches are still being added now and then.

So why are we still using it? MRTG just works. It stable and robust. And it does what it is supposed to do and nothing else. This makes MRTG still king of monitoring network equipment over SNMP. Well, that is, until Munin 1.4 is released in a couple of days. Munin 1.4 have (better) SNMP support - they are aiming at MRTG.

So until Munin 1.4 is released and stabilizes, I'll use MRTG in production. I've added some minor wrappers around MRTG so that adding and removing nodes gets dead easy. This way, other people can add/remove equipments without knowing too much about MRTG.

Every Linux distribution out there have MRTG in their repository. If yours don't, change distribution or compile MRTG yourself.

1. First of all, we add all our network equipment in a text file:

$ cat /etc/mrtg/network.cfg
#
# SNMP capable switches goes here
#
# After adding hosts here, run
#
#   /etc/mrtg/mrtgmaker.sh
#   /etc/mrtg/indexer.sh
#
# Format (community is optional) and override default
#
# [community]@IP description
#
# Example:
# 192.168.1.1 Core Network Router 1 (Location A)
# secret@10.0.0.1 Core Network Router 2 (Location B)
10.1.1.1 Cisco 6500 08/09 Core Network Router 1
192.168.1.1 Cisco 4948 09/09

2. I create a small script that reads the network equipment from the text-file and generate mrtg.cfg:

$ cat /etc/mrtg/mrtgmaker.sh
#!/bin/bash
#
# This should be run every time you add a SNMP capable
# switch under /etc/mrtg/network.cfg
#

[ -r /etc/mrtg/network.cfg ] || exit 1

ALL=""

while read switch
do
   if `echo $switch | grep -q ^#` || `echo $switch | grep -q "^$"`; then
        continue
   fi
   HOST=`echo $switch | awk ' { print $1 }'`
   ALL="$ALL $HOST"

done < /etc/mrtg/network.cfg

echo "Harvesting SNMP info from $ALL"

/usr/bin/cfgmaker --snmp-options=:::::2 --show-op-down --global 'AddHead[_]: ' --global 'Options[_]: growright, bits' --global 'HtmlDir: /var/www/html/mrtg' --global 'ImageDir: /var/www/html/mrtg' --global 'LogDir: /var/lib/mrtg' --global 'ThreshDir: /var/lib/mrtg' --community=SECRET --output=/etc/mrtg/mrtg.cfg --subdirs=HOSTNAME $ALL

echo "Config file: /etc/mrtg/mrtg.cfg"
echo "You should now run /etc/mrtg/indexer.sh"

3. Then we need to add a script to update the HTML

$ cat /etc/mrtg/indexer.sh 

#!/bin/bash

#

# This should be run every time you add a SNMP capable

# switch under /etc/mrtg/network.cfg

#

echo '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>

<head>

<title>MRTG @ Company Name</title>

<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">

<meta http-equiv="Refresh" content="300">

<meta http-equiv="Cache-Control" content="no-cache">

<meta http-equiv="Pragma" content="no-cache">

<meta name="robots" content="noarchive">

<link href="favicon.ico" rel="shortcut icon">

<link rel="stylesheet" type="text/css" href="mrtg.css">

</head>

<body bgcolor="#FFFFFF" text="#000000">

<h1>MRTG @ Company Name</h1>

<img src="company_logo.png" height="135" width="130" align="right" alt="Company Name logo"/>

<blockquote>

' > /var/www/html/mrtg/index.html

while read switch

do

if `echo $switch | grep -q ^#` || `echo $switch | grep -q "^$"`; then

continue

fi

IP=$(echo $switch | cut -d" " -f1)

IP=${IP#*@}

DESC=$(echo $switch | cut -d" " -f2-40)

DATE=$(date)

DNSNAME=$(dig +short -x $IP 2> /dev/null)

echo "Indexing $IP"

/usr/bin/indexmaker --nolegend --subtitle='<h2><a href="../">Back home</a></h2>' \ 

--pageend="<em>MRTG @ Company Name - generated on $HOSTNAME</em>" \ 

--addhead='<link rel="stylesheet" type="text/css" href="/mrtg.css">' \ 

--output /var/www/html/mrtg/$IP.html  --filter name=~$IP \ 

--title="Network utilitization for $DNSNAME ($IP)" /etc/mrtg/mrtg.cfg

if [ -z $DNSNAME ]

then

echo "<font size="+1">⇒ <a href="$IP.html">$IP</a> — $DESC</font> <br>" >> /var/www/html/mrtg/index.html

else

echo "<font size="+1">⇒ <a href="$IP.html">$IP</a>, $DNSNAME — $DESC</font> <br>" >> /var/www/html/mrtg/index.html

fi

done < /etc/mrtg/network.cfg

echo "

</blockquote> 

<p>MRTG is also used as datasource for our Network Weathermap — <a href="http://weathermap/">http://weathermap</a>

<hr>

<em><font size=\"-1\">More info: <a href=\"http://wiki/mediawiki/index.php/MRTG\">

http://wiki/mediawiki/index.php/MRTG</a></font><br></em>

<em><font size=\"-1\">Generated by $HOSTNAME:$0</font></em>

</body>

</html>" >>  /var/www/html/mrtg/index.html

4. We add a stylesheet to make thing a little prettier:

$ cat /var/www/html/mrtg/mrtg.css
body {
background-color: #EFEFEF;
color: #000000;
font-family: sans-serif;
font-size: 12px;
}

h1 {
background-color: #CCCCCC;
font-family: sans-serif;
font-size: 18px;
font-weight: bold;
}

h2 {
font-family: sans-serif;
font-size: 16px;
font-weight: bold;
}

a {
text-decoration: none;
}

5. We test:

# /etc/mrtg/mrtgmaker.sh
Harvesting SNMP info from 10.1.1.1 192.168.1.1
Config file: /etc/mrtg/mrtg.cfg
You should now run /etc/mrtg/indexer.sh
# /etc/mrtg/indexer.sh
Indexing 10.1.1.1
Indexing 192.168.1.1

We are then presented with an overview page then takes us to each switch/router:

27 Aug 2009

Slackware 13 released!

Slackware 13 was released yesterday. It's the oldest currently maintained Linux distribution out there, and with good reason. It is clean, simple and without the "bells and whistles" that clobbers up so many other distributions.

Slackware was for myself (and for many of my friends and colleagues) my first encounter with Linux. I used Slackware for many years, and still do on occasions. Its a great distribution to really learn Linux and not learn a Linux distribution. I will say that if you really know Linux (and Slackware), you will know most Linux distributions as well.

You would think Slackware was abandoned for other more popular distributions nowadays, but there is still a large active Slackware community and user base out there. It is in fact, one of the most downloaded Linux distributions (in both MB and number of hits) for Norway's largest ftp-site:

http://ftp.uio.no/stats/usage_200907.html#TOPURLS

16 Jun 2009

Quick and strong file-encryption with OpenSSL

To quickly encrypt a file with a password of your choice you can use OpenSSL. OpenSSL supports a whole range of ciphers, including government approved encryption algorithms. The encryption algorithm AES is the only accepted open confidentiality algorithm here in Norway (read more here). AES is the new algorithm replacing DES. You can read all about AES and DES elsewhere.

To encrypt a file using AES with a 256 bit key-length:

$ openssl enc -e -aes-256-cbc -salt -in filename.odp -out filename.odp.enc
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:

The encrypted file is now found as filename.odp.enc

Since symmetric block ciphers process one block of data at the time (AES uses a block length of 128 bits), it is important that we use CBC mode. CBC prevents repeating plaintext to create the same (repeating) ciphertext. Use option -p to have OpenSSL print out the salt, key and IV used:

$ openssl enc -e -aes-256-cbc -salt -p -in filename.odp -out filename.odp.enc
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
salt=92BCA2EA0EABCA62
key=1BCE6E251E86A6379066B634FD20CD3090981B50CDF3FF5634C49DCF4A1812A5
iv =9604DF84236BB3965083830396277636

To decrypt the file: Note! If you type in the wrong password, you'll get garbled output since there is no way to check if the password is correct.
$ openssl enc -d -aes-256-cbc -in filename.odp.enc -out filename.odp
enter aes-256-cbc decryption password:

And the decrypted file is found as filename.odp

For example: You can encrypt a file with a password of your choice. Send the file to the receiver, and then communicate to him over another secure communication channel what the password is (and that you've used "aes-256-cbc").

19 May 2009

Encrypted swap, tmp and home partition in Ubuntu 9.04

I really would like to have an encrypted swap, tmp and home partition on my laptop. In case it gets stolen or if I should forget it somewhere, I can be sure that no-one would be able to read my private files. In this mini-howto I set my home partition using LVM, but using a regular partition should work just fine. This howto should also work, with minor modification, if you use another distribution than Ubuntu.

Updated:
May 2009: Updated for Ubuntu 9.04. Added encrypted /tmp.
May 2008: Init for Ubuntu 8.04.

Note! Both the "server" and "alternate" Ubuntu ISO-images provide the option to encrypt your home directory (but in a different way using eCryptfs. Swap and /tmp are not encrypted). It might be an easier solution if you find this page too hard to follow. The difference? They are two different implementations. eCryptfs is file level encryption, LUKS is block device (/dev/sda3). Think of it like SSL vs. IPSec. Both have their advantages and drawbacks. Read more here and here

By using Linux Unified Key Setup (LUKS) setting up encrypted partition in Linux is done in no time.

Prerequisites

Install required packages:

# apt-get install lvm2 cryptsetup libpam-mount

The device-mapper should be active (if not, reboot):

$ ls -l /dev/mapper/
total 0
crw-rw---- 1 root root 10, 61 2009-05-19 15:39 control

..with support for crypto:

# dmsetup targets | grep crypt
crypt            v1.6.0

Good. Now we're ready.

Part I: Setting up encrypted swap

Step 1: Disable your current swap partition.

# swapoff /dev/sda2

Step 2: Fill your swap with random data.

# dd if=/dev/urandom of=/dev/sda2 bs=1M
1954+0 records in
1953+0 records out
2048094208 bytes (2.0 GB) copied, 529.177 s, 3.9 MB/s

As you see, this might take some time depending on your swap size. So go grab a coffe.

Step 3: Configure encrypted swap.

Add this to your /etc/crypttab

# cat /etc/crypttab
...
cryptoswap /dev/sda2 /dev/urandom cipher=aes-cbc-essiv:sha256,size=256,hash=sha256,swap

Why /dev/urandom and not /dev/random? The latter blocks until it got enough entropy to continue, urandom don't. So if you use random instead urandom you might have to wait during boot until enough entropy is collected. (It does help to type your keyboard and move the mouse.) Use /dev/random if you're really paranoid.

Next, change your swap entry in /etc/fstab to this:

# cat /etc/fstab
...
/dev/mapper/cryptoswap swap swap sw 0 0

For every time we boot, swap will be encrypted with a different encryption key.

Step 4: Test it.

Reboot to test.

We now have an encrypted swap:

# cat /proc/swaps
Filename                Type        Size    Used    Priority
/dev/mapper/cryptoswap                  partition    2000084    0    -1

# cryptsetup status cryptoswap
/dev/mapper/cryptoswap is active:
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
device: /dev/sda2
offset: 0 sectors
size:    4000185 sectors
mode:    read/write

Good. Now we're safe right?

Part II: Dealing with /tmp

To protect /tmp, we have two choices. 1) we can encrypt it like we did with swap or 2) we can create a ramdisk. The content of a ramdisk don't survive a reboot and /tmp rarely is used for any big files, its is also a good option. But, paranoid as we are, we choose option 1)

The setup is almost identical as for swap:

Step 1: Setting up a tmp partition using LVM.

If you use a regular partition, you can easily skip this step.

# pvcreate /dev/sda3
Physical volume "/dev/sda3" successfully created
# vgcreate vg_storage /dev/sda3
Volume group "vg_storage" successfully created
# vgchange -a y vg_storage
0 logical volume(s) in volume group "vg_storage" now active
# lvcreate -L500M -nlv_tmp vg_storage
Logical volume "lv_tmp" created

For more details on how to use LVM, please check out the excellent LVM HOWTO.

Step 2: Fill the partition with random data.

# dd if=/dev/urandom of=/dev/vg_storage/lv_tmp
1024001+0 records in
1024000+0 records out
524288000 bytes (524 MB) copied, 139.983 s, 3.7 MB/s

Step 3: Add entry in /etc/crypttab

# cat /etc/crypttab
...
cryptotmp /dev/vg_storage/lv_tmp /dev/random cipher=aes-cbc-essiv:sha256,size=256,hash=sha256,tmp

Now, since /tmp is encrypted with a new key every time, the filsystem must be created every time as well. The option "tmp" fixes that for us and calls mkfs before mount. Since it is created with filesystem ext2, we add in fstab:

# cat /etc/fstab
...
/dev/mapper/cryptotmp /tmp ext2 defaults 0 0

Step 4: Test it.

Reboot to test.

We now have an encrypted /tmp partition as well. Great!

# cryptsetup status cryptotmp
/dev/mapper/cryptotmp is active:
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
device: /dev/mapper/vg_storage-lv_tmp
offset: 0 sectors
size:    1024000 sectors
mode:    read/write

Part III: Creating and setting up an encrypted home partition

Step 1: Setting up a home partition using LVM.

If you use a regular partition, you can easily skip this step.

# lvcreate -L20G -nlv_home vg_storage
Logical volume "lv_home" created

Step 2: Fill your soon-to-be home partition with random data.

# dd if=/dev/urandom of=/dev/vg_storage/lv_home
20481+0 records in
20480+0 records out
21474836480 bytes (21 GB) copied, 5554.23 s, 3.9 MB/s

This will take even longer than the swap partition. So go for lunch or something.

Step 3: Initialize the partition and set initial key.

Remember, if you use a weak password, your screwed. If you forget the password, its game over.

# cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/vg_storage/lv_home

WARNING!
========
This will overwrite data on /dev/vg_storage/lv_home irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.

We use cipher "aes-cbc-essi", since the default is vulnerable to Watermarking attack.

Step 4: Create a device mapping.

# cryptsetup luksOpen /dev/vg_storage/lv_home cryptohome
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.

This will create a device mapping, as can bee see under:

$ ls -l /dev/mapper/
total 0
crw-rw---- 1 root root 10, 61 2009-05-19 15:39 control
brw-rw---- 1 root disk 252, 4 2009-05-19 15:52 cryptohome
brw-rw---- 1 root disk 252, 1 2009-05-19 15:39 cryptoswap
brw-rw---- 1 root disk 252, 2 2009-05-19 15:39 cryptotmp
brw-rw---- 1 root disk 252, 3 2009-05-19 15:52 vg_storage-lv_home
brw-rw---- 1 root disk 252, 0 2009-05-19 15:39 vg_storage-lv_tmp

Note that LVM also uses the device-mapper (that is why LVM volumes also are listed).

Or, you can use the command "dmsetup ls" to list the mapped devices:

$ dmsetup ls
cryptoswap    (252, 1)
vg_storage-lv_tmp    (252, 0)
cryptotmp    (252, 2)
vg_storage-lv_home    (252, 3)
cryptohome    (252, 4)

Step 5: Create a filesystem.

We now have an encrypted partition. To use it, we need to create a filesystem on it:

# mkfs.ext4 -j -m 1 -O dir_index,filetype,sparse_super /dev/mapper/cryptohome
mke2fs 1.41.4 (27-Jan-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1310720 inodes, 5242623 blocks
52426 blocks (1.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
160 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
      32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
      4096000

Writing inode tables: done
Creating journal (32768 blocks): done

Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

Step 6: Testing!

We start by closing and reopen the encrypted partition before we mount it:

# cryptsetup luksClose cryptohome
# cryptsetup luksOpen /dev/vg_storage/lv_home cryptohome
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
# mkdir -p /mnt/cryptohome
# mount /dev/mapper/cryptohome /mnt/cryptohome
# touch /mnt/cryptohome/testfile
# ls /mnt/cryptohome/
lost+found   testfile

We can also confirm that it works by issuing the command:

# cryptsetup status cryptohome
/dev/mapper/cryptohome is active:
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
device: /dev/mapper/vg_storage-lv_home
offset: 2056 sectors
size:    41940984 sectors
mode:    read/write

Now would be a good time to move your current home to this partition.

Finally we umount:

# umount /mnt/cryptohome
# cryptsetup luksClose cryptohome

Step 7: Cryptohome mounted at boot or at login?

Now you have to take a choice. A) You can enable the partition at boot time, but then the boot sequence is interrupted asking you for the LUKS password. B) If you want the partition automatically mounted when you login, skip to the next section.

Instead of manually typing in password, you can have the key stored externally - for instance on a usb-stick. Read more about that here.

You want to enable mounting at boot time? Then update /etc/crypttab:

# cat /etc/crypttab
...
cryptohome /dev/vg_storage/lv_home none luks

And /etc/fstab:

# cat /etc/fstab
...
/dev/mapper/cryptohome    /home/ ext4 relatime,errors=remount-ro 0 2

When you now reboot, the boot process is interrupted asking you for the LUKS password. If you type it correctly, the home partition is mounted. When you now log in, you will have an encrypted home partition ready waiting for you.

Part IV: Automatically mount when logging in.

A more elegant solution would be to automatically mount the home partition the same time you log in. This require that you use the same password for login as for the encrypted partition. (Actually that is not entirely true. You may have the password stored on file somewhere. But in this howto, we assume you have the same password for both.)

Step 1: Remove home partition from /etc/fstab

If there is an entry to your (encrypted) home partition in /etc/fstab, remove it

# cat /etc/fstab
...
/dev/mapper/cryptohome    /home ext4 relatime,errors=remount-ro 0 2 # this gotta go

Step 2: Update /etc/crypttab

Make sure the you have a line in /etc/crypttab that reads as follows:

# cat /etc/crypttab
...
cryptohome /dev/vg_storage/lv_home noauto luks

Step 3: Configure pam_mount

Add the following entry in /etc/security/pam_mount.conf.xml. This file is heavily commented, and it may be useful to read the comments.

# cat /etc/security/pam_mount.conf.xml
...

Step 4: Configure PAM

No longer necessary. As of 9.04 all options already included.

Step 5: Test!

Log out and back in. You should now have an encrypted home:

$ df -h
...
/dev/mapper/_dev_mapper_vg_storage-lv_home
                       20G 296M   20G   2% /home

Congratulation, you now have an encrypted swap, tmp and home partition!

A final advice: Take regular backups.

Useful links:

"dm-crypt: a device-mapper crypto target": http://www.saout.de/misc/dm-crypt/
"dm-crypt HOWTO for Debian unstable and testing": http://www.saout.de/tikiwiki/tiki-index.php?page=HOWTO

23 Apr 2009

Sharing Internet connection over bluetooth in Ubuntu

Me and my girlfriend are staying in a hotel here in Sha Tin, Hong Kong. Since the hotel only allow one computer per room connected to the Internet at the time - I found out it would be a nice time to look into Internet connection sharing over bluetooth. There are some documentation on how to set up PAN in Linux, so the prosess should be pretty straightforward. One posting I found mention some software called "Blueman". Turns out Blueman can do all the work for me with the click of a button.

It's even in Launchpad, so I can install it using apt. I start the applet, go into "Local Services", enable NAP, and.. it just works! This is getting too easy!

Mass EXIF date and time manipulation

I'm out traveling and I forgot to change the timezone on my camera again. So the EXIF time stored in the pictures are all wrong. My first though was to write another Perl script to fix this (se earlier post). But I found out that the program jhead can do all sort of magic EXIF manipulation. To mass change EXIF dates, just do a:

$ jhead -ta+7:00 *.JPG
Modified: IMG_1708.JPG
Modified: IMG_1709.JPG
Modified: IMG_1710.JPG
...

This add seven hours to the EXIF stored time. Nice and easy.

8 Apr 2009

Memory usage by user

A short little script I stumbled across when cleaning my $HOME. I do not think I wrote it myself - at least I can't recall that I did. Quite handy and it's small and compact using the commands ps, awk, sort and head:

ps aux --no-headers | awk '
        {
                name[$1] += $1;
                pros[$1] += $4;
                mem[$1] += $5
        }
        END {
                for (var in name) {
                        print mem[var]" "var" "pros[var]
                }
        }' | sort -nr | head

The result is a top ten list of the users that consume the most memory:

741012 root 9.3
238152 bjorn 3.8
119380 thomasez 1.2
105332 krav 1.9
100804 lars 0.6
95916 ingvar 1.6
89720 kjetilho 1.5
78044 jo 1
74232 espen 0.8
73460 michael 0.4

There I am - at number five...

7 Apr 2009

First RFC 40 years old

The first request for comments (RFC 1) was published 40 years ago today (7. April 2009). RFCs are standard documents published by the Internet Engineering Task Force (IETF). Today over 5000 RFCs have been published by IETF. Stephen Crocker, the author of RFC1, recollect some thoughts of the early days:

http://www.nytimes.com/2009/04/07/opinion/07crocker.html

1 Feb 2009

Secure password management using CPM

There are numerous articles on the importance of creating strong secure passwords that are hard to guess and break. However, the harder the password, the harder it is to memorize. Another problem arises when we have several different passwords, usually one for each device or service. How can we store and manage the increasing number of passwords? Console Password Management (CPM), created by Harry Brueckner, does a great job for exactly that.

I worked as a system administrator for a medium sized Norwegian company. Our department was administering a large number of network devices and Unix/Linux servers. The company had two international offices each with different network security zones. This complex network topology combined with a severe strict password policy, made it impossible to memorize all different passwords.

We solved this by equipping each administrator with their own Palm with an approved secure password application. These Palms had to be manually fed, which meant in practice that they never were in sync. The authoritative password "database" was a green folder with sheets upon sheets of paper combined with post-it notes scribbled all over. In other words, it was a mess. The only up-turn was that this folder was stored in a huge fire-proof safe.

We decided to clean this up. First, we wanted an online central password database, stored as secure as possible, and running on Linux. I found dozens upon dozens of password applications. However, most of these could be placed in one of two categories (and in some cases both):

The application is designed for one user. Many of these applications are pretty usable, some even with a nice graphical user interface. A familiar example; both Firefox and Thunderbird allow you to save username and passwords. When enabling the Master password, you should, these passwords are encrypted on disk. However, these passwords are only available to the user of the application. The desktop managers GNOME and KDE both have the ability to save passwords securely.
The application is fundamentally flawed. For example, the application allows core dumps or being swapped to disk. One password application I found even stored the passwords in clear(!) text in a SQL database. Really dumb.

Fortnunately, there was one application that caught my eye. It did not fit any of these conditions above.

Console Password Management

CPM is one of those rare applications that have done many things right when it comes to secure passwords storage. At startup it checks

whether core dumps are disabled,
whether memory is locked from paging,
whether the application is protected from ptrace spying,
whether the application has environment checks enabled, and
whether it's running without root privileges.

The database of CPM is just a XML file, compressed with zlib (gzip), and encrypted with GPG. CPM is command line based, which I consider an advantage. That way I can access it through a login window or a terminal. Most of the work of a network or Linux administrator is in a shell anyway. Also, should I be stuck down in the server room and need that password, all I need to do is log in to the correct server and access CPM. Handy.

Installation

Installing CPM from source can be a little hassle unless you are familiar with compiling your own software. On Debian, you can just add CPM's apt source and install it using Debian's own package manager. You'll find instructions on CPM's homepage. Unfortunately, I did not find updated packages for Fedora/Red Hat Enterprise. I know that the developer is busy updating CPM and that a static binary is high on his priority list. A static binary would ease the installation tremendously.

Note that CPM is installed SUID root (mode 4755), meaning that CPM will be executed with root privileges regardless whether root executes the application or the user. This is necessary to enable memory locking and protection from strace/ptrace attacks. The root privilege is dropped right after memory locking.

GnuPG

Before we start using CPM, we need to have an asymmetric keypair generated by GnuPG. GnuPG is a free implementation of the commercial PGP and is included in most Linux distributions. Since CPM relies so heavily on GPG, it is imperative that you and your co-users have a grip on GnuPG. If you plan to have more than one user accessing the same CPM database, you need to create a GnuPG "web-of-trust", which basically is signing each others keys. If you are the only users of CPM, this is not necessarily.

If you don't already have a GnuPG keypair, you can create one:

$ gpg --gen-key

You'll be asked some questions, where you safely can choose the default options. Be sure to type in your name and email address when asked so. Choose a really good passphrase! This will be the only password you'll have to remember. But do remember it! If you forget this, there is no way to recover the password database.

You can now list your newly created key:

$ gpg --list-keys

Good! Lets get started using CPM.

Configuration and usage

First, we need to configure CPM. Copy /etc/cpm/cpmrc to ~/.cpmrc

$ cp /etc/cpm/cpmrc ~/.cpmrc

Open this file with the editor of your choice. In this file, you need to set the "EncryptionKey" variable. Its value would be the GnuPG email-address you typed in when you generated the GnuPG keys. So for me, that would be:

EncryptionKey "lars.strand@linpro.no"

Save and exit. Start CPM with a security test:

$ cpm --security

You should now get an output like the one in the image above. It looks like we're secure enough. The first time we start CPM, we get an error telling us that it can't find any database. That's ok, since we haven't created one yet. There is no host added, so you'll be greeted with an empty CPM as shown in the image below.

You populate the database by pressing Ctrl-A. Enter the hostname, and press enter. Selecting the host and pressing enter, enables you to add one or more services for this host. Each service can have one or more username/password pairs linked to it. Every host, service or username/password can have a comment associated with it. See the image below.

Install the password checker cracklib, and CPM also warns you if you enter a weak password. See figure:

Every entry has a timestamp indicating when it was updated and by which GnuPG key. This way, we can see which user has updated this particular entry.

Finally, save by pressing Ctrl-W. If this is the first time you run CPM, we'll be prompted for our GnuPG password. Otherwise we're asked for the password at startup - else CPM is not able to read our database. Quit by pressing ESC. The database is now saved in ~/.cpmdb in our home directory:

$ file ~/.cpmdb
/home/lars/.cpmdb: PGP armored data message

This file is just an encrypted and compressed XML-file. We can easily decrypt the content by issuing the command:

$ gpg --decrypt ~/.cpmdb | gzip -cd > cpm-decrypted.xml
$ file cpm-decrypted.xml
cpm-decrypted.xml: XML document text

CPM also provides command line search. Here I search for every entry containing "trinity:

$ cpm valhall
enter your passphrase (try #1)
Lars Strand
login root@valhall secretpassword3
1 match found.

This is quite useful when I'm in a hurry.

More than one user

If you plan to use CPM with several users, be sure that everyone has grip on GnuPG and how to proper handle their keys. You also want to store the database somewhere else. Your home directory is not a good place! Create a directory /var/lib/cpm/ and call the database cpmdb. Create a group called "cpm" and populate it with users of CPM. Then make sure the directory is (only) readable by that group. If CPM is running on a high trusted host, you've come a long way to see the security officer in your company smile.

You need to consult the GnuPG documentation on how to sign each others GnuPG keys to create a "web-of-trust".

If there is more than one user accessing CPM at the same time. Only the first user has read-write access. All other users will have read-only.

Conclusion

CPM does one thing, and it does it really well. It stores passwords securely. If you and your co-workers know how to handle GnuPG, it is way better than most other solutions out there.

This article originally appeared in Linux+DVD magazine in the January 2009 issue.