Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)
Eduard Bloch <edi@gmx.de> writes:
> Moin Goswin!
> Goswin von Brederlow schrieb am Tuesday, den 02. December 2003:
>
> > > I would like to see the following things happen:
> > >
> > > - current md5sums file in control.tar.gz should contain
> > > checksums of really all files
> > > - a signature of the md5sums file should be stored either in
> > > control.tar.gz or in the ar file itself
> > > - new dpkg version should pickup the signature files and store them
> > > either in /var/lib/dpkg/info or in some alternative directory
> > > - modify debsums to check the signature as well as maintainer scripts'
> > > checksums
> > >
> > > Any additions, comments, etc.?
> >
> > If you think files of a deb are compromised on your system what makes
> > you thing the md5sum files are not? Storing the md5sum files on-site
> > will only help against accidental (or stupid) changes.
>
> Because you store the extra signatures of md5sum files in a separate
> location, as said above. But as Goswin and other stated before, the gain
> (securitywise) is low compared to the costs of extra signing and
> handling with the signature file. So I see another good method to verify
> the already installed files: create an extended version of the current
> Contents-ARCH files including the md5 checksums of each file from each
> package and sign this Md5Contents file with some official key.
That would be signed automatically every day. A compromised master
would make the file useless.
> > Also since the complete deb is just as save as the md5sumsfile
> > contained in the deb it is pointless to have such. People who realy
> > want to store the md5sums file should create it during install time
> > (let dpkg do that). The md5sums file still requires one to download
>
> As said before, some people may not run tripwire&Co. during the initial
> installation and enable such modification detection systems later. There
> should be a way to feed the database with known good md5sums afterwards,
> see above.
>
> > the complete deb from a trusted source to verify the installed
> > system. But then why not just do a 1:1 compare?
> >
> > After all this ranting about how useless a md5sums file is here's an
> > idea:
> >
> > 1. No md5sums files are contained in the deb itself.
>
> You mean in the deb as created by dpkg-deb during the build? Okay, the
> functionality may be moved to the second step (below), but then
> dh_md5sums should be converted to a dummy script and debhelper conflict
> with the older versions of dpkg-dev.
The existance of the file wouldn't hurt but making dh_md5sums a dummy
would be the upgrade path.
> > 2. dpkg-genchanges unpacks the deb (control and data) and creates a
> > sorted md5sums file (sorted by md5sum, by filename or whatever. But
> > reproducible). A signature of the md5sums file (md5sum of it?) is
> > then added to the change file.
>
> As we agreed on IRC, the contents of control.tar.gz should be included
> too. Idealy extracted temporarily into
> $tmpdir/var/lib/dpkg/info/pkgname.FILE so debsums gets full paths and
> has easy job later.
Another point mentioned on irc was that the original conffiles all
need to be preserved, at least the md5sum of each. When recreating the
md5sums file for verification purposes (if it's not created and stored
at install time) would have to have the original md5sums of all
conffiles or too many false positives would appear.
Comparing local conffiles against the original ones would be a local
matter and another step in auditing. Having the actual original
conffiles around for that would be better than just saying "was
modified" after comparing md5sums. For that reason (and for three way
diffs on updates) I would like dpkg to allways create a
conffile.dpkg-orig even when first installing. Alternatively a
/var/lib/dpkg/info/package.conffiles/ directory could be used to store
original conffiles or /usr/share/doc/package/example.conffiles/.
MfG
Goswin
Reply to: