Re: Bug#132767: debsum support should be mandatory
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.
It would actually be quite trivial to keep track of the Package files, and
it handily nullifies all your arguments. Disk space is cheap, if you are
serious about tracking unstable you can easially waste 100M for package
data. Stable requires only 1 set of course.
APT based code can quite trivially maintain the database, it's a really
trivial problem.
> 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
If you keep the package files as you said then it all works exactly the
same way as signing the individual filelists.
> 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 your scheme the attacker only has to install one of our many
root-comprimize enabled SSH's and it is just as undetectable. With my
scheme you check the Package/Relase files that you kept (optional, of
course) and you will detect this right away.
You don't loose any security, you burn some space with extra
package/release files - but who really cares? You gain the same advantages
that singed releases provide over signed debs regarding key and release
management! It's a good workable scheme.
> 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.
I don't really care about the discussion of the merits of 'the debsig' way
vs 'signed release' way. Both are useful to some people, but only signed
releases are supported by Debian - so any file list security scheme *MUST*
work in that context.
We can easially have both, I don't see what the point of discussing the
merits of the two schemes *again* is. All I want is to ensure that we can
have both.
It's very simple:
1) Decide on the file list format
2) Have dpkg write it as it unpacks (makes the corruption people happy)
3) Have debsigs generate a signature that covers the filelist hash
(and the rest of the meta-data to further help agaist the version-forging
attack). Key management issues/etc can be managed in the usual
debsigs way
4) Devise some way to distribute the file list hashes protected by
the release signature. Key management and release management is
managed in the usual Debian way (same keys)
Dpkg has an internal tar for extraction, and it now has a configration
file, it should be trivial to have it optionally write out the file list
data - someone make a patch already :P Heck, I'll even make a reference
deb->file list converter if it will help.
Jason
Reply to: