Повышение безопасности машины времени

Обновление после обсуждения с bmike (см. ниже)

Во время фактического резервного копирования Time Machine backupd монтирует два общих ресурса. /Volumes/Whatever и /Volumes/Time Machine Backups. В то время как первый не может быть доступен пользователю без полномочий root, последний может. Действительно, можно очистить ACL файлов и впоследствии перезаписать их. Так что вопрос безопасности открыт.

Оригинальный ответ

Немного подумав о базовой системе крепления, я пришел к выводу, что мой первоначальный вопрос содержал ошибочное предположение, удаление которого, возможно, делает вопрос устаревшим. Я решил написать ответ вместо того, чтобы удалить вопрос в пользу столь же заблуждающихся.

Когда я проверил права доступа к своим файлам sparsebundle, я вручную смонтировал диск Time Capsule. Поскольку я смонтировал диск как обычный пользователь, этот пользователь стал владельцем точки монтирования (проверив терминал, я вижу, что моя учетная запись пользователя является владельцем точки монтирования, а «персонал» - это группа).

Теперь мое предположение (которое не было для меня прозрачным) заключалось в том, что если Time Machine смонтирует диск во время сеанса резервного копирования, он будет присутствовать в системе так же, как если бы я смонтировал его вручную. Но это неправильно. Ибо так как backupd запускается от root, то точка монтирования принадлежит root (проверка в терминале, владелец "root", группа "wheel", группа и мир не имеют прав.) и, таким образом, процесс, принадлежащий обычному пользователь не сможет зашифровать файлы на диске Time Machine, смонтированном с помощью backupd .

Таким образом, в настройке Time Capsule на данный момент не существует опасности, что программа-вымогатель зашифрует резервную копию. Однако с локально подключенным внешним жестким диском все может быть по-другому. Я смутно помню, что, когда я все еще использовал внешний жесткий диск, я мог видеть раздел Time Machine, смонтированный в Finder (чего я сейчас не вижу), и, следовательно, он мог быть смонтирован с правами пользователя. Я не могу проверить это, так как у меня нет внешнего жесткого диска с машиной времени, но, возможно, кто-то еще может что-то сказать по этому поводу.

Резервные копии Time Machine в первую очередь защищены ACL, запрещающим кому-либо запись в файл.

$ 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

Чтобы вредоносная программа изменила файл в подсистеме резервного копирования, ей необходимо сначала прочитать и удалить любой ACL, а затем она сможет внести изменения в файл, хранящийся в каталоге Time Machine.

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

После приведенной выше команды файл открыт для модификации или полного удаления.

Код программы не нуждался бы в каком-либо специальном корневом доступе - просто он работал под обычным пользователем с правами администратора, чтобы внести это изменение, а затем иметь возможность писать в файлы.

Ни песочница, ни защита целостности системы не остановят какой-либо вредоносный процесс, запущенный от имени администратора, от шифрования/изменения/удаления файлов пользовательских данных на резервном диске, который можно подключить (сетевые диски) или подключить и уже подключить.

Чтобы защитить ваши резервные копии, вам нужно будет так или иначе иметь копию в автономном режиме, предполагая, что злоумышленник знает, что нужно проверить и изменить/удалить ACL, прежде чем они вмешаются.

Я бы рассмотрел варианты шифрования, чтобы защитить некоторые файлы, с которыми вы не можете позволить себе случайную программу, и, возможно, не хранить ваш ключ шифрования для второго тома резервной копии в вашей цепочке ключей.

• Шифрование / защита резервного диска Time Machine?

Таким образом, первое место назначения резервного копирования может запускаться часто, но быть уязвимым для вредоносных программ. Второй пункт назначения будет сообщать вам каждые две недели или около того, что он устарел, если вы не смонтируете его и не начнете более ручное резервное копирование.

Это не идеально, но я полагаю, что Apple может перепроектировать систему, если этот потенциальный риск со временем станет более реальным риском в OS X. Единственная спасительная черта привратника и подписанного кода заключается в том, что чем более широко распространено вредоносное ПО, тем более вероятно, что Apple запретит его запуск на машинах, которые используют защиту Gatekeeper. В этом случае похоже, что прошло менее 48 часов с момента публичного объявления об угрозе до того, как средство от Apple отключило ее.