Re: "Not really. What you can do, they can UNdo"
"by, say, using privilege escalation"
Here's one part of the problem, the notion that there are users or programs which have more privileges than others. So it, for instance, I have root privilege I can encrypt anybody's files.
I used to work with database servers where the server had sole control of an area of disk space in that only the server read or wrote from the disk because only it had the algorithms for the storage structures. Any program which needed access to the data had to do that through a client/server relationship.
Now running under, say, a Unix system this isn't perfect.
Firstly there's no mechanism to verify the client that makes the request is allowed to do so, the only security is at the user level so a rogue program running under the user's ID could wreak havoc.
Secondly although the disk might be allocated to a server ID and group with 660 permissions there's nothing to stop a rogue program elevated to root from trashing the whole disk area.
This sort of client/server relationship between processing and storage could be applied as a basis for securing data.
So there are a couple of things to look at in terms of OS architecture.
One is to provide authentication IDs to programs as well as users so if user fred's office-suite program wants to write a revised version of his masterpiece to disk it has to call the server and there is then a mechanism in place to verify that the caller has both fred's authorisation in order to overwrite* an existing file of fred's and office-suite's authorisation to call the server. This, of course, depends on some mechanism such as code signing to verify that the office-suite can be installed with the correct ID. There could be additional safeguards such as the server verifying that the file actually has the structure that's expected - if, for instance, it's supposed to be an OpenDocument file it should have the structure of a zipped file containing several XML documents which are valid according to the appropriate schemata. This verification mechanism might even come into play when the office-suite is passed an alleged office file from the email client**.
The other is to not have that omnipotent root. There needs to be a disk space manager that can dole out a portion of space to the server. That manager doesn't, however, have to have the rights to read or write to that portion, nor does it have to have the rights to set up user or program IDs. It might even be the case that such a manager can only be active when booted into a safe mode.
Do we sacrifice some operational convenience for this sort of OS? Maybe, but it's arguable that some of our woes are the direct result of sacrificing security for convenience. The balance is wrong and needs to be rectified. Id be surprised (assuming I'm still here!) if we're still using such intrinsically unsuitable OSs by the end of the next decade, and probably a good deal sooner. Note that I regard Unix-style as well as Windows-style OSs as intrinsically unsuitable.
* Of course it might not overwrite, there might be versioning in play.
** If the user stores copies of emails locally there will, of course, be a separate server with its own disk space for this purpose.