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
Reply to: