4 ms·

eh that's load of work for something that'll require constant manual intervention, besides, block level protection is the wrong level of abstraction and will ge

eh that's load of work for something that'll require constant manual intervention, besides, block level protection is the wrong level of abstraction and will get in the way of getting anything done, unless you rewrite the whole operating system to be aware of that (just run a lsof / openfiles ) a software defined version would be: make an opt in sandbox for processes that ties a folder and it's content to a single executable, with the executable pinned by the operating system and let the whole thing be mediated by the kernel. of course that's as thigh as the kernel security, but if you're worried by that, offsite incremental backups are a cheaper answer.

ChuckMcM 9y ago
Understand that it is isn't required to be set to change files, it is only required to be set to change a block on disk which has been marked as protected. If your OS marked nothing as protected it would never have to be set. If you look at the time stamp history of your 'system' files on a windows system (C:\Windows\System\*) you will see that the files have a change frequency of approximately once every 3 to 6 months. That would correlate with when you would need to flip the switch to allow an update (ie very rarely, like 2 or 3 times a year).
- LoSboccacc 9y ago
  if you rely on the os to mark protected sectors, the physical switch becomes moot. malware can just keep quiescent til a privileged action is required, especially if the switch is a disk wide all-or-nothing also, system files aren't really the target here, the issue are userland files - who cares that the os is safe when the data is crypted
- khedoros1 9y ago
  Well...but I don't know which files will be updated when, and Windows 10 likes rebooting itself automatically to update files. On top of that, I'm not terribly worried about malware encrypting Windows, more like it encrypting my own data files, which change much more often than several times a year. Some malware gets delivered to my computer as a new file, and the code that it contains begins to execute as an admin user. Its attempts to mess around with C:\Windows is thwarted by block-level protection. Instead, it goes into C:\Users\Me and starts encrypting stuff (not block-level protected, because it's all constantly changing anyhow). So, it can't modify the Windows system files that I could just re-install anyhow, but it can modify the creative output on my disk that only exists in a month-old backup copy, or something. Given that scenario, I'm not sure how much help the ability to write-lock blocks would be.

ChuckMcM 9y ago

Understand that it is isn't required to be set to change files, it is only required to be set to change a block on disk which has been marked as protected. If your OS marked nothing as protected it would never have to be set. If you look at the time stamp history of your 'system' files on a windows system (C:\Windows\System\*) you will see that the files have a change frequency of approximately once every 3 to 6 months. That would correlate with when you would need to flip the switch to allow an update (ie very rarely, like 2 or 3 times a year).

LoSboccacc 9y ago
if you rely on the os to mark protected sectors, the physical switch becomes moot. malware can just keep quiescent til a privileged action is required, especially if the switch is a disk wide all-or-nothing also, system files aren't really the target here, the issue are userland files - who cares that the os is safe when the data is crypted
khedoros1 9y ago
Well...but I don't know which files will be updated when, and Windows 10 likes rebooting itself automatically to update files. On top of that, I'm not terribly worried about malware encrypting Windows, more like it encrypting my own data files, which change much more often than several times a year. Some malware gets delivered to my computer as a new file, and the code that it contains begins to execute as an admin user. Its attempts to mess around with C:\Windows is thwarted by block-level protection. Instead, it goes into C:\Users\Me and starts encrypting stuff (not block-level protected, because it's all constantly changing anyhow). So, it can't modify the Windows system files that I could just re-install anyhow, but it can modify the creative output on my disk that only exists in a month-old backup copy, or something. Given that scenario, I'm not sure how much help the ability to write-lock blocks would be.