>>"Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
Jason> On Fri, 8 Feb 2002, Manoj Srivastava wrote:
>> 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.
Jason> It would actually be quite trivial to keep track of the
Jason> Package files, and it handily nullifies all your
Jason> arguments. Disk space is cheap, if you are serious about
Jason> tracking unstable you can easially waste 100M for package
Jason> data. Stable requires only 1 set of course.
Not all my arguments. If the file list and the hash is part of
the deb rather than the the Packages file, it affords protection even
when the deb files are distributed piecemeal. Thus my scheme provides
protection even in cases of individual debs, you require the
infrastructure of Packlaes files and Release files in order to do
verification.
Keeping the signed filelist as part of the deb also simplifies
the security verification process, and keeping things simple is
desirable. (keeping three sets of files -- the file list, the
Packagres file that contains the filelist SHA1 sig, and the Release
file that contains the md5sum of the Packages file, in synch, and
around, is way too complicated, and it does not need to be so).
>> 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
Jason> If you keep the package files as you said then it all works exactly the
Jason> same way as signing the individual filelists.
Not quite the same. It adds complexity, increases the book
keeping infrastructure, and disallows the practice of users
sharing/transfering .debs on their own, without using the
Packages/Release/Apt mechanism. Bad idea.
I know you are focussed on Apt, but there is a word of package
installs that does not use apt/Packages files yet.
>> 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.
Jason> With your scheme the attacker only has to install one of our
Jason> many root-comprimize enabled SSH's and it is just as
Jason> undetectable. With my scheme you check the Package/Relase
Jason> files that you kept (optional, of course) and you will detect
Jason> this right away.
Strawman. No security mechanism is perfect, and no
verification system can detect bugs in the underlying process. Just
because there are bugs in packages that prevent perfect security does
not mean we should weaken security measures.
Jason> You don't loose any security, you burn some space with extra
Jason> package/release files - but who really cares?
I do. Disk space may be cheap, but that is no excuse for bad
design. And wasting diskspace may have significance for my Linux
based PDA. Or my Debian watch. Or my cell phone.
Jason> You gain the same advantages that singed releases provide over
Jason> signed debs regarding key and release management! It's a good
Jason> workable scheme.
I see no reason why signing the debs with the same key that
signs the Release file is so very evil. If dpkg allows for multiple
detatched sigs for each content block in the ar archive, we can have
the best of both worlds.
Jason> I don't really care about the discussion of the merits of 'the
Jason> debsig' way vs 'signed release' way. Both are useful to some
Jason> people, but only signed releases are supported by Debian - so
Jason> any file list security scheme *MUST* work in that context.
Are we so hard bound by current practice that we can't even
design a different way of working? Sure, signed release files ar all
we support now. But we are not talking about now -- we are talking
about changes that need to be made to provide cryptographic
verification of machines.
Jason> We can easially have both, I don't see what the point of
Jason> discussing the merits of the two schemes *again* is. All I
Jason> want is to ensure that we can have both.
Sure. Add the SHA1 sum to the Packages file as well if you
wish. Makes things easier for apt, I guess -- less code.
But it should not be the only way. As Adam Heath has said,
adding extra components to the ar archive shall be easy enough.
Jason> It's very simple:
Jason> 1) Decide on the file list format
Jason> 2) Have dpkg write it as it unpacks (makes the corruption
Jason> people happy)
I assume you mean for the sig to already have ben
generated. We may not be able to trust dpkg on the target machine; so
the file list has to be generated, and the signature as well, in the
deb itself. Or else dpkg becomes the single point of failure, and we
can't transition from a machine in an unknown state to a machine in
a known state.
Jason> 3) Have debsigs generate a signature that covers the filelist hash
Jason> (and the rest of the meta-data to further help agaist the
Jason> version-forging attack). Key management issues/etc can be
Jason> managed in the usual debsigs way
Ok.
Jason> 4) Devise some way to distribute the file list hashes protected by
Jason> the release signature. Key management and release management is
Jason> managed in the usual Debian way (same keys)
Well, I would like a detatched sig to be arttached to the .deb
as well at this phase, so that we do not need to rely on the
Packages/Relase file mechanism; and I would be able to distribute a
single .deb and still have the target machine be able to verify
things ``the debian way''.
(In real life, my colleages have had to sneaker-and-floppy-net
code over to protected networks with no connections outside; code
that I wrote, and provided phone support to install, but could not
get into the building due to security issues. I can see single,
audited .debs being installed that way ).
manoj
--
egrep patterns are full regular expressions; it uses a fast
deterministic algorithm that sometimes needs exponential space. Unix
manuals
Manoj Srivastava <[EMAIL PROTECTED]> <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
