>>"Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
Jason> On Sat, 9 Feb 2002, Manoj Srivastava wrote:
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> Beacuse post-intrusion you *can* answer the question 'Is this
Jason> machine Debian 2.2r6' when you have release data.
Rarely a question that is interesting to answer.
Jason> From there you can make statements about the known buggyness
Jason> of the packages installed. The goal is to measure against the
Jason> current state of the art in Debian.
Only if the machine _has_ remained true to a known
release. Unfortunately, a large class of machines are selectively
upgraded. My contention is that the granularity of a Pavckage is a
more natural one than the level of a packages files -- and signed
filelists, built into the package, offer iwder coverage than the
release file mechanism (are daily release files signed yet?)
>> 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
Jason> No - that is a narrow viewpoint. You need to establish the sanity of
Jason> everything against a known valid state. 'All packages ever released by
Jason> Debian' is definately not a known valid state.
Look at the granularity of the package. If we have signed
filelists for each package, then we can indeed buildup the security
picture of the whole machine
Jason> Essentially it is like this - you install debian stable 2.2 w/
Jason> all security updates. You know the machine has no known
Jason> exploitable holes. It is cracked some how. Debian advertises
Jason> post-instrusion clean up via a forensic boot. The admin does
Jason> this, finds no errors. Woops, ssh was downgraded and the
Jason> machine has a remote root hole. Crackers re-enter at a later
Jason> date. I want to prevent that case by detecting that the
Jason> remote-root ssh is not part of stable 2.2 w/ security updates.
Different issue to what we were talking about. But I sese the
validity of this.
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.
Jason> The file can optionally be re-created and saved by dpkg on
Jason> extraction. It does not have to be in the .deb for dpkg to
Jason> write it to /var/lib/dpkg/info.
But then it can't be signed, and it can be mandled on the
machine, unless we go and store all the packages files and all the
corresponding release files.
Jason> The huge benfit is that once dpkg is patched every existing
Jason> .deb will generate a hash file. Since the .debs don't change
Jason> this also means we can immediately cover all file lists with
Jason> the release key. This is good and is really all I want.
This is indeed a benefit, and I can see how it is a good
interim measure. Perhaps if there is no internal filelist, dpkg can
craft one at install time. As more packages start shipping file
lists, we can use them as a better verification base.
manoj
--
I always say beauty is only sin deep. Saki, "Reginald's Choir Treat"
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
