>>"Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
>> 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.
What is undetectable? The fact that ssh is buggy? Or that I
further compromised it? The upstream fault can't be identified by any
hash schema (and both out proposals are just that).
>> 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> With my scheme you check the Package/Relase files that you
Jason> kept (optional, of course) and you will detect this right
Jason> away.
How shall you detect the ssh is buggy? (We both can identify
ssh being replaced, neither can do anything about the upstream bug)
Jason> Oh please, my example must be a serious concern for anyone
Jason> doing post-intrusion clean up - you can't just dimiss it just
Jason> because per-deb sigs cannot ever solve that problem. That's
Jason> the entire point of the other method :P
How so? We are talking about a forensic boot from known good
media to determine if a binary on the machine is bad, and you bring
up the case where at some point of time some version of
aforementioned binary was buggy and had a security problem. Sure,
security problems in packages are an issue -- but a different issue
from the one we are talking about.
>> 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> This will never happen. A 30G mirror hit to add sigs is
Jason> unnacceptable.
Another strawman. Debian shall never make all current packages
buggy. What shall happen is that all future packages shall have this
signed filelist -- and somewhere down the line, perhaps flush out the
remaining packages once their number falls low enough.
Jason> The key that signs the release file(s) for stable releases are
Irrelevant. There is not a small suppl;y of keys, we can
generate a separate key for daily signing, and we know it is a low
security key.
Jason> well secured and only used during the release process, it is
Jason> infeasible to use them on .debs in the archive.
I see. I can see the following things happening"
a) The incoming dir is scanned, sigs checked and moved to the install
dir
b) dinstall is run, and packages moved from install to thearchive and
the changes file moved to DONE
c) The packages files are regenerated
d) The Release files are generated, and signed.
Why can't package/filelist signing be doen either during
dinstall, or before dinstall is run? What is so very unfeasible?
>> 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> IMHO per packages signatures will never have a significant
Jason> role in Debian proper. I belive the model cannot be made to
Jason> work sufficiently well for us.
Opinions. Yes. Well, I think that signed packages shall indeed
have a role. I see no technical reason for them not to work. I have
been offered key management as the bugbear why public key systems
shall not work; but, for the most part, I have personally had very
few problems reading peoples sigs in mailing lists (similar domain of
key management).
Additionally, if we do have a low security key signing
packages and file lists, it significantly raises the bar for forging
Jason> However, I belive Progeny was making effective use of them -
Jason> as I said, I don't care, both methods need to exist.
cool, we agree here.
>> 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> No, the filelist does not have to be present in the .deb, only
Jason> the signature (ie during .deb signing the file list is created
Jason> in /tmp, it is signed and the signature included in the .deb,
Jason> the file in /tmp is discarde). dpkg can produce the file list
Jason> on the client side. This is much better because it immediately
Jason> enables the entire archive, not just those packages that
Jason> happen to have been re-uploaded.
This is an interesting idea. But I want to know which file is
corrupt, I need the actual file list -- not just that the whole
package is now in an untenable state. If there is a file list, and I
can verify the list is intact, then it can tell me which file I need
concentrate on.
You seem to be entirely focussed on high bandwidth, replace
the whole package approach, I prefer to go finer grained.
>> 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''.
Jason> See flame-war on -private for so many reasons why this just is
Jason> ineffective..
I saw the war. There is a significant difference between the
two cases. There we proved that merely signing the packages was not
as good as providing a chain of verification from release file -
package file .deb; however, having both ensure that if the key
management has been accomplished, individual packages can indeed be
checked.
>> (In real life, my colleages have had to sneaker-and-floppy-net
>> code over to protected networks with no connections outside; code
Jason> And this would be a situation that has nothing to do with
Jason> Debian where having debsigs in general can be very good. That
Jason> does not mean it is good for Debian.
Debian ougfht to go further in empowering our users than
merely saying we have secured the primary distribution ppeline for
our packages, as long as you use the primary pipeline and store
several hundred MB's of apckages files yuou are going to be OK.
Signed packagfes and signed file lists shall take verification
beyond the primary debian pipeline.
And that can only be good.
manoj
--
Fortune suggests uses for YOUR favorite UNIX commands! Try: [Where
is Jimmy Hoffa? (C shell) ^How did the^sex change operation go? (C
shell) "How would you rate BSD vs. System V? blow (C shell) 'thou
shalt not mow thy grass at 8am' (C shell) got a light? (C shell)
!!:Say, what do you think of margarine? (C shell) PATH=pretending!
/usr/ucb/which sense (Bourne shell) make love make "the perfect dry
martini" man -kisses dog (anything up to 4.3BSD) i=Hoffa ; >$i; $i;
rm $i; rm $i (Bourne shell)
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
