[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <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.)

> * 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.

Reply to: