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

Re: debsums for maintainer scripts

(no need to CC: me as I'm subscribe)

> > Why do we have to make each of our users find a solution to generate this
> > from a _local_ mirror (or the system's .deb archive which shoulnd't be
> > trusted in the event of an intrusion) when we could do this ourselves and
> > provide the results?
> Thats why I want signatures so even after a compromise and reboot from
> a good medium the debs or md5sum lists from the compromised system can
> be trusted.

You can still have a valid signature but an invalid package (out of date 
with known security holes) installed, though.

> > It is not that much work and known good databases are really useful in
> > forensic investigation (see below or read Sleuth Kit informer issue #6,
> > http://www.sleuthkit.org/informer/sleuthkit-informer-6.html)
> Debian can provide such a database completly without any md5sums files
> in the deb. They are as it is realy useless.

No they are not, but it seems you did not understand my example at all.

> > > > 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.
> > > 
> > > 	If you want a list of such files, we have it now. If you want
> > 
> > We have the information, but it needs to be extracted. Not all users/admins 
> > now how to handle our archive, and there are no standard tools to do what 
> > I'm askin for (again, see below)
> Then write such a tool instead of wasting all mirror and users
> bandwith and diskspace.

I'm asking Debian mirrors to handle the file with the whole list of 
md5sums. Not users. Still, you are saying that users would need to have a 
_complete_ copy of the archive to generate that list or compare it against 
a local system.

> > If I want to do a security audit of a compromised system, taken offline, of
> > which I have a hard disk image, md5sums are _not_ useless. If I have a list
> > of known good checksums (provided by the vendor) I can compare them with
> If the vendor supplies the list you don't need any list in the debs
> themself. Thanks for prooving our point.

You do want that list too, again, you didn't read or understand my example. 
I'm not proving your point.

> You argue against people who are basically on your site. A known good
> list of md5sums is usefull. A md5sums file inside the deb does not
> provide this. We agree on that.

(I guess site -> side?)
We don't agree in this, I want both: the known good list of md5sums 
provided in Debian mirrors and the md5sums file inside the debs to use them 
both for comparisons against the files and against themselves.

> > Do you really want to say that the only way a forensic investigator could
> > have of checking a hard disk image contents is downloading the _full_
> > Debian archive in order to compare that to the disk? What if the system is
> Thats how it is now. in package md5sum files, what this is all about,
> doen't change that a bit.

No, it is not. That information can be easily extracted to a single file 
and provided in the mirror so you can download that file instead of all the 

> > stable+security updates, how would you remove the false positives in your
> > above example? 
> You read every single file thats changed and find out if that is an attack.

What do you mean read? Do you mean checking the timestamps? Checking the 
md5 hashes? I'm sorry but I don't see your point.

> > Now, imagine we have this file, and we have the local md5sum database in 
> > the image copy of the compromise system. I could check rather easily:
> > 
> > 1.- if the vendor provided md5sum files in the database matches the local 
> > md5 hashes information for files in the system.
> That means you throw th local one away and download a known good one.

No, it meas I use both to determine if the local database has been tampered 
or not. The fact that the local database has been tampered means I cannot 
trust it, but it also highlights a targeted attack (current rootkits do 
not mess with package information)

> (1) downloads you a known good copy which mans downloading all debs
> as it is now.

I'm asking for two things here, as I said before, md5sums in the .debs 
and a Contents-md5sums file in the mirrors which would be downloaded in (1)
you wouldn't need to donwload the archive.

> > > > So my vote goes to adding md5sums to policy.
> > > 
> > > 	We still don't vote on technical issues, thank god.
> > 
> > It was just an expression, obviously. Maybe it's not translatable. 
> > 
> > Friendly 
> > 
> > Javi
> You vote for providing md5sums files seperatly from the debs and not
> in the debs (and you probably would still agree by just providing a
> signature for locally stored/generated md5sum file verification). So
> your on our side.

Well, there are not really sides here. But again:

- I want md5sums to be stored in the local filesystem, I don't really care 
if they are inside the debs or not, as long as it's standard procedure and 
nobody has to hack apt.conf, dpkg or what else to have this. If we cannot 
provide a standard configuration for apt that regenerates this information 
then our only bet is md5sum files inside the debs.

- I want md5sums information provided in a off-site way by ftp sites and 
mirrors so I can compare it against the local database and against the 
files in the disk. Again, this could be generated by extracting the whole 
archive and running md5sum over the archive or (easier) by extracting the 
md5sums files from the .debs and putting them together.

Hopefully, I have expressed my views, I'm kind of tired of explaining this, 
language and e-mail getting in the way, so I will probably not go on 
discussing this.


Attachment: signature.asc
Description: Digital signature

Reply to: