Invariant Properties

I have time to post a few notes while waiting for Norton to finish a complete scan of my Windows 7 system….

In a well-managed Debian/Ubuntu system everything that is not under /home will be under package management control. Okay, that’s a gross overstatement even though it feels that way at times. The actual split is

/bin, /sbin, /lib, /usr – package management. (Note: /usr/local should be symlinked into /var/local.)

/boot – package management (plus grub conffile)

/dev – package management

/etc – package management plus conffiles

/home, /root – no package management

/media, /mnt, /proc, /tmp – transient and without package management

/opt – ideally under local package management

The /var partition is a catchall mess although it’s getting better.  In general it won’t be under package management beyond the creation of directory structures.

All Debian and Ubuntu packages contain metadata that is written into the /var/lib/dpkg/info directory. Specifically we’re interested in three files:

<package>.list – a list of files and directories provided by the package.

<package>.md5sums – a list of md5 checksums for the files provided by the package.

<package>.conffiles – a list of configuration files that are provided by the package but are routinely edited by the system administrator.

Now here’s the key point: Every file under /bin, /boot, /lib, /usr, /etc, should be ‘owned’ by exactly one package and it should either have the specified MD5 checksum or be a designated conffile for that package. We can use the package metadata to find files that have been modified. We can use the package metadata to find files that shouldn’t be there. We can use the package metadata to find files that are missing.

This will be even easier with Ubuntu 11.04 when conffile .override files are introduced. These files allow the conffile to be overridden without actually requiring it to be modified. This will make it trivial to capture the customization of a system – just grab all of the .override files.

In practice there’s usually a bit of cruft but it’s easy to handle them with local packages.

At first glance this sounds like it’s just a second way to implement ‘tripwire’ but there’s a huge difference – provenance. If I use ‘tripwire’ I have no reason to trust the initial set of files. That’s not the case with package metadata – if I’m lazy I’ll just use the files under /var/lib/dpkg/info but if I’m careful I’ll pull the package metadata directory from the binary package. It’s easy – a Debian/Ubuntu package is just a Unix ‘ar’ archive containing two compressed tarballs, one for the static content (‘data.tar.gz’) and one for the metadata (‘control.tar.gz’)). If I’m really paranoid I’ll verify the cryptographic signatures on the packages.

This approach isn’t foolproof, e.g., a rootkit or compromised libc library can still cause me to miss compromised files. But it gives me better warm+fuzzies than the traditional tripwire approach.

There’s one other neat thing you can do with this approach. As I mentioned earlier the binary packages contain a compressed tarball of the static content. You can use this to verify the ownership and permissions on all files. In practice you would only use it to check ‘unusual’ permissions, e.g., every SUID or SGID file.

Important reminder

An important reminder – you should not trust the standard find and md5sum programs. At the least use a statically linked copies, ideally from a read-only location like a CD-ROM or NFS mount exported read-only.