Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server hard drive freespace scrubbing #88

Closed
Taipo opened this issue Oct 16, 2013 · 4 comments
Closed

Server hard drive freespace scrubbing #88

Taipo opened this issue Oct 16, 2013 · 4 comments

Comments

@Taipo
Copy link

Taipo commented Oct 16, 2013

Worst case scenarios are a journalistic organisation facing a direct raid by an adversary in a country that does not have laws protecting the rights of journalists/sources.

This goes beyond having apache logging disabled and secure file destruction

It is important that the source and journalist servers have their free space scrubbed regularly to remove not just the deleted file content but also the meta data history to prevent a nation state adversary from rebuilding an activity, where proof of the activity itself could be enough to begin incriminations against a journalist.

If that is an accepted premise, how well can a solid state drive have its free space scrubbed, or individual secure file erasing?
http://www.usenix.org/events/fast11/tech/full_papers/Wei.pdf

@fpietrosanti
Copy link

If the I/O operations are done over a Luks encrypted filesystem this is not going to be required.

@Taipo
Copy link
Author

Taipo commented Oct 17, 2013

I would have thought restoring deleted encrypted files is no different to any other restore process if the adversary has physical access to a working server irrespective of the drive partition encryption method being used. Am I misunderstanding this?

@garrettr
Copy link
Contributor

I think this is less of a concern due to the implementation of the anti-forensic measures in #862, but we might still consider implementing it for some additional defense in depth.

@garrettr garrettr added this to the 0.4 milestone Mar 25, 2015
@psivesely psivesely removed this from the 0.4 milestone Mar 2, 2017
@redshiftzero redshiftzero added this to the Some Day milestone Oct 6, 2017
@redshiftzero
Copy link
Contributor

Since swap is disabled (#1626), we use srm when deleting documents (#131), and we never write plaintext to disk in the first place (#862), I'm closing this issue. Feel free to comment if you disagree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants