Re: [Tails-dev] Last steps toward enabling incremental upgra…

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: The Tails public development discussion list
Subject: Re: [Tails-dev] Last steps toward enabling incremental upgrades by default [
Hi Jacob,

Jacob Appelbaum wrote (17 Dec 2013 19:03:03 GMT) :
> I would suggest including a small shell script and one utility to test
> the integrity of a tails release - something as simple as md5deep. Once
> we start to change the Tails disk, we really want to ensure that an
> attacker can't stick around past a reboot.


> I could write such a utility but I'd like some feedback - for example -
> should we run this after install and put the current state into the
> persistence? Should we keep a list of hashes of all possible updates, so
> that we can check a user's data set against a known good list?


> The easy bit is basically to write something to check the MBR, the
> partitions and then walk the file systems. It won't detect firmware
> changes to the disk drive (usb, sata, whatever) but it should be able to
> very easily detect any binaries that are changed. Obviously we'd need
> two tails disks to really be able to do this kind of basic forensics.


> Thoughts?


Thank you for suggesting this.

My general take on this is that *if* you have another, trusted Tails
device, which is required anyway to run any kind of integrity check,
then you can as well "Clone and Upgrade" it, and make the untrusted
one trusted again (modulo the MBR, that clone'n'upgrade does not
touch, which could be a worthy problem to tackle in itself; checking
the partition table could be worth it too, in case a *second*,
corrupted Tails was installed by the attacker).

So, unless I've missed something (which wouldn't be surprising, given
no threat model this feature addresses was described yet AFAIK), such
a feature would only be useful to answer the "was a given Tails device
persistently corrupted by an attacker" question, no?

Note that our #6397 ticket, and the temporary workaround I've proposed
last in the "2.0 milestone += supporting USB devices exposed as
non-removable?" thread, should be taking into account when reasoning
on this topic.

Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc