How can I make a file trully immutable (non-deletable and read-only)?

Question

I need to make a file truly read only - to keep it as is. No delete, no nothing.

(Setting the 'ReadOnly' attribute isn't an option)

I see now some approaches:

1. Use a program to keep the file open. Drawback: One can kill the process an then the file closes.

2. Use a program to set the security attributes. Drawback: The file can be deleted. Also, the attributes can be changed back.

Any ideas? Also, a sample code (preferably in Delphi) would be appreciated.

UPDATE: Thanks to all answers so far. They are really great. I realize that I wasn't very clear. The problem which we want to solve is this:

There are some .txt-like files which contains sensitive information. Our clients wants to be sure that these files aren't changed 'behind the scenes' on their computers. We should mention that their PCs can be infected easily with malware specifically targeted to do this thing. Our clients should be able to open these files with Notepad, Wordpad etc. but they accept that the files are Read Only. If any of our clients take a decisive action like entering in 'Safe Mode' etc. and tampering the files from there is their responsibility. We should guard them from any malware, including a zero-day attack. (Hence a classical Antivirus solution isn't so appropriate).

Can you give now some ideas?

PS: My most sincere apologies once again for not being so clear from the beginning.

Answer 1

Caveats: This is a solution from my time as a sysadmin a couple decades ago.

This should be quite easy to do. You need to set up a OpenBSD system to store the files. Then install Samba on it to export the directory tree to your local group of Windows clients.

OpenBSD has security flags to make a file immutable. This particular operation cannot be reversed in multiuser mode. You have to reboot into single user mode to change the flag back to mutable.

There are other options too. A file can be marked append only. A directory can be marked so that you cannot delete a file in it.

OpenBSD is pretty lean out of the box. I ran it as my firewall, and DMZ machines.

Possible issues: The client machines do not have an api AFAIK that can make a mutable file immutable. A kludge for this would be to run a chron script on the OpenBSD box that marked all files in a certain directory as immutable. If this happened while the client was saving the file, it might be a problem. Need to test. If it is a problem the script has to check that the file doesn't currently have a file open lock by the samba server.

There is a possible race condition between the client machine receiving the file on their computer, and it being saved for the first time. If malware modifies the file before it's saved for the first time, then an incorrect version is saved.

When a file is first saved on the server, run a hash on it, such as SHA256 (I think it's still secure...) That hash is sent back to the original provider of the file, "File {name} has SHA256 Checksum {insert sum} on our stored copy. Please verify."

Some of this can also be done ahead of time. File provider provides a set of files, and in a separate out of band communication sends their checksums. You see this done a lot on open software. The master source of the installer or source publishes the checksum. If you pick the file up from other distribution source you can check your local copy against the master source's checksum.

In passing: I did volunteer work for a local school, who had crappy old machines that couldn't run current operating systems for the day. Kids were constantly finding malware to install. So I set it up so that I had a standard image on a FreeBSD server. Every night the entire lab was re-imaged. All user profiles were kept on a FreeBSD samba server. The downside of this is you need a separate image for each combintation of software and hardware.

Another way to do this would be to run some minimalist OS on the client, and run virtual machines that can be reset to a known state.

Answer 2

There is a way to combine the idea of using Windows ACL's and Super User, (NT_SYSTEM) access to make a file (somewhat) immutable.

1. Research via a web search on how to assume the role of NT_SYSTEM - the ultimate "root" user in Windows. There is a way to do it from the command-line where you end up with a different terminal window open where you have subsumed the identity of NT_SYSTEM.

2. Navigate to the file in question. Possible issue: I discovered that, other than things like running REGEDIT, this instance of NT_SYSTEM actually had very little capabilities, so you may not be able to do much.

3. Take ownership of the file as NT_SYSTEM and set the ACL's as you see fit.

The big problem with this, as others have mentioned, is twofold:

1. This only works within the existing filesystem as run by the existing operating system. Booting into a different O/S, possibly even by using a bootable flash drive image. (Though that can be prevented to some extent within some BIOS settings.)

2. Alternate access methods, particularly "bare metal" access at the most fundamental level can still get you.

This is true for any filesystem, Linux, Windows, Mac, IBM Mainframe, CRAY supercomputers, etc. etc. etc.

One possible mitigation strategy, again mentioned above, is to encrypt the drive, or, (even better), use a "secure vault" drive with internal hardware encryption. This is the technique used in many high-security and/or Top Secret installations where each user has a removable, hardware encrypted, hard drive which is taken directly from some kind of secure storage direct to the user's system and is immediately returned to the secure storage when done for the day. Unfortunately, even that is hackable once the drive is "unlocked".

The bottom line is that if someone REALLY AND TRUELY wants your tush, they're going to get it. If the DOD, CIA, and banks with bazillion-dollar security budgets can be hacked, so can you. The best you can hope for is to make yourself invisible so you don't become a target and minimize the attack surface if the bad guys are interested.

Answer 3

Raymond Chen from Microsoft just recently wrote an article that's closely related: The way to stop people from copying files to a folder is to use NTFS security, not to block drag/drop. While this one mentions trying to stop someone from copying a file to a specific folder you can use the same solution presented to fix your problem here.

To properly secure the file and prevent tampering you can set the ACLs on the file to have Read permissions but deny Write, Delete and Change permissions. You can set that for a specific user, group, or even everyone! The owner of the file will always have permission to change the permissions, so you can't permanently lock yourself out (even if you try to deny the CREATOR OWNER special object). Keep in mind that to manually set these from the security dialog box, you'll have to enter the advanced permissions area, they aren't available from the standard page. You may also want to break inheritance so that the file has only the permissions you set and none from its parent.

In this case it would be best to leverage options that are already there and so you won't have to try and hack the system to make work. NTFS has robust security and can accomplish what you want without you writing code. You can also work with the security directly through the WINAPI using methods related to File Security and Access Rights (MSDN). You can provide the permissions when you call the first CreateFile or change permissions after the fact by using SetNamedSecurityInfo or SetSecurityInfo.

EDIT: To address the concerns of malware, you can even deny SYSTEM access so even services running under the system account cannot delete it or write to it. I've actually taken care of one pesky virus in that method. it would keep creating a directory, so I booted PE, emptied out the directory, then denied everyone access to it including the SYSTEM account. The virus was unable to propagate while I worked on removing it.

Answer 4

Why don't you just encrypt the file and open/close it along with your executable? Or place it in your self-made filesystem?

Answer 5

A way be to sure that these files aren't changed 'behind the scenes' would be to add a signature to the file.

To sign the file you could for example: Make a string with the whole content of the file + a secret password and calculate an SHA1-Hash of the string. Then add this hash on the first or last line of the file.

To check the signature: Read the file, remove the line with the hash, add the secret password, recalculte the hash and check if it is the same as the one in the file.

To calculate SHA-1-Hashes with Delphi you can for example use MessageDigests.

Answer 6

Burn it to write-once media.

Answer 7

burn a cd.

Answer 8

Buy a PROM, and a micro controller programmer kit, and burn your file into the ROM...

Answer 9

You can't do that, for the simple reason that you shouldn't ever be allowed to anyway. As Mihal pointed out, this has the potential to wreak havoc on a computer.

Programming Ethics 101: If your program is going to run on someone else's computer, remember that it's their property, not yours. That means they have the right to modify and/or delete anything they want to. Try to treat the system like your property, and they'll treat your program like malware.

Probably the best solution, if you need to make certain that a file will be available, is Massif's idea to embed it within your program as a resource. That way, nothing short of someone tampering with the EXE will stop you from having it available, and if that does happen, you've got bigger problems to worry about anyway.

Answer 10

This is one of the "what would happen if that were true?" questions. It has nothing to do with the operating system, the points apply equally to any general purpose computer.

Imagine that there were a way to somehow create an immutable file.

• What's there to stop someone from filling up a file system with an immutable file (or many of them)?

• What if someone were to create immutable files with pathnames the operating system needs (Windows example - NTUSER.DAT for some user, *nix example - /bin/ls, etc.)?

• What if the operating system decides it must move the file (e.g., while defragmenting or otherwise reorganizing the file system)?

• What if a piece of malware replaces a system file with a copy of itself then makes that file immutable to prevent anyone from ever cleaning the system?

I feel the question is incomplete as it is now. Could you edit it to include more details about the underlying problem you're trying to solve?

Answer 11

You can use windows security acls to protect the file. However if the person has access to the hardware then they can always as massif says boot into another mode or os and delete it.

Answer 12

Why do you want this? It seams to me like an odd requirement.

I don't think you can do this. The best alikes I can think of are: Create the file as an admin and set the permissions that so that a normal user change not change it (this assumes different users) or create an application that resets the file if it changes.

Answer 13

you're doomed. Even windows can't prevent me deleting files arbitrarily if I boot into safe mode.

How about setting a watcher on the file in question and replacing it with a pristine one should it be changed? Or embedding the file in the resources of the program that needs it?