Re: concrete steps for improving apt downloading security and privacy
-BEGIN PGP SIGNED MESSAGE- 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: https://wiki.archlinux.org/index.php/DeveloperWiki:Package_signing 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 -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTx5HLAAoJEKWX1kB3NXekY2oH/jBCo4+9c07Y7GNRaM1rkXh6 zr8vYG6tQJDco7Imf2ug1CrSHKUe5nIziwlj0qolq8D0eE33TDfOsztPo5WaqFw6 w5xXwP03cf+pR6VBO+/4fNHV6c/uW29biVcktePvEBFQH5AW8778rM8u0RLNBTol cBnq2t3m5FjSQN4dmRqGrxaViSy9S2qoxThOajr8cmrT/dxRvf2t8aOj2z+REHkb 85DZVNcKXEYft0atkoQO8ihwg51vnVnjxYcUcy+hEEM6UryGJ3awN1tMipCmAisR lExNhqgjOghvbuzYP1B9MBhvDQGeLTjysfFfYELtOgVakAoyzTgV1gMNtVuYnn8= =pnyf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c791cb.4060...@bitonic.nl
Re: Debian mirrors and MITM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 31-05-14 12:55, Patrick Schleizer wrote: Joey Hess: [...] there are situations where debootstrap is used without debian-archive-keyring being available, [...] Please elaborate, which situations are these? Let me answer this: using debootstrap on non-Debian systems, a scenario likely to become more frequent with Debian running in Linux containers (LXC). However, caveats apply in these scenarios, I will illustrate one way to think about this - if not just to gather feedback (it applies not only to LXC/VMs but in general for the case of spawning new Debian systems): 1) you have a Debian CD that you have verified being authentic thanks to your web of trust, this will be the system you trust most with trust level T0. Let's say you got it from the warm hands of your favourite DD and you are jealously storing it away as good wine 2) you are running a non-Debian system as host, let's say you have a trust level Tx on this operative system (it can be anything, but also Debian) 3) using debootstrap *without* a trust path to get the archive signing keys is enough of a mistake, in this case drinking the HTTPS cool-aid doesn't fix the trust path e.g. you would multiply Tx by zero (APT security != SSL CA security) 4) to overcome the problem above, you have to use your host system (with trust level Tx) to get the archive signing keys or to get an already seeded Debian chroot. I prefer the latter, thus I would download an official CD or net install ISO (verifiable thanks to https://www.debian.org/CD/verify), that we will label with trust level Ty 5) at this point you can continue the installation of your derived Debian system, that will have same trust level Ty Theorem: in absolutely no case you can create a system with a higher trust level than its parent: Tx = Ty Let's depict scenarios where you want to achieve Ty = T0. If at (3) you went forward without trusted archive signing keys, Ty is 0 (this covers the case Tx Ty), so let's drop this scenario. If your host system with trust Tx is let's say SuperSecureLinux downloaded from malwareland, then: Ty = T0 iif (if and only if) Tx = T0 (You must trust malwareland more than or equally as Debian) If instead your host system has trust level T0 (you installed it with that lovely CD), then chain of trust is respected (given that you followed [4] and not [3]): Tx = T0 = Ty = T0 Sorry for the pseudo logic, hope it adds positively to the understanding discussion. Related threads: https://lists.debian.org/debian-devel/2004/06/msg01499.html Kind regards, - -- Giuseppe Mazzotta -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTidwBAAoJEKWX1kB3NXekxNgIAIdCDjMnIN5i9EtuQsqMvbYG lFmmgpygoQZFcibptEJsoIYxsY6RK1XlcPh8F4SvOSa4EGDKa9PTF/9uHW/K0bpW fWpmJuMr2r04DadUp9mQe8hNDnNqeog6OavwjkZ7ruM1BldyZVWD1IAcGFb0b0B6 gnZW3/CuDDD2u7OWBVhan4Aru7WdXa/gqCNMhOe1YjKku4bOdx+DpsWKpVAtXgK0 iSMqwYk4x8rV80uWRvdD14ft3Dx9wX170l/rfN4q9/ut2gzqq/FPVs/RehURJSzD ZNP92nTrqt6yqRxLTNDZiV2HbBYjcMri8ACT3ycuNjLdKTEfwVHfq5OvszdV7oM= =PMc1 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5389dc01.1050...@bitonic.nl
