I would prefer that no one, even me, could encrypt my files. I have no use for it, and don't want it.
Is there a way to permanently disable any sort of encryption at the OS level?
If not, is this a possible improvement that a future file system could incorporate? Or is it fundamentally impossible to prevent?
Read-only file systems can by definition not be written to (At least not digitally. What you do with a hole puncher and a neodymium magnet is your own business). Examples:
Versioning file systems would be more practical, but are not common. Such systems might easily include options to transparently write each version of a file (or its difference from the previous version) to a WORM device or otherwise protected storage.
Both of these solve the underlying issue: Not losing the original data in case of encryption by malicious software.
No, that's impossible, unless you change the definition of a file.
A file is arbitrary data. Arbitrary data can be encrypted data.
Even if we only allow structured data, structured data can - if we assume no space constraints - be abused to store all arbitrary data* (citation needed). Which brings us to the starting point.
You can have partial success, if we introduce restrictions. An example would be if you don't want files to be encrypted after writing them, you can use a write once (or even write only) system. Or if you want to fight ransomware attacks, you could have a filesystem that preserves original copies of modified files for a certain amount of time.
*For example a restrictive text format that only allows the words "Fizz" and "Buzz" can represent all binary data by replacing 0 with "Fizz" and 1 with "Buzz".
Loads of file systems don't have native file system level encryption support. Software-encrypted files can be stored on any file system though, just like any other file. The file system cannot tell the difference between random data and encrypted data.
Is there a way to permanently disable any sort of encryption at the OS level?
Not so long as code can run and write files to disk.
Or is it fundamentally impossible to prevent?
Without sacrificing basic functionality, yes.
You've tagged your question ransomware though. What you may be looking for is information on application sandboxing or heuristic-based ransomware detection.
There seems to be a misconception between encryption and file systems.
The two are independent, one can do encryption without having a file system, and one can have a file system without doing encryption.
For instance, traditional FAT16/FAT32 file systems do not "support" native encryption like NTFS does with it's EFS sub component. That doesn't mean however, one couldn't change data that is already committed, nor write data to the file system that is encrypted.
It is entirely possible to have a "write only" file system, or "read only" drive, but this still doesn't prevent someone copying the data, encrypting it, and then keeping it elsewhere. You can certainly prevent the deletion and write-over of data already on disk (files in Windows can be locked by an active process).
A file system is basically a service provider for the operating system (e.g. it provides a way to permanently store and retrieve data on underlying storage media), and the operating system offers this service to any program running on the computer.
It's not in a file system's basic job description to take care of encryption, and while there are some file systems that offer native encryption, it's usually other layers that take care of it.
Ransomware doesn't care about any of that, though. Even if you have a file system that doesn't do native encryption, and even if you've removed any additional software that provides an encryption layer (such as Truecrypt, Veracrypt etc), the ransomware code itself will use the interface the OS provides to access the files on the filesystem and encrypt them. There's nothing that will reliably protect you from that except diligent backing up of your data, so that you can recover if necessary.
Ideally, encrypted data should be indistinguishable from random data. This isn't a matter of "hiding" whether or not encrypted data is present (that's steganography; more on this later) but a matter of ensuring that an attacker can't find patterns in the data which could, in turn, be used to figure out the key to decrypt it.
This causes problem for your desired system, because random data could, in theory, contain any sequence of bits. It's not necessarily likely that a random string of bits would turn out to be, say, a random JPEG, but it has happened. Combine this with steganography, where data is hidden inside other data (often used to hide encrypted data inside other unencrypted data), and the situation looks more grim for your scenario.
Because of this, there isn't really a way to tell whether a given piece of data is encrypted or not, or contains another piece of data that might be encrypted. The closest you could get to a filesystem that absolutely cannot contain encrypted data is one that cannot contain any data at all, and there are very few uses for a filesystem like that.
Like others have said, you can't prevent encryption at the filesystem level, but the closest alternative that I've not already seen mentioned is Mandatory Access Control.
Basically, you can set extra permissions up so your applications that have access to the Internet have extremely limited access to your disk. Your web browser, for example, could be set up to only be able to write to its settings, cache, and a downloads directory. Any attempt by that process to write outside those folders would be denied by the operating system.
So what happens if a vulnerability is exploited is instead of your entire disk getting encrypted, only your downloads directory can be encrypted. Of course not 100% safe (nothing is), but it's another layer that attackers don't usually expect.
The downside is it's tricky to set up and inconvenient to maintain, and feels pointless after a while when the high-profile attacks leave the public eye.
I am guessing your reasoning is because of the concern of being vulnerable to ransomware. If that isn't the case, then my answer also becomes "why"? All the file systems that support encryption give the options to not use it. Thus you don't have the overhead slowing down your file accesses, and don't have to worry about disk corruption making your entire file system unreadable.
I don't think any of the ransomware varieties leverage the file systems encryption capabilities. They do their own, so disabling encryption at the file system level won't help.
To prevent ransomware from being able to encrypt the files, you'd have to make your file system read-only, or fiddle with the permissions. You could take away your ability to write/modify/delete your data files, and specifically give yourself those rights only when you want to update a file. Not very feasible. I did a little proof of concept recently with a lockbox type of app, that would remove all change permissions to a folder making it read-only to you, administrators, etc. Then when you want to enable your ability to change files, you unlock the folder.
I didn't really go much farther with it because I still don't see that being feasible from a user perspective.
The best protection from ransomware continues to be to make frequent backups of your files. Windows 7/10 have the "previous versions" functionality which is nice because it keeps a history of the files as they change. So if your files become encrypted, deleted, etc. a week ago, but you didn't notice until today, you will still find the undamaged versions.
You could rig windows 7/10 to trigger UAC when your data files are changed if you put those files under "program Files" folder.
If the concern is about preventing files from being made inaccessible, a versioned filesystem (like VMS had), set up so deleting old versions is not trivially possible, is probably among your best bet.
