Hardening Time Machine Security

Question

In face of the news that there is now a ransomware for mac in the wild I thought about the security of my time-machine backups.

Permissions

First, I had a look at the permissions of the files that reside on my timecapsule, which are the following:

Data Directory

User (unknown) Read & Write

Group (everyone) Read & Write

Individual Sparsebundles per backuped computer within Data Directory

User (unknown) Read & Write

Group (staff) Read & Write

Group (everyone) Read & Write

It seems that there is room for improvement here. First, I don't understand why an Unknown user is listed. Is there any reason for this or can I delete this item? Second, is there any necessity to give Read and Write Permissions to "everyone" and "staff"?

If I understand correctly, Time Machine Backups are run by the backupd process, which, on my computer, runs as user root. So it seems that only the root user is required to have Read & Write access. Is that correct? Could I delete the existing permissions and add user "root" with Read & Write permissions?

Lastly, would this change provide a further line of defence against ransomware? If a ransomware runs as a normal user X and does not gain root, it could encrypt all files to which X has write access, but it could not encrypt time machine backups, because only root has access to them. Is this line or reasoning correct?

Running OSX El Capitan, 10.11.3.

Answer 1

Update after discussion with bmike (see below)

During an actual Time Machine Backup, backupd mounts two shares. /Volumes/Whatever and /Volumes/Time Machine Backups. While the former cannot be access by a non-root user, the latter can. It is indeed possible to clear ACLs of files and overwrite them subsequently. So the security issue is wide open.

Original answer

Thinking a little more about the underlying mounting system, I came to the view that my original question contained a misguided assumption, the removal of which perhaps makes the question obsolete. I decided to write an answer instead of removing the question for the benefit of the equally misguided.

When I checked the permissions of my sparsebundle files, I manually mounted the Time Capsule disk. Because I mounted the disk as a normal user, this user became the owner of the mount-point (checking in the terminal, I can see that my useraccount is the owner of the mount-point, "staff" being the group).

Now my assumption (which was not transparent to me) was that if Time Machine mounts the disk during a backup session, it would be present in the system just as if I mounted it manually. But this is wrong. For since backupd runs as root, the mount-point belongs to root (checking in the terminal, the owner is "root", the group is "wheel", group and world having no rights.) and thus a process belonging to a normal user would not be able to encrypt files on a Time Machine Disk mounted by backupd.

Thus, in a Time Capsule setup there does not seem to be, for the moment, a danger of a ransomware to encrypt the backup. However, it might be different with a locally connected external harddrive. I vaguely remember that when I still used an external harddrive, I could see the Time Machine partition as mounted in Finder (something I do not now) and thus it might be mounted with user rights. I cannot test this, as I don't have an external time machine harddrive, but maybe someone else can say something about this.

Answer 2

Time Machine backups are primarily protected by ACL denying permission for anyone to write to a file.

$ ls -le /Volumes/Whatever/Backups.backupdb/Mac/Latest/Macintosh\ HD/Users/me/Desktop/file.text 
-rw-r--r--@ 1 me    staff  - 14 Mar  8 11:54 /Volumes/Whatever/Backups.backupdb/Mac/Latest/Macintosh\ HD/Users/me/Desktop/file.text
0: group:everyone deny write,delete,append,writeattr,writeextattr,chown

For a malicious program to change a file on the backup subsystem, it would need to first read for and delete any ACL and then it would be able to make a change to a file thats stored in the Time Machine directory.

$ chmod -a# 0 /Volumes/Whatever/Backups.backupdb/Mac/Latest/Macintosh\ HD/Users/me/Desktop/file.text 

After the above command, the file is open to modifications or outright deletion.

The code of the program wouldn't need any special root access - just that it ran under a normal admin user to make this change and then be able to write to the files.

Neither sandboxing nor System Integrity Protection would stop any malicious process that runs as an admin from encrypting/modifying/deleting user data files on a backup drive that was mountable (network drives) or attached and already mounted.

To harden your backups, you would need to have a copy offline in some manner or other assuming the bad actor knows to check and modify/remove ACL before they tamper.

I would look over encryption options to protect some files you can't afford a random program to taper with and optional not storing your encryption key for a second backup volume in your keychain.

• Encrypting/protecting Time Machine backup drive?

That way, the first backup destination could run often but be vulnerable to malware. The second destination would prompt you every two weeks or so that it's out of date if you don't mount it and kick off a more manual backup.

It's not ideal, but I would presume Apple could re-engineer the system if this potential risk becomes more of an actual risk over time on OS X. The one saving grace about gatekeeper and signed code is that the more widely spread malware is, the more likely Apple will ban it from running on machines that opt in to Gatekeeper protection. In this case, it looks like it took less than 48 hours from public announcement of the threat to the remedy to disable it being available from Apple.