0

So, here is the deal:

I have a file I cannot change. I cannot, but I know in the future I will want to change it. It's of my understanding that it's not possible to make this file unchangeable while being root. But I want to make it so that the only way to change it is by building my whole OS from ground up.

So, here is my ideas so far:

Use entr to make a script that verifies if the file has changed and does something very harmful if so: like rm -rf /bin /sbin /usr /boot /etc... you get the idea (only mantaining /home). But in order for this to work, this script must be running on a infinte loop since boot and I must not be able to stop it or to prevent it from starting in the first place.

So, to achieve this, I can only think of: obuscation. Maybe create the script, naming it and placing it in such a way that I would not be able to easily guess which one of the running processes is it without risking kernel panic or something similar, nor could I tweak my HD with a live boot USB searching for which file to delete.

Is this possible to implement? Would this work? If not, how could I achieve my goal?

chedieck
  • 74
  • 2
  • 1
    Possibly over pedantic, but by "_I have a file I **cannot** change_", presumably you mean "_I have a file I **must not** change_"... the problem is that you **can** change it, and you're looking for ways of preventing or discouraging future changes? – TripeHound Sep 01 '20 at 11:48
  • @TripeHound yes, that's correct. I should have phrased it better. – chedieck Sep 01 '20 at 14:07
  • If, like you said in reply to Ángel, it's a system file you want to protect, then presumably it can't be arbitrarily renamed and hidden, so it couldn't it always be changed directly with a live boot? – Silver Sep 01 '20 at 20:10
  • Is the goal to make it impossible to change the file, or just impossible to do so without detection? And should it also be impossible to delete? If so, you should worry about future you just smashing the drive with a hammer. – Anders Sep 02 '20 at 11:24

3 Answers3

1

If you set up a system to block you, you would ultimately also be able to bypass it.

The best way would be for you to place it outside of your reach. An option would be to burn a CD/DVD-R, so that you cannot physically change it. I don't know if whatever will make you want to change it could also make you want to destroy it. You could provide the disk with the never-to-be-changed file to a third party, such as a lawyer. You could also publish the file on the internet, in such a way that it would be very hard for it to disappear. You could share it on keybase, IPFS, a Dropbox account you purposefully lose the password to, get it uploaded to archive.org...

You can also use a similar approach to restrict you from modifying it, such as tweeting today the full hash of the file, so you couldn't change it into the future without revealing that it is not the original file.

Note that you could publish an encrypted version encrypted, so it doesn't show its contents to the world.

Finally, if you really know so well that in the future you will want to change it, I wonder if it's really a good idea that you make your future self unable to do that.

Ángel
  • 17,578
  • 3
  • 25
  • 60
  • sorry for not making it clear, but it's a system file. It's a personal file in my computer that cannot be changed. – chedieck Sep 01 '20 at 01:47
  • i assumed it was a personal file. But it seems like assuming you will be dumber in the future... – Ángel Sep 02 '20 at 02:40
  • Which is it, a system file or a personal file? "...it's a system file. It's a personal file..." is a tad confusing. – mikem Sep 02 '20 at 17:09
1

Yes, you could do this, but only if I interpret your request literally.

A Linux system gives full and unrestricted power to the root user. In fact, if UID == 0, most security checks are simply bypassed entirely. There is nothing root can't do and that's by design. So any locks you put on anything, you can also remove.

So how to do it?

The first answer is that you could manipulate the kernel. In whatever fancy or simple way you want, the kernel source code is available, and you could, theoretically, add code to it that creates locks that cannot be unlocked, even by root. It could be a special file by name or inode, or a special UID, anything you can fancy. To get at your data, you would have to build and install a new kernel. If that is a sufficiently high hurdle for you, I would consider it "I want to make it so that the only way to change it is by building my whole OS from ground up".

The second answer is that someone already did that for you. Turn on SELinux, define a policy that secures the file or folder you want to protect, say by giving nobody write permissions, then lock that policy by removing all permissions to change the policy, then turn on enforcing mode and likewise lock it in. Congratulations, you have locked yourself into your system. No SELinux permissions can ever be changed again. You will have to reinstall a different kernel, and if you've taken those permissions away as well, you have to do it from outside the system.

(I don't recommend doing this. I've been part of SELinux development in the early days, and I can't count how many times I had to reboot because I locked myself out of my system - and that system booted into permissive mode. If you make a small but significant mistake in your policy, you can go and reinstall.)

Now that is the literal interpretation. If you are looking for a time-based solution, such as "I want to lock this data away for at least 5 years" then you are looking at things like https://crypto.stackexchange.com/questions/3064/is-it-possible-to-make-time-locked-encrytion-algorithm or https://stackoverflow.com/questions/11416803/time-based-encryption-algorithm -- which, to cut right to it, all require a third party in some form, but don't necessarily require you to store your data externally.

Tom
  • 10,124
  • 18
  • 51
0

We need more information on the use-case. Like, are you simply trying to protect yourself from accidental changes to the file or from external malicious changes to the file?

If you really want to limit yourself -- as root or not, make the directory holding the file it's own filesystem and then mount it read-only. Even root can't modify a file on a read-only filesystem.

For example, let's say the file is in /data/sensitive-files/myprivatefile You'd create /data/sensitive-files as a filesystem. Mount the filesystem read-write and create the myprivatefile. Then unmount and remount /data/sensitive-files with read-only permissions (ie. mount -o ro)

When setting the filesystem in /etc/fstab, be sure to mark it as "ro" there as well.

This would definitely protect you from unintentional changes, but keep in mind, the root user has ultimate power and could intentionally re-mount the filesystem rw to change the file.

Otherwise, I'd say stop logging in as root. Day-to-day you should be using a non-root user and only becoming root when needed.

To further protect yourself, you could limit the most common root administrative functions (ie. yum, mkfs, etc) to sudo rules and never actually login as root. Then, when that rare day comes where you need to change the file, login as the true root user to make the change.

mikem
  • 248
  • 1
  • 6