Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • T tails
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 968
    • Issues 968
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 32
    • Merge requests 32
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • tails
  • tails
  • Issues
  • #5687
Closed
Open
Issue created Jul 18, 2013 by import-from-Redmine@import-from-Redmine

erase memory when the USB stick is removed

Originally created by Tails on #5687 (Redmine)

Rationale

If running from the USB drive and it is removed, it would be nice to wipe memory and reboot when the USB drive is removed: if you’re in a persecuted country and they are on to you, you can grab the USB and leave.

Current state

Implemented in 0.7.

  • design documentation: done in memory erasure
  • end-user documentation: done in cold boot attacks

Inspiration

A simple udev rule should do the job. It should be triggered by ACTION=="remove", and be really careful to detect whether the system is running from the just-removed USB stick.

The implementation difficulty arises from the fact that smem must be permanently kept in RAM after boot, along with what’s needed to make the command run by the udev rule work. Possible solution: run smem on boot, immediately SIGSTOP it, and SIGCONT it when the USB stick is unplugged.

Liberte Linux has some kind of watchdog that does something alike these lines (i.e. at least shutdown the box):

  • they pre-cache needed programs in a directory in /dev/shm
  • they have a udev watchdog written in C, which is supposed to be more reliable than udev rules.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking