[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: PATCH: package verification in dpkg

On Fri, 9 Mar 2001, Ben Collins wrote:

> > I see the deb signature stuff as providing potentially very high security,
> > but the user has to be vigilant and maintain a very strict and complete
> > policy. 
> The policies are not meant to be written by users, but by distributors
> of the packages. IOW, Debian, Progeny, etc.

Then IMHO they are not very worthwhile. When the best Debian can do is say
'all packages are signed by one of these 800 keys' :P
> Only in certain situations, and that situation is when using apt.
> Restricting security to a tool that doesn't allow you to bypass it and
> get the same security, is not perfect. Most users will at some point
> install a .deb directly, without the user of apt.

It is not limited to APT. It is limited to the data that is available via
APT. Debs cannot be checked alone because there is not enough information
to associate them with a release. (and before you go explaining the deb
release signatures in this scheme remember that the ftp masters have
rejected that idea)
> Yes, the debsig-verify tool does allow you to pass deeper data. Have you
> looked at the tool at all? No, you can't do this through dpkg, so you

I was not talking abou the debsig-verify tool. I was talking about the
integration with dpkg, which does not have any of these features.

If your answer is going to be to just always use debsig-verify directly
then scrap the dpkg integration :P

> > It does not show which signatures are present signing dates, etc, which
> > may very well allow 'obsolete package' attacks to slip past.
> You've spoken of these "obsolete attacks" and yet, you've never given me
> an example of one which is actually a security risk. I don't see this as
> a problem which signatures need to address.

Oh I donno, stick that nice root exploitable openssh on a server that
looks surprisingly like security.debian.org and pollute a DNS cache
someplace. Users expecting to upgrade to a safe version will find the only
available version is this buggy one. You could even spoof the version in
the filename. Betcha most people won't notice the dpkg message is .1
digits off.

Log http/ftp transfers and automatically r00t he box after the buggy sshd
is installed.

The other one I like to bring up is the idea of a debian distribution that
looks alot like potato, except that every root exploitable daemon/program
is stuck at an older version. ''Worst of Debian'' 


Reply to: