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

Re: concrete steps for improving apt downloading security and privacy

On 07/16/2014 08:06 AM, Holger Levsen wrote:
> Hi,
> On Mittwoch, 16. Juli 2014, Michael Stone wrote:
>> Yes you are--what you described is exactly how the Release files work.
> Well, there are (many) other .debs on the net which are not part of our 
> releases, so it still seems to me that making .changes files accessable in 
> standardized ways could be very useful.

What I'm talking about already exists in Debian, but is rarely used.  dpkg-sig
creates a signature that is embedded in the .deb file.  So that means no
matter how the .deb file got onto a system, that signature can be verified.
I'm proposing to start making dpkg-sig a standard part of official .deb files.
 This can be done in stages to make it manageable.  Here's a rough idea of that:

1. Adding a 'builder' signature should be easy to start with, make `debsign`
also run `dpkg-sig --sign builder` on any .deb files it finds.  I believe that
`dpkg -i` will already try to verify a signature if it exists.

2. add something like `dpkg --require-debsig` to force checking of the
dpkg-sig signature.  This would be optional to start with, and complimentary
to the already existing `dpkg --no-debsig`.

3. make `dpkg-buildpackage` call `dpkg-sig --sign builder --sign-changes full`
to sign packages.

4. etc.

As for Michael's complaint that I have not described a real problem, I have
tried already in the thread, so I'll try again in bullet points:

* TAILS is a Debian-based live CD
* the core system image by definition cannot be modified (live CD)
* it has a feature for persistent storage of files on a USB thumb drive
* it also can save apt cache/lib to that persistent store
* it will automatically install packages on boot from that store
* mostly people use TAILS in online mode
* there is a fully offline mode in development
* offline TAILS cannot verify the packages if apt lists are > 2 weeks
* updating the apt cache/lib is painful on an offline machine
* an offline machine's threat model is drastically simpler

On top of all that, each update increases risk of compromise on offline
machines because each new update provides a vector to run a script or
introduce new code that otherwise does not exist (no network!).  And any
decent attacker with physical access to the machine will always get in.

Other people want to be able to directly download .deb packages and have then
verified as part of the install process.  This is not my primary concern, but
I do think it is a valid one.  It would also be addressed by fully support of


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: