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

Re: concrete steps for improving apt downloading security and privacy

Hash: SHA512

On 16-07-14 18:26, Hans-Christoph Steiner wrote:
> 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 dpkg-sig.
I fully agree with Hans-Cristoph here. Looking at other distros, Arch
Linux' package manager has had a feature to enable SignedOnly packages
for a while now, and I found it extremely useful in my deployments.

Their wiki's related page is an interesting start to read about:

As far as I understand for Debian it's more a matter of improving
packaging best practices rather than developing/integrating new
features. If we have work to be done on both sides, it would be nice
to split it now and address the two concerns separately.

Kind regards,
- -- 
  Giuseppe Mazzotta

Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


Reply to: