Re: concrete steps for improving apt downloading security and privacy
On 07/14/2014 01:57 PM, Michael Stone wrote: On Mon, Jul 14, 2014 at 01:22:10PM -0400, Hans-Christoph Steiner wrote: Or, you could make use of the Check-Valid-Until and Min-ValidTime options in apt.conf. There's a reason things are done the way they are, and you probably aren't going to find a lot of interest in getting people to do a lot of work to create a system which is duplicative at best and less secure at worst. Sure, those options would work well for people who understand them and want to tweak them. I'm not interested in that. I'm currently working on a TAILS-based system for running build and signing processes on machines that _never_ go online. So that means that changing the apt config is not an option. I'm working with apt-offline currently and that helps a lot. You're making an assertion and not supporting it. Changing a configuration parameter is unacceptable, but switching to an entirely different package trust model is ok? You care very much about the trust path to debian packages but not anything else (like the software that's installing them?) Seems like a weird problem, but maybe you're just not fully explaining it. If that's really the constraint set I guess it may be a case of you created your problem, so you get to fix it. TAILS is a live CD, but provides a method of installing and maintaining new packages on top of what is provided by the live CD. That means those packages are stored in an encrypted stash, and are installed on each boot. So in order to use this feature, the apt cache needs to be refreshed using apt-offline at least every two weeks, otherwise the packages won't be installed since apt can no longer validate them. Have you actually tried setting Acquire::Check-Valid-Until off; in apt.conf? What was the result? How do you propose managing a distro that mostly needs apt as is, but other times need Acquire::Check-Valid-Until off;? In other words, how would you manage a distro that sometimes uses apt as it was designed, and other times has to tweak in ways that would break the main use case? That sounds like a recipe for lots of edge cases and bad bugs. The situation in TAILS in not like normal Debian installed, but it basically the same for any live CD that has the option of installing additional packages from a persistent store. TAILS is mostly meant to be on online system, but fully offline support is in the works. Having signatures in .debs is entirely complementary to the existing apt system. It does not change how apt works at all in the normal network mode. The apt metadata would be used to verify that repo information is up-to-date, downloaded packages are intact, etc. Then the moment of install would use the signature in the .deb to verify that the .deb is intact and signed by a trusted key. Right now, `dpkg -i package.deb` does not verify against any signature. So for the offline system, if the .deb files have signatures, the .deb files can be copied on the offline machine however (apt-offline is a good option, but others are possible), then they can be installed, uninstalled, etc. after verifying that the signature in the .deb is trusted. So really, this would not be modifying apt so much as modifying `dpkg -i`. .hc -- 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/53c564a8.4000...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On Tue, Jul 15, 2014 at 01:28:08PM -0400, Hans-Christoph Steiner wrote: How do you propose managing a distro that mostly needs apt as is, but other times need Acquire::Check-Valid-Until off;? In other words, how would you manage a distro that sometimes uses apt as it was designed, and other times has to tweak in ways that would break the main use case? That sounds like a recipe for lots of edge cases and bad bugs. Um, so does your suggested change. Using apt with the valid check off is fundamentally equivalent to using signed .debs. Both mechanisms have the same failure modes, but one is a configuration change and one reworks the trust path to get to the same place. is up-to-date, downloaded packages are intact, etc. Then the moment of install would use the signature in the .deb to verify that the .deb is intact and signed by a trusted key. Right now, `dpkg -i package.deb` does not verify against any signature. This is funcationally the same thing as checking that the hash of the deb is the same as the one listed in the Releases file (or apt-cache show) before installing the deb. You could do that in a wrapper. So for the offline system, if the .deb files have signatures, the .deb files can be copied on the offline machine however (apt-offline is a good option, but others are possible), then they can be installed, uninstalled, etc. after verifying that the signature in the .deb is trusted. So really, this would not be modifying apt so much as modifying `dpkg -i`. Right, as I said, a complete reworking of the trust path (new code, new bugs, etc.) to get essentially the same result. It sounds like what you need to do to get the result you're talking about is grab the releases file along with the deb, validate the sig on the releases file (except ignoring the expiration), verify the hash of the .deb, then install the .deb. Depending on the specifics of the implementation you could do that from an apt command line by setting the Check-Valid-Until via -o or by writing a dpkg wrapper. In any event it shouldn't be all that much code and certainly much less what you're proposing. (I'd also hope that your front end would at least tell the user how old the Release file is, and that the distributor recommends checking for a newer version. The expiration mechanism is important to ensure that people aren't installing old/vulnerable versions of trusted packages--which may be equivalent to installing trojan packages.) 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/6e73f5b0-0c49-11e4-ac7f-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On 07/15/2014 02:11 PM, Michael Stone wrote: On Tue, Jul 15, 2014 at 01:28:08PM -0400, Hans-Christoph Steiner wrote: How do you propose managing a distro that mostly needs apt as is, but other times need Acquire::Check-Valid-Until off;? In other words, how would you manage a distro that sometimes uses apt as it was designed, and other times has to tweak in ways that would break the main use case? That sounds like a recipe for lots of edge cases and bad bugs. Um, so does your suggested change. Using apt with the valid check off is fundamentally equivalent to using signed .debs. Both mechanisms have the same failure modes, but one is a configuration change and one reworks the trust path to get to the same place. is up-to-date, downloaded packages are intact, etc. Then the moment of install would use the signature in the .deb to verify that the .deb is intact and signed by a trusted key. Right now, `dpkg -i package.deb` does not verify against any signature. This is funcationally the same thing as checking that the hash of the deb is the same as the one listed in the Releases file (or apt-cache show) before installing the deb. You could do that in a wrapper. So for the offline system, if the .deb files have signatures, the .deb files can be copied on the offline machine however (apt-offline is a good option, but others are possible), then they can be installed, uninstalled, etc. after verifying that the signature in the .deb is trusted. So really, this would not be modifying apt so much as modifying `dpkg -i`. Right, as I said, a complete reworking of the trust path (new code, new bugs, etc.) to get essentially the same result. It sounds like what you need to do to get the result you're talking about is grab the releases file along with the deb, validate the sig on the releases file (except ignoring the expiration), verify the hash of the .deb, then install the .deb. Depending on the specifics of the implementation you could do that from an apt command line by setting the Check-Valid-Until via -o or by writing a dpkg wrapper. In any event it shouldn't be all that much code and certainly much less what you're proposing. (I'd also hope that your front end would at least tell the user how old the Release file is, and that the distributor recommends checking for a newer version. The expiration mechanism is important to ensure that people aren't installing old/vulnerable versions of trusted packages--which may be equivalent to installing trojan packages.) Mike Stone There is already an existing format for signing and verifying .debs, the signing keys infrastructure is already in place, there is a clear spot to validate on install, doing some hacked together dpkg wrapper sounds like a good way to prototype, but a bad way to widely deploy a working system. I'm not saying that adding .deb signature validation to `dpkg -i` would be trivial and without risk. But the idea of validating signed package files on install is hardly revolutionary or even novel any more. Indeed it is pretty widespread: think Android, Fedora, Java, iOS, etc. I think it is the cleanest approach for the problem that I've outlined. .hc -- 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/53c58e06.3030...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On Tue, Jul 15, 2014 at 04:24:38PM -0400, Hans-Christoph Steiner wrote: I'm not saying that adding .deb signature validation to `dpkg -i` would be trivial and without risk. But the idea of validating signed package files on install is hardly revolutionary or even novel any more. Indeed it is pretty widespread: think Android, Fedora, Java, iOS, etc. I think it is the cleanest approach for the problem that I've outlined. Except that you haven't addressed *at all* why the current mechanism is insufficient, except that you don't like it and want to do something else instead. You understand why that argument isn't particularly compelling. 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/934303a6-0c60-11e4-b95c-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
Hi, On Dienstag, 15. Juli 2014, Michael Stone wrote: Except that you haven't addressed *at all* why the current mechanism is insufficient, except that you don't like it and want to do something else instead. AIUI Hans-Christoph wants something else _also_, not instead. And technically I think those signed .debs even exist already, via hashes in signed .changes files. Or am I getting something wrong? cheers, Holger signature.asc Description: This is a digitally signed message part.
