Editing
Free space file system
Jump to navigation
Jump to search
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
This page documents a hypothetical free space file system (FSFS) [https://www.noisebridge.net/pipermail/noisebridge-discuss/2009-September/008176.html proposed] by [[User:Saizai|<span style="color:#006633;font-weight:bold;">Sai Emrys</span>]] on nb-discuss 9/23/09 and during a [http://events.ccc.de/congress/2009/wiki/Lightning_Talks 26C3 lightning talk] ([http://s3.amazonaws.com/saizai-public/free_space_file_system.pdf slides]). See that thread for more details and discussion. It was [https://www.noisebridge.net/pipermail/noisebridge-discuss/2009-September/008227.html codenamed] 'Dandelion' by Mountain Sky, because of the way it lives "between the cracks" of its host file system (FS). It is not currently implemented, just a proposal. If you feel like implementing it or have other ideas to contribute, please let Sai know (or just edit this page). == Main idea == Dandelion is a covert storage system. It lives parasitically within a host FS by treating the blocks that the host FS considers unallocated as allocatable. It allows the host FS to continue to allocate those blocks freely (except perhaps requesting a write lock during write operations to prevent race condition edit conflicts), treating such allocation as effective deletion of the block. Of course, all data stored (including the index) is encrypted, thus requiring the key not just to read files but even to detect data's presence (though note vulnerabilities below). Dandelion does NOT require: * unmounting or making read-only the host FS * allocating or reserving blocks on the disk (except perhaps temporarily for write operations) * a special volume manager * tampering with host FS files (except perhaps for a slack space index) * being present for the creation of the drive and/or partitions * leaving any space unaccounted for by a perfectly ordinary host FS Dandelion's index (if it exists) would need to live either: * in slack space (such as that provide by Rune, Waffen, KY, Data Mule, or MAFIA Slacker) * in free space (thus requiring brute force search to find on boot) * in RAM (thus completely destroying the Dandelion storage on reboot) * out-of-band (e.g. in network storage or a USB key) It may also be possible for Dandelion to not ''have'' an index. This would mean that listing all data present in free space requires brute force search, but various hash addressing schemes could make looking up some particular key still reasonably fast. If Dandelion is not actively maintained, the natural churn of the host FS reallocating "free" blocks (that Dandelion was secretly using for data) will wipe out all of Dandelion's data. This provides for an automatic dead man switch; if Dandelion's control daemon is shut off (or not started on the next boot), it will completely disappear - no cruft left on the host FS. Dandelion is ''not'' suited to reliable long-term storage. Depending on how replicated it is and how much the host FS wants to allocate, any particular datum may vanish at any time; it is similar to memcache in this regard. Dandelion has two major vulnerabilities to detection: # its control system must be stored elsewhere, and thus may be discoverable # it makes free space look suspiciously random; normal free space would contain snippets of old files and be much less random == Similar ideas == * [http://en.wikipedia.org/wiki/Rubberhose_(file_system) Rubber Hose FS] ([http://iq.org/~proff/marutukku.org/ main site]) * [http://en.wikipedia.org/wiki/Deniable_encryption#Software Deniable encryption] * [http://en.wikipedia.org/wiki/Plausible_deniability Plausible deniability] * [http://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Rubber-hose cryptanalysis] * [[M.A.I.D.|Mutually Assured Information Destruction]] * [http://www.windowsecurity.com/articles/Alternate_Data_Streams.html NTFS Alternate Data Streams] * [http://www.wikistc.org/wiki/Slack_space_data#Storing_data_in_slack_space Slack space storage] * [http://www.o3one.org/hwdocs/fat_fs/sfs3.pdf Steganographic FS] * [http://www.metasploit.com/research/projects/antiforensics/ Metasploit Slacker] ([http://synfulpacket.blogspot.com/2008/11/metasploit-anti-forensics-project-mafia.html screencaps]) * [http://www.blackhat.com/presentations/bh-federal-06/BH-Fed-06-Thompson/BH-Fed-06-Thompson-up.pdf FragFS] * [http://www.blackhat.com/presentations/bh-usa-05/bh-us-05-grugq.pdf Data Mule FS] * [http://en.wikipedia.org/wiki/Error_coding Error coding] * [http://allmydata.org/~warner/pycon-tahoe.html TAHOE] (among many other distributed storage systems)
Summary:
Please note that all contributions to Noisebridge are considered to be released under the Creative Commons Attribution-NonCommercial-ShareAlike (see
Noisebridge:Copyrights
for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource.
Do not submit copyrighted work without permission!
To protect the wiki against automated edit spam, we kindly ask you to solve the following CAPTCHA:
Cancel
Editing help
(opens in new window)
Navigation menu
Personal tools
Not logged in
Talk
Contributions
Log in
Request account
Namespaces
Page
Discussion
English
Views
Read
Edit
View history
More
Search
Dig in!
Noisebridge
- Status: MOVED
- Donate
- ABOUT
- Accessibility
- Vision
- Blog
Manual
MANUAL
Visitors
Participation
Community Standards
Channels
Operations
Events
EVENTS
Guilds
GUILDS
- Meta
- Electronics
- Fabrication
- Games
- Music
- Library
- Neuro
- Philosophy
- Funding
- Art
- Crypto
- Documentation/Wiki
Wiki
Recent Changes
Random Page
Help
Categories
(Edit)
Tools
What links here
Related changes
Special pages
Page information