[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debsums for maintainer scripts

On Wed, Dec 03, 2003 at 04:23:33AM -0600, Manoj Srivastava wrote:
> On Mon, 1 Dec 2003 17:12:36 -0500, christophe barbe <christophe@cattlegrid.net> said: 
> > I don't see why adding a md5dsum_are_mandatory clause to the debian
> > policy would be difficult (what would be a good reason to not add
> > md5sum to a package?).
> 	Because it buys little security wise? Because there are
>  solutions one can put in place today that offer better coverage than
>  in package md5sums?

First off, little security is better than no security. Second, it's not
only useful for security, it's useful for integrity checking (which is not
always related). Third, other solutions (calculating md5sums on install,
running tripwire/aide, etc.)  might be computational intensive and might
need to be ruled out in some (critical) systems.

Finally, there's one thing md5sums in packages can provide that no other
solution proposed in this thread can: a database of known good signatures
[1]. Many vendors [2] provide a full list of valid md5sums for their
operating systems which enables investigators to determine if a file
belongs to the system or it has been modified. This is very useful in a
forensic investigation since it enables a way to determine which files in
the system have been modified by comparing them against the vendor-provided
list of MD5sums. In many forensic investigation cases, i.e. 
security-unaware sites, there's no integrity checking being done outside
what system tools provide.

For example: Tiger provides a module [3] to do this kind of check and some
forensic tools (sleuthkit) can use external databases to check for

As for integrity checking, as I said, this can be completely unrelated to
security. If I want to retrieve the list of configuration files in the
system that have been modified (in order to do a focused backup) md5sums in
packages helps a lot, I can also determine if the administrators did not
modify a binary in the system (which some might do, in the case of shell
scripts, instead of making a copy to /usr/local and replacing that one). An
admin that has not foreseen that need, and has to do it without a locally
generated integrity database will find it very difficult to accomplish.

Let's not get into the discussion of wether tripwire/aide/samhain/integrit 
are better solutions to do host intrusion detection. They are. But I would 
love to see an automatic way to analyse a mirror and retrieve _all_ the 
valid md5sums of binaries in Debian packages for a stable release.

The burden imposed on maintainers in adding this is minimum, the burden
imposed on administrators in order to do it themselves is higher (install
and customize your integrity tool of choice, or modify dpkg to calculate
those) and still will not differ from a solution based on packages included
md5sums if not planned properly (databases in read-only media, planed
updates of the integrity database, checks using trusted binaries in
read-only media or in maintenance mode...). Certainly not something your 
average desktop user will do.

So my vote goes to adding md5sums to policy.



[1] Such as those provided by the NIST's National Software Reference 
Library (www.nsrl.nist.gov) and the Known Goods Database 
Note: Knowgoods is not too up to date.

[2] Sun does for Solaris:
the database is available at 
and so does IBM for AIX, take a look for example to how IBM suggests 
checking the "Trusted Computing Base"

[3] check_signatures

Attachment: signature.asc
Description: Digital signature

Reply to: