Differences between revisions 4 and 5
Revision 4 as of 2006-11-05 04:41:14
Size: 3097
Editor: vpn-nat
Comment: Reject idea.
Revision 5 as of 2006-11-07 00:54:16
Size: 3233
Editor: user-5446cdca
Deletions are marked like this. Additions are marked like this.
Line 50: Line 50:
Perhaps rename the result ''earlybird'' or ''canary'' to show that it's a quick, high-level first level of alert, but not infallible.

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.


This is a leftover from Dapper server spec.


A lot of sysadmins have the need to do lightweight intrusion detection to ensure system integrity. system-integrity-check provides a way to at least verify a big set of data on an installed system to ensure that main set of tools have not been compromised. The checker is *NOT* a replacement for a full intrusion detection system.

Use cases

  • Elmo wants to verify that all the binaries on a certain system are still ok. He knows that system-integrity-check can do that offline using a trusted source of data ( Once verified that the main set of binaries are still intact, he will be able to reinstall whatever is corrupted or compromised with very little effort due to the detailed report that's generated by the scan. He is also aware that not everything can be checked, but at least the system is safe enough to be accessible.


  • Infrastructure at the datacenter ( is now available and updated automatically.
  • system-integrity-check code is in the archive and hooked up to rescue d-i boot option.
  • move system-integrity-check to main and make it part of cd images.
  • add more checks to system-integrity-check:
    • check for orphaned files.
    • add SHA1 checks (does it add anything compared to md5)?
    • attempt to not rely on dpkg database on the installed system.

Unresolved issues

  • Abstracting the tool from the dpkg db on the installed system is not trivial and might end up in tons of false positive. is it actually worth doing it? also in front of the fact that the system will need a reinstall if such db is compromised.


  • An integrity check with

       for I in /var/lib/dpkg/info/*.md5sums; do 
         [ $I != "/var/lib/dpkg/info/udev.md5sums" ] && md5sum -c $I; 
       done | awk '! /OK$/ { print; }'

    gives quite reasonable results. On a server installation (no gui) only /usr/bin/perldoc was a false positive, which is autogenerated.

  • If we can check the integrity of the md5sums, we have what we need. Maybe we can put a checksum of the md5sums file of each package in a new field in the _Packages file? The integrity of the _Packages files is in turn verified by apt and a gpg key.

There is very little point to add this check when the md5 on the system cannot be trusted. The whole point of having pkgsum.u.c (that is already working) is to use a trusted external source. The more data you need to trust from the compromised machine, the worst result you get.

Perhaps rename the result earlybird or canary to show that it's a quick, high-level first level of alert, but not infallible.

BoF agenda and discussion


IntegrityCheck (last edited 2008-08-06 16:14:39 by localhost)