Re: Bug#132767: debsum support should be mandatory
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)
Beacuse post-intrusion you *can* answer the question 'Is this machine
Debian 2.2r6' when you have release data. From there you can make
statements about the known buggyness of the packages installed. The goal
is to measure against the current state of the art in Debian.
> 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
No - that is a narrow viewpoint. You need to establish the sanity of
everything against a known valid state. 'All packages ever released by
Debian' is definately not a known valid state.
Essentially it is like this - you install debian stable 2.2 w/ all
security updates. You know the machine has no known exploitable holes. It
is cracked some how. Debian advertises post-instrusion clean up via a
forensic boot. The admin does this, finds no errors. Woops, ssh was
downgraded and the machine has a remote root hole. Crackers re-enter at a
later date. I want to prevent that case by detecting that the remote-root
ssh is not part of stable 2.2 w/ security updates.
> 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.
The file can optionally be re-created and saved by dpkg on extraction. It
does not have to be in the .deb for dpkg to write it to
/var/lib/dpkg/info.
The huge benfit is that once dpkg is patched every existing .deb will
generate a hash file. Since the .debs don't change this also means we can
immediately cover all file lists with the release key. This is good and is
really all I want.
Jason
Reply to: