Hi,
preamble: the second patch was very hard to deal with as it is based
on an old version of the draft, and fixes things that were already
fixed in Git... in other ways.
alan@??? wrote (04 Jan 2011 17:37:50 GMT) :
>> Hi,
>>
>>> 1. First, about what you call the « post-mortem analysis ». I like the
>>> term but I want to know whether it is a canonical term for security
>>> experts or something that might need a bit more explanation.
>>
>> I think the keyword here is forensics. Could go instead of analysis.
> Hmm… Having a look at the wikipedia entries for 'forensics' and
> 'computer forensics' this term is explicitly linked to a legal context, see:
> « Forensic science (often shortened to forensics) is the application of
> a broad spectrum of sciences to answer questions of interest to a legal
> system. »
> « Computer forensics (sometimes computer forensic science[1]) is a
> branch of digital forensic science pertaining to legal evidence found in
> computers and digital storage media. »
> I'm not sure we want to be that specific. So I'll stick to 'post-mortem'
> and add a drop of plain 'data recovery' to be more explicit.
I've merged + adapted + generalized your changes to remove the
forensics word from the draft.
>>> Then, apart from the threat model, the document is not very explicit
>>> about this issue. There might not be much to say but I think that it
>>> should at least be mentioned in the requirements, part 2 :
>>> - What is required for a PELD to prevent from post-mortem analysis?
>>> - How do we think this should be provided?
>>
>> I agree, we should improve this.
> See the second patch. I tried to do the following :
> 2.1.2 Working on sensitive documents:
> Be a bit more vague and explain more why the intent should be to go for
> a white list approach (without calling it like this) and not keep
> anything unless ask to do so.
> 2.2.1 The goal of the attacker:
> Be more explicit about the swap and RAM issues.
> 2.7 Data recovery requirements:
> Adding this part by basically recycling stuff from the old 2.1.2.
This is already solved in the draft, in other ways though, since, hrm,
quite some time. I've thus merged tiny changes from this second patch
that, well, did several things. Most of it is unfortunately lost work.
Please review the draft's current state and express your concerns
if needed.
>>> Again in part 3, while presenting the implementation we should explain
>>> more about what Tails does to achieve that. There is a paragraph on
>>> host system RAM but I guess we can find more to explain, like :
>>> - I could imagine that some LiveDistros detect the swap areas and use
>>> them. Do we ? ;)
>>
>> Hints to the one who will write this part:
>>
>> - not using live-boot's swapon option
>> - config/chroot_local-hooks/03-noswap
>> - config/chroot_local-hooks/05-disable_swapon
> Great. The first patch is about that.
Was already done. Sorry.
> Even though I couldn't find the 13swap file deleted by
> config/chroot_local-hooks/03-noswap anywhere.
The swap-enabling code has moved a lot and is now part of live-boot.
This file does not exist anymore in recent live-boot versions.
It's now done in scripts/live-bottom/12fstab, which we don't want to
delete as it does useful stuff. We now need to keep an eye on
live-boot changes, to make sure the SWAPON toggling setting is not
made buggy again. I'm doing this.
>>> - I could imagine that some LiveDistros read the disks and possibly
>>> mount the available partitions automatically. Same thing.
>>
>> Hints to the one who will write this part:
>>
>> - grep nopersistent config/amnesia
>> - probably a few GConf settings in
>> config/chroot_local-includes/usr/share/amnesia/gconf/
> Didn't do that ;)
Done.
Bye,
--
intrigeri <intrigeri@???>
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| Did you exchange a walk on part in the war
| for a lead role in the cage?
