Re: concrete steps for improving apt downloading security and privacy
On Thu, Jul 17, 2014 at 12:55:10PM -0400, Hans-Christoph Steiner wrote: Not without modifying the apt config. The point here is to have a working system that is tested and audited, rather than just a set of instructions or recommendations. That would be why you'd create a wrapper to faciliate the config changes necessary for your particular situation. Mike Stone -- 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/4bea5e4e-0dd9-11e4-b619-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On 07/17/2014 08:20 AM, Joel Rees wrote: > A little context? > > On Thu, Jul 17, 2014 at 1:26 AM, Hans-Christoph Steiner wrote: >> [...] >> * 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 > > What happens when you put your live-image CD or USB in a box whose > boot ROM or BIOS ROM has been overwritten through some vulnerability > and now contains a hook to a backdoor? > > I'm not going to say that the whole idea of a live-image system is > full of holes, but I personally do not trust anything important to any > of the live images I use from time to time on hardware I don't > control, except for the live CDs I use for repairing systems that have > gone belly-up. > > I have, in the past, brought live USBs home from work and booted them > on my home hardware. I don't do that any more. (I'd have to mount the > USB on a running system at home and verify the parts of the file > system that shouldn't change.) _All_ software installed is vulnerable to this kind of exploit. Using a live CD does not address the issue of an untrusted BIOS any more than using a normal Debian install. The live CD does address lots of other issues that cannot be addressed easily in a normal Debian install. Same goes with offline vs online systems, both are entirely vulnerable to already exploited BIOSes. An offline machine reduces the risk since an exploited BIOS could only be installed by gaining physical access. >> * 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 > > Yes it can. Not without modifying the apt config. The point here is to have a working system that is tested and audited, rather than just a set of instructions or recommendations. .hc >> * updating the apt cache/lib is painful on an offline machine > > Don't turn your nose up at wrappers. Lots of very useful stuff around > that is just wrapping something else. Quite stable, if the wrapper > does its job fully. > >> * an offline machine's threat model is drastically simpler > > I disagree with that, as you see. > >> 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!). > > I suggest looking at the reasons for that again. > >> And any >> decent attacker with physical access to the machine will always get in. > > Isn't this a red herring? > >> 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. >> >> .hc >> > > I understand the hesitation. Having individual packages signed is a > good lead to a false sense of security. > > One point I strongly suggest considering is, for example, that > firefox, direct from mozilla.org, on stock debian, is more likely to > have vulnerabilities than firefox (iceweasel) loaded from the debian > packages archives. > -- 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/53c7ffee.6060...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
A little context? On Thu, Jul 17, 2014 at 1:26 AM, Hans-Christoph Steiner wrote: >[...] > * 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 What happens when you put your live-image CD or USB in a box whose boot ROM or BIOS ROM has been overwritten through some vulnerability and now contains a hook to a backdoor? I'm not going to say that the whole idea of a live-image system is full of holes, but I personally do not trust anything important to any of the live images I use from time to time on hardware I don't control, except for the live CDs I use for repairing systems that have gone belly-up. I have, in the past, brought live USBs home from work and booted them on my home hardware. I don't do that any more. (I'd have to mount the USB on a running system at home and verify the parts of the file system that shouldn't change.) > * 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 Yes it can. > * updating the apt cache/lib is painful on an offline machine Don't turn your nose up at wrappers. Lots of very useful stuff around that is just wrapping something else. Quite stable, if the wrapper does its job fully. > * an offline machine's threat model is drastically simpler I disagree with that, as you see. > 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!). I suggest looking at the reasons for that again. > And any > decent attacker with physical access to the machine will always get in. Isn't this a red herring? > 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. > > .hc > I understand the hesitation. Having individual packages signed is a good lead to a false sense of security. One point I strongly suggest considering is, for example, that firefox, direct from mozilla.org, on stock debian, is more likely to have vulnerabilities than firefox (iceweasel) loaded from the debian packages archives. -- Joel Rees Computer memory is just fancy paper. The CPU and IO devices are just fancy pens. -- 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/caar43im5bnalp1fny9j63cqezizpf0uxgm-txufasc-lj6m...@mail.gmail.com
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
