Debian File Integrity: Debsums for Package Checks

Files change.

It’s a tale as old as time, or at least as old as systems administration. You install a package on your Debian or Ubuntu box, and for a while, all is right with the world. Then, maybe a rogue script cleans too aggressively, someone fiddles with a config file they shouldn’t have, or your disk decides to throw a tantrum after an unexpected shutdown. Suddenly, you’re left scratching your head: Is this thing still in the state I expect? Did something, anything, get messed with?

<a href="/tag/debsums/">debsums</a> answers that question.

Look, we’ve all been there. Staring at a system that’s acting… off. You could spend hours grepping logs, diffing directories, and generally flailing in the dark. Or, you could use a tool built for precisely this kind of digital detective work. For Debian-based systems, that tool is debsums.

It’s not sexy. It won’t make headlines. But when you need to know if the files installed by a package have actually, you know, changed on disk, this is your go-to. And let’s be honest, in the grand scheme of tech hype, finding something this fundamentally practical is a win.

Beyond Vulnerability Scans

Now, before you confuse this with some kind of all-encompassing security silver bullet, let’s pump the brakes. The folks who write the debsecan tool are busy looking for known vulnerabilities – the CVEs that make security teams sweat. debsums is playing a different game entirely. It’s not asking if a package is vulnerable. It’s asking if the files that package put there are still the original files.

Think of it like this: debsecan is the cop checking your ID to see if you’re on a watchlist. debsums is the security guard comparing your baggage to the manifest. Two different jobs, both important, but you don’t send the baggage scanner to interview suspects.

debsums does its magic by comparing the files on your system against MD5 checksums. These checksums are tucked away neatly in /var/lib/dpkg/info/*.md5sums for each package. If the calculated checksum of a file on your disk doesn’t match what’s recorded in that .md5sums file, debsums raises a flag.

What can it spot?

• Locally modified package files (the classic culprit).
• Files that have gone missing entirely.
• Certain types of data corruption or bit rot that might occur.

But as the man page is quick to point out – and you should pay attention to this – it’s not a full-blown security audit. It’s primarily for finding files that have been tampered with locally or damaged by hardware issues. That distinction is crucial for setting expectations.

Getting Started: It’s Easy (Mostly)

If you’re running Debian or Ubuntu, getting debsums is as simple as a couple of standard commands:

sudo apt-get update
sudo apt-get install debsums

Just to be sure it’s there, a quick:

debsums --version

will confirm.

When you’re just poking around, start small. If a specific package, say bash, is giving you grief, run:

debsums bash

If all is well, you’ll probably get silence. That’s the good kind of silence in sysadmin land.

For faster triage, especially when you just want to see the problems, the --silent flag is your friend:

debsums --silent bash

This suppresses all the output for files that haven’t changed, leaving you with only the errors. Handy.

Now, for a quick sweep of your entire host – the kind of command I’d reach for during a health check – this is your ticket:

sudo debsums -c

The -c flag means --changed, and it implies --silent. So, it only reports files that have actually been modified. If this command returns nothing, you can usually breathe a sigh of relief.

Config Files: Handle with Care

Here’s a point where debsums gets a little nuanced, and frankly, it’s smart:

By default, debsums actively ignores configuration files found in /etc. Why? Because it’s expected that these files will change. When you install an application, you’re often meant to tweak its configuration. Overwriting those custom changes with defaults from the package would be disastrous.

If you do want to include configuration files in your check – perhaps you’re worried about unintended modifications – you can use the -a flag (for --all):

sudo debsums -ca

And if you only want to check configuration files, that’s covered too:

sudo debsums -ce

Use these options judiciously. A changed config file isn’t always a bad thing; sometimes it’s just normal, responsible system administration.

When Checksums Go Missing

Not every package ships with that handy .md5sums file. debsums can tell you which ones are missing this information using the -l flag:

debsums -l

This doesn’t mean those packages are inherently compromised or broken. It just means debsums can’t verify their files against local checksums because there are none to begin with. You’ll need to handle these on a case-by-case basis, perhaps by trusting the package repository or doing deeper manual checks.

Rebuilding the Checksum Cache

What if you want debsums to have more data to work with, especially for those packages missing checksums? The Debian man page offers a neat trick: download the package archives into your APT cache.

First, get the list of packages missing checksums:

debsums -l

Then, use that list to download the corresponding .deb files:

sudo apt-get --reinstall -d install $(debsums -l)

This populates your /var/cache/apt/archives directory. Now, debsums can use these cached archives to generate checksums where they were previously unavailable. You can then perform a more comprehensive check using the -g (generate) and -p (path) flags:

sudo debsums -cagp /var/cache/apt/archives

Here’s what those flags mean:

• -c: Show changed files.
• -a: Include configuration files.
• -g: Generate checksums for packages that are missing them (using the cached .deb files).
• -p /var/cache/apt/archives: Specifies the directory where the cached .deb files are located.

This command sequence is arguably one of the most powerful integrity checks you can run on a Debian host. It’s a full-system sweep that goes beyond just looking for quick modifications.

A Practical Workflow for System Checks

If I were tasked with checking a Debian server that was acting up, here’s the order I’d likely proceed:

1. Quick Scan for Changes: bash sudo debsums -c This gives you an immediate look at any files that have been altered since installation. This is your first line of defense.

2. Include Configuration Files: bash sudo debsums -ca If the initial scan shows nothing, but you’re still suspicious, broaden the scope to include config files. Remember, these are often intentionally changed, but it’s good to know what has changed.

3. Identify Packages Without Checksums: bash debsums -l This flags packages that debsums can’t verify. You’ll need to investigate these separately.

4. Download Missing Package Archives: bash sudo apt-get --reinstall -d install $(debsums -l) Prepare for a more in-depth check by grabbing the necessary files.

5. Comprehensive Integrity Sweep: bash sudo debsums -cagp /var/cache/apt/archives This is the grand finale. It’s a thorough check that use all available information to give you the clearest picture of your system’s integrity.

This structured approach provides a much clearer signal than randomly diff-ing files under /usr and hoping you stumble upon the right problem. It’s methodical.

Recovering from Changes

So, debsums -c spits out a file that’s been modified, like /usr/bin/example-tool. What now? You need to know which package owns it. The dpkg -S command is your friend here:

dpkg -S /usr/bin/example-tool

This will tell you something like example-package: /usr/bin/example-tool, clearly identifying the responsible package.

Once you have the package name, you can proceed with a reinstall. The debsums man page outlines a pipeline for this, but breaking it down step-by-step gives you more control:

1. Find changed files: bash sudo debsums -c

2. Get the owning package for all changed files and make them unique: bash dpkg -S $(sudo debsums -c) | cut -d: -f1 | sort -u

3. Reinstall those packages: bash sudo apt-get install --reinstall $(dpkg -S $(sudo debsums -c) | cut -d: -f1 | sort -u)

Be cautious with that last command. It’s incredibly useful for restoring package-managed files to their original state. However, it’s not a magic wand that means every changed file should be blindly overwritten. If that file was changed intentionally and that change is still required, a full reinstall might break your system. Always understand why a file changed before blindly restoring it.

This isn’t about absolute, unattainable security. It’s about practical, verifiable integrity. And for that, debsums is an indispensable tool in the Debian admin’s toolkit. It cuts through the guesswork.

🧬 Related Insights

• Read more: GitHub’s AI Security Nets Every Script and Config in Your Repo
• Read more: One Week to Launch: The AI That Writes Your Outage Apologies