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 <hans@at.or.at> 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.
>
Reply to: