Re: Bug#540215: Introduce dh_checksums
Hey Russ,
On Tue, Mar 9, 2010 at 13:57, Russ Allbery <rra@debian.org> wrote:
> Joey Hess <joeyh@debian.org> writes:
>> Russ Allbery wrote:
>>> It's also always worth bearing in mind that while a really good
>>> attacker can do all sorts of complex things that make them very hard to
>>> find, most attackers are stupid and straightforward.
>> It's stupid and straightforward to install /usr/local/bin/ls. debsums
>> will not detect it.
> True. Adding new binaries is, in my experience, more common than
> modifying binaries already on the system.
> I don't really mean to be arguing for debsums as a security mechanism,
> more just commenting on the general question.
So what's the goal here? Basic integrity checking by defending against
random corruption due to occassional hardware, software or admin
errors? Or an additional security layer verifying that the installed
system software is still exactly what it was intended to be?
(Or, I guess, a third option would be that it's just some security
theatre to make people feel more comfortable about their system's
integrity, without actually adding any technical guarantees.)
For basic integrity checking, I'm finding the dpkg patch I posted the
other day works fairly nicely -- I've reinstalled the handful of
packages that don't provide md5sums files so dpkg would generate the
hashes file for me, and now I've got hashes for every package on my
system, without having to worry about policy getting changed or
packages getting reuploaded, or having to worry about bugs like any
random packages I might use not following the new policy.
And now that I actually look at debsums, rather than just checking
with md5sum -c directly, I see debsums already gets invoked by apt by
default to ensure that there's an md5sums file for every package. And
that's been there for a fair while, based on Bug#132767.
If the idea is just to catch a wide swathe of accidental errors,
doesn't it make sense to stick with md5 as being cheap and unlikely to
have accidental collisions, do the md5sum generation in either apt or
dpkg to guarantee it's done for all installed packages, and leave it
at that? That means we could get rid of a bunch of policy and code
from package build scripts, which seems like it could only be a good
thing; and it also seems pretty easy to do for squeeze (since it's
already done as far as apt is concerned, and there's a patch for dpkg
if desired, and no other packages need to be changed).
The only drawback seems to be that you end up verifying what was
actually installed, and that might differ from verifying what was
meant to be installed in the event that the deb you're installing gets
corrupted while you're reading it, despite having previously passing
its own secure hash check.
OTOH, if the idea is to do more than just basic integrity checking of
dpkg-installed files, to aid in detection of and recovery from
malicious/deliberate changes, it seems like there's a lot of things
that ought to be done differently to how debsums/pkg.md5sums work
(secure hash, checking conffiles, stuff in /var, checking added files,
checking additional diversions, preventing
addition/deletion/modification of the md5sums files...).
(Well, better handling of the md5sums files themselves could be useful
for basic integrity checking too -- a disk/fs error that trashes files
in /var/lib/dpkg/info/ can be inconvenient too)
Cheers,
aj
--
Anthony Towns <aj@erisian.com.au>
Reply to: