I asked Macrium about this over PM and they confirmed that it would be possible, so I'm submitting it as an official Wish List request. Not all users store their definition files in locked down locations such as within their own user profile folder, which means some definition files would be editable even by non-admin users -- and it occurred to me that malicious modification of a definition file, either by malware or a human attacker, could have some serious consequences. The greatest risks in my mind are these:
- Redirecting backups to a different destination, which could facilitate data theft. For example, a full system image sent to a location that the attacker controlled would give them access to data from the system that they would not otherwise have had as a non-admin.
- Changing the data being backed up, either maliciously (removing content) or adding content to be backed up in conjunction with the "redirected destination" data theft scenario above.
- Implementing a malicious retention policy, e.g. "Retain 1 Full, match on all backups in the destination, run purge before backup". If the attacker were subsequently able to cause a Full backup to fail mid-job, the user would be left with no backups at their destination.
- Changing the encryption password (or enabling encryption). In conjunction with the malicious retention policy above to purge all previous backups, and perhaps damaging the source system somehow after creating a new backup with the "malicious" encryption, the attacker would effectively be able to hold the victim's data for ransom.
Currently MIG only protects backup files based on their file extension. Definition files use the XML extension, and it would clearly not be appropriate for MIG to start blocking modifications to all XML files the system. However, if MIG could extend its protection to include only the specific XML files "registered" in Reflect under its Backup Definition Files tab, I think this would add some valuable security without creating any hassles for end users. I suspect only a small minority of users ever modify their XML files outside of Reflect, and especially now that Reflect 7.2 has a popup notification when MIG blocks something, the underlying cause of any issues encountered by those users would be clear. Still, perhaps this extended protection should be optional to accommodate users who want to protect their backups but not their definition files. I myself admittedly wrote a script in this thread
for another user here that modifies the XML file just before Reflect runs in order to achieve some functionality he wanted.