Hey Russ, On Tue, Mar 9, 2010 at 13:57, Russ Allbery <r...@debian.org> wrote: > Joey Hess <jo...@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 <a...@erisian.com.au> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87b3a4191003091145p26467cag8d2d4cfb9dc20...@mail.gmail.com
