Re: Bug#132767: debsum support should be mandatory
>>"Jason" == Jason Gunthorpe <jgg@debian.org> writes:
Jason> On Thu, 7 Feb 2002, Manoj Srivastava wrote:
>> If you have a broken dpkg/md5sum on the machine, the only way
>> to detect that after booting from known secure media (like a cdrom
>> you have audited) is if the hash file were generated (and known not
>> to be tampered because if a cryptographic signature) on another
>> machine.
Jason> This has all the same problems as signed .debs and brings in no signed
Jason> release goodness so *insert the usual complaint about signed .debs
Jason> accountability, Debian and blah*
I think not. More on this later.
Jason> To get this level of security I recommend we first dispose of
Jason> .md5sums and create instead a .filelist info file - this would
Jason> contain hash, permissions, symlink, device major/minor/etc
Jason> data.
Jason> Then, we add a new field to the packages file which would be called
Jason> 'FileList-SHA1' which is.. the SHA1 of this filelist.
See below why this makes this proposal as unusable as the
debsums one.
Jason> It is now possible to answer the question 'is this machine
Jason> Debian 2.1r5 and how many packages have a questionable
Jason> origin', which is really what you are talking about when you
Jason> say you want to validate an untrusted machine. Remmber you
Jason> cannot trust the status file and the .md5sum file gives zippo
Jason> insight into what version of the package you have installed.
Bingo. Without the signature on the hash file, network access
is _required_ to do any verification. Assuming, of course, that the
Packages file has stayed around. And that is the telling blow to your
solution. Packages files are ephemeral.
IN the real world, we had machines on unstable while in code
devel phase. The minute we went to beta, everything froze, including
the boxes. The versions of packages on the machine are not on Debian,
and the corresponding package files are gone as well.
Could I keep Packages file and the Release files? Sure. Way
more bloat. A simple signed file list is smaller, and less prone to
error. And unless you mean to keep track of which Packages files to
remove, man, it would get insane.
Also, wrong use case. I have installed debian packages on these
machines. I have a trusted media I can boot from. Now, unless I have
an online connection, I can't get the Packages file from Debian (if
it exists there anyway).
The idea is that I boot from a known good media (a cd rom with
some keyrings on it), mount the file systems, and check my machine. I
have a number of machines, and do not have space or connectivity for
a full mirror.
I can do checksums until I am blue in the face, but unless I
know the file list has also not been modified, I am getting
nowhere. The state of the machine is still unknown. As a cracker, the
minute I replace ssh, I'll go and change the file list (as you said,
maybe easy to compute). No signature, heh heh. No packages file
anymore. heh heh.
With a local filelist, and a signed SHA1 of the file, I can
immediately tag compromised machines. (This is espescially true if
dinstall creates a second detached sig of the hash file, so I only
need a single public key to test the validity of the files. Once we
have reasonable assurance the file lists have not been tampered with,
we are good to go. The second sig would be used only as a backup,
since its security is low, but covers me if my keyring is not quite
up to date.
I already accept code from the Debian boxes, so trusting an
auto generated sig from there is no worse than what we have. As far
as perfect security goes, it is no worse than accepting code compiled
on those machines. It certainly is better at protecting ourselves
against local attacks and mirror attacks.
Don't let perfect be the enemy of pretty darned good.
So, ar components:
debian-binary
control.tar.gz
data.tar.gz
filelist.gz
detatched-sig-of-filelist.gz
detatched-sig-of-the-whole-deb
Or something.
manoj
--
"Isn't it interesting that the same people who laugh at science
fiction listen to weather forecasts and economists?" Kelvin Throop,
III
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: