(More) Specifics:
- Undoing the protection should include filling in a password.
- The password should be different from the one used with
sudoor any other passwords that are used for acquiring elevated privileges.
All (possible) solutions and suggestions are welcome! Thanks in advance!
Edit: Perhaps additional specifications:
- With 'displace‘, I mean anything involving that resembles the result of
mv,cp(move, cut, copy) or whatsoever. The files should remain in their previously assigned locations/places and should not be able to ‘pop up’ anywhere. - I require for the files to be unreadable.
- I don’t care if it’s modifiable or not.
- I don’t require this for my whole system! Only for a specific set of files.
What do you mean with “displace”?
‘Move’; this includes copying, cutting or what have you. It should remain in the assigned directory/location. I’ll include this remark. Thank you!
deleted by creator
It seems I wasn’t clear as most people misunderstood me.
But, to give a very precise example; say
- I had a folder called
~/some/folder. - It was on an encrypted drive.
- And I had done additional work to encrypt the folder again.
- And say, I used
chattr,chmodorchownor similar utilities that remove access as long as one doesn’t have elevated privileges. - And say, I had done whatever (additional thing) mentioned in your comment.
Then, what prevents whosoever, to copy that file through cloning the complete disk?
Even if they’re not able to get past the password, it will be found on the cloned disk. SO, basically, I ask for some method that prevents the file to even be copied through a disk clone. I don’t care that it has three passwords protecting it. What I want is for the disk clone (or whatever sophisticated copy/mv/cut or whatsoever utility exists) to somehow fail while trying to attempt the action on the protected files.
deleted by creator
Very informative. I appreciate it!
- I had a folder called
Just make the file root owned and readable by no one. An unreadable file can’t be copied. You can use
chattrto add some flags like immutability if you desire (shouldn’t really need to). Use a command likefind /some/path -type f -exec chattr whatever {} \;if you need to do this recursively. Root account should need a password, and should (hopefully) not be accessable with an unprivileged user’s password throughsudo/doas, but on its own account with it’s own password usingsuorlogin.Note that without encrypting the file, this does not protect you from someone just grabbing your storage device and mounting it with root permissions and then they can do whatever they want with your data. It also doesn’t protect you if someone gets root access to your device through other remote means. If you want to encrypt the file, use something like
openssl some-cipher -k 'your password' -in file -out file.cipher_ext. If you want to encrypt multiple files, put them in atarball and encrypt the tarball. You can again also usefindwithopensslto encrypt/decrypt recursively if you don’t want to use a tarball, which may be better with ciphers like blowfish that aren’t secure at large file sizes; but if you do that, you expose your encrypted file system structure to attackers.I am not a fan of full disk encryption, because it usually means leaving all your data decrypted during runtime with how most people use it. If you only decrypt a block device when you need to, there’s nothing wrong with that, and can work as an alternative to encrypting a tarball.
Definitely one of the better answers I’ve received so far. Thank you for that. However, I feel as if the following part reveals that it’s not as ‘protected’ as I’d like:
It also doesn’t protect you if someone gets root access to your device through other remote means.
Though, at this point, I’ve somewhat accepted that I’m seeking a software solution for a hardware problem. Hence, the impossibility of my query… I hope I’m wrong and perhaps you can point me towards the solution I’m seeking. However, if that’s not the case, then I would like you to know that I appreciate your comment. Thank you.
