(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.
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.
If you don’t want files to be accessible by you, then have another user own them.
If you don’t want files to be accessible by root, then don’t have them at all.
This seems interesting. However, if I’m correct. What you suggest is not capable (by itself) to prevent said files to be copied through a disk clone. Am I right? Even if they’re otherwise encrypted or inaccessible, then still they will come through the disk clone. Did I understood you correctly?
It sounds like you’re actually more concerned about the data in the files not being able to ‘pop up’ elsewhere, rather than the files themselves. In thus case I’d suggest simply encrypting them, probably using
gpg. That’ll let you set a password that is distinct from the one used forsudoor similar.You should also be using full disk encryption to reduce the risk of a temporary file being exposed, or even overwritten sectors/pages being available to an attacker.
I’ve failed tremendously in making my demands come across :P .
Uhmm…, what you propose with
gpgdefinitely solves one part of the puzzle.But, if I understood correctly, it doesn’t help to prevent a disk clone from getting hold of the files.
Yes, the files are encrypted, but that’s not sufficient for my needs by itself. If the files would somehow destroy or corrupt themselves on a disk clone (or something to that effect), I would have acquired what I’m seeking.
Nothing can prevent a disk clone cloning the data, and there’s no way to make something happen when a disk is cloned as you’re not in control of the process.
If you wish to mask the existence of the files, use either full disk encryption, in which case cloning the disk doesn’t reveal the existence of the files without the decrypt password, or use a file based encrypted partition such as veracrypt in which case the cloner would just see a single encrypted blob rather than your file names.
Ultimately encrypting the files with gpg means they have already effectively ‘destroyed or corrupted’ themselves when cloned. If you don’t want to reveal the filenames, just call them something else.
If you could be a bit more specific about your threat model people may have better ideas to help.
If you could be a bit more specific about your threat model people may have better ideas to help.
Threat model is me protecting myself from myself.
Incoming XY problem.
I want to prevent myself from reinstalling my system. The trick I came up with involved the use of files that couldn’t be disk cloned. However, if it’s far far easier to accomplish it through other means, then please feel free to enlighten me on this.
Ok, I’m still not clear on exactly what you’re trying to achieve as I can’t quite see the connection between somehow preventing certain files being duplicated when cloning the disk and preventing yourself from reinstalling the system.
Bear in mind that reinstalling the system would replace all of the OS, so there’s no way to leave counter-measures there, and the disk itself can’t do anything to your data, even if it could detect a clone operation.
If what you’re trying to protect against is someone who knows everything you do accessing your data, you could look to use TPM to store the encryption key for your FDE. That way you don’t know the password, it’s stored encrypted with a secret key that is, in turn, stored and protected by your CPU. That way a disk clone couldn’t be used on any hardware except your specific machine.
Ok, I’m still not clear on exactly what you’re trying to achieve as I can’t quite see the connection between somehow preventing certain files being duplicated when cloning the disk and preventing yourself from reinstalling the system.
Premises:
- Very important files on disk (somehow) protected from copy/mv/clone whatever.
- Reinstalling my OS wipes the disk.
Therefore, I would lose those very important files if I were to attempt a wipe. If said files are important enough for me to reconsider wiping, then the act of protecting them from copy/mv/clone has fulfilled its job of preventing me from reinstalling the OS.
Bear in mind that reinstalling the system would replace all of the OS, so there’s no way to leave counter-measures there, and the disk itself can’t do anything to your data, even if it could detect a clone operation.
I understand.
If what you’re trying to protect against is someone who knows everything you do accessing your data, you could look to use TPM to store the encryption key for your FDE. That way you don’t know the password, it’s stored encrypted with a secret key that is, in turn, stored and protected by your CPU. That way a disk clone couldn’t be used on any hardware except your specific machine.
Very interesting. A couple of questions:
- Is it possible to only protect a set of files through this? So not the entire disk?
- Does TPM get flushed/randomized on OS reinstall?
This seems like a very complicated way to achieve your goal! It sounds like sitting yourself down and giving you a stern talking to might be a beter aporoach.
Having said that, if you have these very important files that you don’t want to lose, please make sure they’re backed up somewhere off of your machine. Storage fails, and it’s a horrible feeling losing something important. Unfortunately doing so would defeat the approach you’re thinking of.
This might be a case of needing to reframe the question to get to the cause of the issue, and then solve that. So, why do you want to make it hard to reinstall your machine? Is it the amount of time you spend on it, the chance of screwing it up, needing it working, has it become a compulsion or something else? Maybe if we can get to the root of the issue we can find a solution.
With regard to TPM, it’s basically just a key store, so you can use it fir anything really, althought it’s normally used by generating a TPM key and using it to encrypt the key that’s actually used to encrypt your data, storing the encrypted key with the OS. Just reinstalling won’t wipe the TPM, but unless you made an effort to save the encrypted key it’ll be gone. Given your problem statement above it just adds to the data you’d need to save, which isn’t helpful.
Looks like a USB stick.
What’s your end goal here? You try to keep files just on that one media without any options to make copies of them? Or maintain an image which has enforced files at their directories? And against what kind of scenarios?
ACLs and SELinux aren’t useful as they can be simply bypassed by using another installation and overriding those as root, same thing with copying. Only thing I can think of, up to a degree, is to use immutable media, like CD-R, where it’s physically impossible to move files once they’re in place and even that doesn’t prevent copying anything.
What’s your end goal here?
Incoming XY problem.
I want to prevent myself from reinstalling my system. The trick I came up with involved the use of files that couldn’t be disk cloned. However, if it’s far far easier to accomplish it through other means, then please feel free to enlighten me on this.
You try to keep files just on that one media without any options to make copies of them?
Yes.
Or maintain an image which has enforced files at their directories?
No, not necessarily.
And against what kind of scenarios?
Protecting myself from myself. That’s where the password requirement comes in: I can send a delayed message to myself that holds the password. The end result shouldn’t in the absolute sense prevent full access for always. Unlocking the protection should be possible and should require the involvement of the earlier mentioned password that is received through a delayed message. That way, those files can be accessed eventually, but only after I had intended to.
ACLs and SELinux aren’t useful as they can be simply bypassed by using another installation and overriding those as root
Excellent! I didn’t know this. Thank you for clarifying this for me!
Only thing I can think of, up to a degree, is to use immutable media, like CD-R, where it’s physically impossible to move files once they’re in place and even that doesn’t prevent copying anything.
The files should remain on the same disk that I run my OS from. So, unfortunately, this doesn’t quite help me. Thank you regardless!
I want to prevent myself from reinstalling my system.
Any even remotely normal file on disk doesn’t stop that, regardless of encryption, privileges, attributes or anything your running OS could do to the drive. If you erase partition table it’ll lose your ‘safety’ file too without any questions asked as on that point the installer doesn’t care (nor see/manage) on individual files on the medium. And this is exactly what ‘use this drive automatically for installation’ -option does on pretty much all of the installers I’ve seen.
Protecting myself from myself.
That’s what backups are for. If you want to block any random usb-stick installer from running you could set up a boot options on bios to exclude those and set up a bios password, but that only limits on if you can ‘accidently’ reinstall system from external media.
And neither of those has anything to do on read/copy protection for the files. If they contain sensitive enough data they should be encrypted (and backed up), but that’s a whole another problem than protecting the drive from accidental wipe. Any software based limitation concerning your files falls apart immediately (excluding reading the data if it’s encrypted) when you boot another system from external media or other hard drive as whatever solution you’re using to protect them is no longer running.
Unless you give up the system management to someone else (root passwords, bios password and settings…) who can keep you from shooting yourself on the foot, there’s nothing that could get you what you want. Maybe some cloud-based filesystem from Amazon with immutable copies could achieve that, but it’s not really practical on any level, financial very much included. And even with that (if it’s even possible in the first place, I’m not sure) if you’re the one holding all the keys and passwords, the whole system is on your mercy anyways.
So the real solution is to back up your files, verify regularly that backups work and learn not to break your things.
“undoing the protection should include filling in a password” That sounds like an encrypted drive. There are USB keys that’ll require software to enter an encryption password before you can do anything (including deleting the contents).
If you’re on Windows, try Bitlocker or Veracrypt. You can create hard disk images that can be mounted temporarily with a password.
Same can also be done on other operating systems, though I don’t know what tools yours come with.
In a pinch, you can just create a password protected 7zip archive, though viewing and editing those files usually involves a temporary copy.
There’s no way to prevent a file that’s loaded in memory from making it back to the disk. The best you can do is also encrypt the system drive so only people who know the encryption password can boot the computer that’s accessing these files.
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.
Then, what prevents whosoever, to copy that file through cloning the complete disk?
Nothing. At most, you can have a hardware encrypted drive that won’t permit access to the encrypted data without a password, but the file will remain available after unlocking that. Plus, dedicated people (law enforcement, data recovery specialists) may be able to get access to the flash chip itself unless you buy one that self destruct on any tampering attempts (and even those have flaws).
You cannot prevent copying of data if that data is readable at disk level. At most, you can make the data useless by padding a layer of encryption (as well-encrypted data may as well be random data without the key material). That’s why everyone is going for encryption: encrypted files may as well be inaccessible to anyone who doesn’t know the passphrase. There’s no sense in copying a file which you cannot possibly read any bytes from.
If the key is gone (i.e. the real key is a password protected file that gets overwritten so even the password doesn’t work anymore), the file becomes irretrievable. This is sometimes called “cryptographic erase” in the context of disks. There are variations of this, for instance, storing the key in the computer’s processor (fTPM) behind a password, and clearing that key out. There’s no way to get the key out of the fTPM so it cannot be backed up. Even if someone were to guess your password, the file will forever remain locked. Or at least until someone manages to break all cryptography, but even quantum computers don’t know how to do that part yet.
If you’re willing to go deep, you could reprogram the firmware on your SSD/HDD to refuse reading the file. A few years back, someone made a proof of concept firmware that detected disk imaging attempts (because all blocks on the disk were read in order) and had the firmware return garbage while secretly wiping the disk when this detection triggered. You could, in theory, write firmware that refuses to read that block of data. However, if whoever you’re hiding this file from know about that, they can take out the platter/memory chips and dump them directly, bypassing your firmware entirely.
Very informative. I appreciate it!
By definition, you can’t. Any software level solution will fail since you can just move the drive somewhere else. It must be baked into the hardware and firmware.
Edit to add further clarification. Do you need it to be failing on every device or just on a device that you control? Since as stated before, moving a mass storage will completely overthrow any software solution
Do you need it to be failing on every device or just on a device that you control?
Actually, I’m fine with a solution that only works on a device that I control. But, failing on every device is nice as well.
Right, working on every device requires a hardware solution. I haven’t encountered any such hardware yet but I do know that it is possible. Next, your second requirement makes what you’re trying to accomplish impossible. Privilege escalation by definition will escalate the privilege. The problem lies in the fact that the root user is basically a god in linux. You can even wipe your system if you so desire. However, you can read more into SELinux or other similar systems. It works by basically running check on the kernel level not user level. But the only solutions I can think of will make other day-to-day tasks more of a hassle. Also, note that whoever knows how to modify the SELinux can also bypass the system. I found an answer on serverfault that points to a blog. However, I haven’t read the blog yet. You may find an answer there.
Thank you!
You’re welcome. I also recommends Arch Wiki on SELinux. It helps clarify a lot of things and how different it is with traditional linux privilege escalation.
Will do.
I ask for some method that prevents the file to even be copied through a disk clone
Oh that’s quite simple! Just don’t have the files on the first disk in the first place. Make them a remote mount from a server, for example via sshfs, webdav, etc. Heck, even ftp if it comes down to it. That way, even though you can clone the disks, you can not get to the files if you don’t also have the full authentication requirements for the remote server (such as a password).
At a conceptual level, you can’t do anything via
rootto prevent someone who clones the disk from… well, cloning the disk. Having physical access to a disk is a much higher level of access than even root, so if what you are looking for is for your content to not be cloned, you need to fortify physical access to the device.Understood. Thank you!
- I had a folder called
What are you trying to do? Why don’t you just use full disk encryption?
I already use FDE. However, unless I’m wrong, FDE does not protect disk clone from occurring. Therefore, if one has access to the password, then also they have access to all my files; including the ones I specifically want to protect. Am I wrong?
So, I’ll make it simple for ya, you don’t need to understand why; however, I seek for some method that prevents files from being copied through disk cloning. Them files being encrypted or whatsoever doesn’t do a thing if the password is known. Unless you propose a method by which the password used to decrypt/unlock the disk on device X doesn’t work when it’s cloned to another disk. If, somehow, one has to rely on another password to decrypt the disk on device Y, then that might make it work out.
I don’t think that’s possible without an OS. For encryption you need a strong passphrase.
Alright. Thank you for your input!
I guess you can use ACLs depending on your filesystem, or SELinux user contexts.
Seems interesting. Got any sources to read up on? Thanks in advance!
You can read about SELinux here or ACLs here. SELinux can be pretty complex if you’ve never used it, so make sure you understand it well. I believe it should be able to do what you want to achieve.
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!
It sounds like you want these files to be encrypted.
Someone already suggested encrypting them with GPG, but maybe you want the files themselves to also be isolated, even while their data is encrypted. In that case, consider an encrypted volume. I assume you’re familiar with LUKS - you can encrypt a partition with a different password and disable auto-mount pretty easily. But if you’d rather use a file-based volume, then check out VeraCrypt - it’s a FOSS-ish [1], cross-platform tool that provides this capability. The official documentation is very Windows-focused - the ArchLinux wiki article is a pretty useful Linux focused alternative.
Normal operation is that you use a file to store the volume, which can be “dynamic” with a max size or can be statically sized (you can also directly encrypt a disk partition, but you could do that with LUKS, too). Then, before you can access the files - read or write - you have to enter the password, supply the encryption key, etc., in order to unlock it.
Someone without the password but with permission to modify the file will be capable of corrupting it (which would prevent you from accessing every protected file), but unless they somehow got access to the password they wouldn’t be able to view or modify the protected files.
The big advantage over LUKS is ease of creating/mounting file-based volumes and portability. If you’re concerned about another user deleting your encrypted volume, then you can easily back it up without decrypting it. You can easily load and access it on other systems, too - there are official, stable apps on Windows and Mac, though you’ll need admin access to run them. On Android and iOS options are a bit more slim - EDS on Android and Disk Decipher on iOS. If you’re copying a volume to a Linux system without VeraCrypt installed, you’ll likely still be able to mount it, as dm-crypt has support for VeraCrypt volumes.
- 1 - It’s based on TrueCrypt, which has some less free restrictions, e.g.,
c. Phrase "Based on TrueCrypt, freely available at http://www.truecrypt.org/" must be displayed by Your Product (if technically feasible) and contained in its documentation.”
Someone without the password but with permission to modify the file will be capable of corrupting it (which would prevent you from accessing every protected file), but unless they somehow got access to the password they wouldn’t be able to view or modify the protected files.
Is it possible to force a corruption if a disk clone is attempted?
Is it possible to force a corruption if a disk clone is attempted?
Anything that corrupts a single file would work. You could certainly change your own disk cloning binaries to include such functionality, but if someone were accessing your data directly via their own OS, that wouldn’t be effective. I don’t know of a way to circumvent that last part other than ensuring that the data isn’t left on disk when you’re done. For example, you could use a ramdisk instead of non-volatile storage. You could delete or intentionally corrupt the volume when you unmount it. You could split the file, storing half on your USB flash drive and keeping the other half on your PC. You could XOR the file with contents of another file (e.g., one on your USB flash drive instead of on your PC) and then XOR it again when you need to access it.
What sort of attack are you trying to protect from here?
If the goal is plausible deniability, then it’s worth noting that VeraCrypt volumes aren’t identifiable as distinct from random data. So if you have a valid reason for having a big block of random data on disk, you could say that’s what the file was. Random files are useful because they are not compressible. For example, you could be using those files to test: network/storage media performance or compression/hash/backup&restore/encrypt&decrypt functions. You could be using them to have a repeatable set of random values to use in a program (like using a seed, but without necessarily being limited to using a PRNG to generate the sequence).
If that’s not sufficient, you should look into hidden volumes. The idea is that you take a regular encrypted volume, whose free space, on disk, looks just like random data, you store your hidden volume within the free space. The hidden volume gets its own password. Then, you can mount the volume using the first password and get visibility into a “decoy” set of files or use the second password to view your “hidden” files. Note that when mounting it to view the decoy files, any write operations will have a chance of corrupting the hidden files. However, you can supply both passwords to mount it in a protected mode, allowing you to change the decoy files and avoid corrupting the hidden ones.
Very informative post. Thank you!
- 1 - It’s based on TrueCrypt, which has some less free restrictions, e.g.,
What do you mean by a file being displaced? Like do you want it to be unreadable, or unmodified, or just not deleted?
It’s not really possible to have a level of protection that would require more than
sudobecause with root access you bypass anything else.You could put the files on an encrypted volume that uses a special password when it is mounted. Or you could use the
chattrcommand to set special ext4 attributes that would make it unmodifiable (but could be removed with sudo). Or just record the file’s hash, and that way you know it hasn’t been modified later.Like do you want it to be unreadable, or unmodified, or just not deleted?
I don’t necessariy care for any of those. They are ‘bonuses’ if you will. Though…:
- Unreadable will be required for preventing recreating the file elsewhere.
- Unmodifiable is not necessarily required. Maybe I would like to ‘append’ something to an existing file. But I’m fine either way. It should not be possible to delete some of the original data though.
- Not deleted is a must as well.
I’m not sure I’m fully understanding. Are you wanting files which can be read but never copied?
Scratch that, i missed a line. So simply files stored but not user readable.
Scratch that, i missed a line. So simply files stored but not user readable.
But also not being able to be copied; even through a disk clone.
If you have these types of issues, just move to an immutable distro.
Who says I’m not already :P . Got any ideas on how this might be able to specifically solve the problem at hand?
What you describe in your post is a user who is not confident enough to manage their own machine with the CLI, and is afraid of misplacing files.
What you seem to not understand is that if you made the mv and cp commands require some sort of user interaction, nothing would ever work on the system, at least not in userspace if that’s the intent. No installer scripts, package managers, apps which use such commands…etc. Imagine implementing a rule like you describe, and then trying to copy/paste something in a GUI file manager, or organize music or photos.
So if you’re so afraid of moving something that needs not be moved, put some simple rules in place for yourself:
- Don’t fuck around with anything outside of your homedir
- Learn to reinstall system packages
Pretty simple. You also probably want to be on ZFS or BTRFS so you can undo your mistakes if you make them.
Isn’t literally ANY option here simpler than what you’re describing?
Thank you for your input! It has made me recognize that I should specify that I don’t want this to be system-wide; which was not clear from the post.
What you’re describe in your post is a user who is not confident enough to manage their own machine with the CLI, and is afraid of misplacing files.
I understand why I might have given off that impression. But no worries; I’m a (relatively) seasoned Linux user. I also have no qualms with CLI or whatsoever. It’s a specific set of files that I wish to ‘protect’.
You’re aware of file permissions, right?
So if you’re concerned about a specific set of files that you don’t want moved, AND they’re in a normal userspace location…
The thing with file permissions is that I or root are able to change that. I am looking for a method (if it exists) that somehow bypasses that.
Yeah, but you’d need to sudo in order to affect the files. So that’s a simpler way of doing what you’re suggesting.
I’ll straight up pose the question I asked someone else:
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.
- I had a folder called
