How do I configure my system to destroy all personal data when a certain password is entered? The motivation behind this being NSA stuff.
I imagine there being three primary usage cases.
- At login, the entering of a predetermined password triggers destruction of user data.
- At system wake up. entering of a predetermined password triggers destruction of personal data.
- Entering any privileged command with a predetermined password triggers destruction of personal data.
I know that something like
dd if=/dev/urandom of=/dev/$HOME
Should be adequate for data destruction. I don’t know how to have that triggered by a certain password, however.
Bonus points if it then permits a login while the data is being deleted.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
Idea #1 – Hidden OS
As an alternative method you could make use of TrueCrypt’s “Hidden Operating System”. This allows you to access a fake alternative OS when a certain password is used, rather than the primary OS.
excerpt
If your system partition or system drive is encrypted using TrueCrypt, you need to enter your pre-boot authentication password in the TrueCrypt Boot Loader screen after you turn on or restart your computer. It may happen that you are forced by somebody to decrypt the operating system or to reveal the pre-boot authentication password. There are many situations where you cannot refuse to do so (for example, due to extortion). TrueCrypt allows you to create a hidden operating system whose existence should be impossible to prove (provided that certain guidelines are followed — see below). Thus, you will not have to decrypt or reveal the password for the hidden operating system.
Bruce Schneier covers the efficacy of using these (Deniable File Systems, so you might want to investigate it further before diving in.
The whole idea of Deniable Encryption is a bit of a can of worms, so caution around using it in certain situations needs to be well thought out ahead of time.
Idea #2 – Add a script to /etc/passwd
You can insert alternative scripts to a user’s entry in the /etc/passwd file.
Example
# /etc/passwd tla:TcHypr3FOlhAg:237:20:Ted L. Abel:/u/tla:/usr/local/etc/sdshell
You could setup a user’s account so that it runs a script such as /usr/local/etc/sdshell which will check to see what password was provided. If it’s the magical password that triggers the wipe, it could begin this process (backgrounded even) and either drop to a shell or do something else.
If the password provided is not this magical password, then continue on running a normal shell, /bin/bash, for example.
Source: 19.6.1 Integrating One-Time Passwords with Unix
Method 2
My approach for this would be to trigger the self destruct in a pam module. There are mechanisms to catch the password with a script, check if it’s the “special” one and start the self destruct process.
Write a line in your /etc/pam.d/common-auth as first line like this:
auth optional pam_exec.so debug expose_authtok /etc/security/suicide.sh
(or for example in /etc/pam.d/gdm if you just want it to work with authentication via gdm)
expose_authtok causes the pam_exec.so module to deliver the password via stdin to the login script called /etc/security/suicide.sh. This script would be run with root priviledges and would for example look like this:
#!/bin/bash # read the users password from stdin (pam_exec.so gives the provided password # if invoked with expose_authtok) read password # if its an authentication and it's the user "user" and the special password if [ "$PAM_TYPE" == "auth" ] && [ "$PAM_USER" == "user" ] && [ "$password" == "magic" ]; then # do whatever you want in the background and the authentication could continue # normally as though nothing had happened exit 0 else exit 0 fi
It would work even if you change the password of the “normal” user.
Method 3
Just so you know if anyone from the gov etc does grab your computer the first thing they will do is copy the drive bit for bit and work off the copy. Same thing is done anytime someone does computer forensics so if you damage while analyzing a drive you only damage the copy.
So lets say the big bad NSA takes your computer and puts your thumbs in a vice to get you to tell them the password. When you give them the wrong password then it will just del to copy and not the original. Now they know your messing with them.
So any use of a kill pass word would only be effective if you ran it before anyone got a hold of your system. So all it would do is give you a complicated way of executing something you could alias.
Method 4
If you really want to destroy your data. You first have to make sure that no one makes a copy of your data (i.e. the whole disk) in the beginning. But this is not possible on OS level.
The only way to make sure your data will not fall into wrong hands is use cryptography. Especially Deniable encryption would be the right thing in your case: If you type the correct password, your personal data shows up. If you type the other password some innocuous data shows up.
Method 5
If you really want to be able to destroy your data, to protect it from the NSA, you need something with explosives, and fire that will melt the metal in the disk platters, and you need to be able to trigger it remotely.
I suspect this is not practical.
Method 6
Well, you could have a script to trash your primary user’s /home directory (as well as /var , /tmp and everyplace else you have eyes-only data) if you log in with a different username… the script would start at login and then automagically load something which deceives the onlooker by doing something putatively useful. If it trashes your system without deceiving the onlooker, they just might pull the plug and thereby prevent your best laid plan from working. That also allows you a login while this is underway… although I would put the TRASHME user on a different drive for the drive being trashed will be rather busy and therefore pokey.
Method 7
A secure hard drive, or flash drive for that matter, is an oxymoron. The only way to secure your information is to use a virtual operating system that runs in memory and evaporates when you turn the power off, with any data that needs to be saved on external media that you can hide if you desire. There are a number of “Live” Linux distributions out there that enable you to do just that. With relatively little effort, you can remaster the CD or DVD and customize it to best suit your needs. Also, be aware that much of your behavioral information is being relayed by your browser, and for any searches that you believe are compromising, you should be using a secure browser such as Tor.
Method 8
If you want to keep things secure, understand that there is no such thing as perfect security and that security is no more than a trade off of acceptibles after accurate risk assessment has taken place.
For a start, why destroy anything. First look at decreasing ease of access. Create an air-gap. Buy a bcheaap box for on-line stuff and anything you want to send from your main box transport there by way of sneakernet. Use good encryption, like Scrypt. Truecrypt and others have had their venerable day.
There are many other strategies you can employ, with not enough space to go into them here, and frankly I don’t have enough time to go into them. I think you have discovered a whole new learning path.
Method 9
As was pointed out to me, and featured on Phoronix, Kali Linux created a method of doing this as well. Looking at some of the code, there is a weakness that will still allow the patch to be defeated, but it goes a long long way to allowing an effective self destruct password. As a note, the weakness is a hardware particularity related to zeroing out data — manufacturer tools can recover zeroed data, and overwriting key locations on a media should be done with a random number generator several times to ensure data scrambling.
Link here: http://www.kali.org/how-to/emergency-self-destruction-luks-kali/
Method 10
Yes, you have to destroy the surface of the drive. A thermite grenade is recommended (that is what they taught us) You can make your own with a fire starter (magnesium block) and an ignition source… the goal is to create a class D fire…. impossible to put out.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0