5 votes

Renforcer la sécurité de Time Machine

Face à la nouvelle qu'il y a maintenant une ransomware pour mac dans la nature J'ai pensé à la sécurité des sauvegardes de ma machine à voyager dans le temps.

Permissions

Tout d'abord, j'ai regardé les permissions des fichiers qui résident sur ma timecapsule, qui sont les suivantes :

Répertoire de données

Utilisateur (inconnu) Lecture et écriture

Groupe (tout le monde) Lire et écrire

Sparsebundles individuels par ordinateur sauvegardé dans le Data Directory.

Utilisateur (inconnu) Lecture et écriture

Groupe (personnel) Lire et écrire

Groupe (tout le monde) Lire et écrire

Il semble qu'il y ait place à l'amélioration dans ce domaine. D'abord, je ne comprends pas pourquoi un utilisateur inconnu est listé. Y a-t-il une raison à cela ou puis-je supprimer cet élément ? Deuxièmement, est-il nécessaire de donner des droits de lecture et d'écriture à "tout le monde" et "personnel" ?

Si j'ai bien compris, les sauvegardes Time Machine sont exécutées par l'application backupd qui, sur mon ordinateur, fonctionne en tant qu'utilisateur Racine . Il semble donc que seul le Racine L'utilisateur doit avoir un accès en lecture et en écriture. Est-ce exact ? Pourrais-je supprimer les autorisations existantes et ajouter l'utilisateur "Root" avec des autorisations de lecture et d'écriture ?

Enfin, ce changement apporterait-il une ligne de défense supplémentaire contre les ransomwares ? Si un ransomware s'exécute en tant qu'utilisateur normal X et n'obtient pas Root, il pourrait crypter tous les fichiers auxquels X a accès en écriture, mais il ne pourrait pas crypter les sauvegardes de Time Machine, car seul Root y a accès. Ce raisonnement est-il correct ?

J'utilise OSX El Capitan, 10.11.3.

1voto

Philipp Points 111

Mise à jour après discussion avec bmike (voir ci-dessous)

Lors d'une sauvegarde Time Machine réelle, backupd monte deux partages. /Volumes/Whatever et /Volumes/Time Machine Backups. Alors que le premier ne peut pas être accédé par un utilisateur non-Root, le second peut l'être. Il est en effet possible d'effacer les ACL des fichiers et de les écraser par la suite. La question de la sécurité est donc largement ouverte.

Réponse originale

En réfléchissant un peu plus au système de montage sous-jacent, je suis arrivé à la conclusion que ma question initiale contenait une hypothèse erronée, dont la suppression rend peut-être la question obsolète. J'ai décidé d'écrire une réponse au lieu de supprimer la question au profit d'autres personnes tout aussi mal avisées.

Lorsque j'ai vérifié les permissions de mes fichiers sparsebundle, j'ai monté manuellement le disque Time Capsule. Comme j'ai monté le disque en tant qu'utilisateur normal, cet utilisateur est devenu le propriétaire du point de montage (en vérifiant dans le terminal, je peux voir que mon compte utilisateur est le propriétaire du point de montage, "staff" étant le groupe).

Maintenant, mon hypothèse (qui n'était pas transparente pour moi) était que si Time Machine monte le disque pendant une session de sauvegarde, il serait présent dans le système tout comme si je le montais manuellement. Mais c'est faux. Car depuis backupd s'exécute en tant que Root, le point de montage appartient à Root (en vérifiant dans le terminal, le propriétaire est "Root", le groupe est "wheel", group et world n'ayant aucun droit) et donc un processus appartenant à un utilisateur normal ne serait pas en mesure de chiffrer des fichiers sur un disque Time Machine monté par backupd .

Ainsi, dans une configuration Time Capsule, il ne semble pas y avoir, pour l'instant, de risque qu'un ransomware crypte la sauvegarde. Cependant, il pourrait en être autrement avec un disque dur externe connecté localement. Je me souviens vaguement que lorsque j'utilisais encore un disque dur externe, je pouvais voir la partition Time Machine comme montée dans le Finder (ce qui n'est plus le cas aujourd'hui) et donc qu'elle pouvait être montée avec des droits d'utilisateur. Je ne peux pas tester cela, car je n'ai pas de disque dur externe Time Machine, mais peut-être que quelqu'un d'autre peut dire quelque chose à ce sujet.

1voto

Oskar Points 1242

Les sauvegardes Time Machine sont principalement protégées par des ACL refusant à quiconque la permission d'écrire dans un fichier.

$ 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

Pour qu'un programme malveillant puisse modifier un fichier sur le sous-système de sauvegarde, il devrait d'abord lire et supprimer toute ACL, puis il pourrait modifier un fichier stocké dans le répertoire Time Machine.

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

Après la commande ci-dessus, le fichier est ouvert aux modifications ou à la suppression pure et simple.

Le code du programme n'aurait pas besoin d'un accès spécial à la racine - il suffirait qu'il soit exécuté sous un utilisateur administrateur normal pour effectuer ce changement et pouvoir ensuite écrire dans les fichiers.

Ni le sandboxing ni la protection de l'intégrité du système n'empêcheraient un processus malveillant s'exécutant en tant qu'administrateur de crypter/modifier/supprimer les fichiers de données de l'utilisateur sur un lecteur de sauvegarde montable (lecteurs réseau) ou attaché et déjà monté.

Pour renforcer vos sauvegardes, vous devez avoir une copie hors ligne d'une manière ou d'une autre, en supposant que le mauvais acteur sache vérifier et modifier/supprimer les ACL avant de les altérer.

Je me pencherais sur les options de cryptage pour protéger certains fichiers avec lesquels vous ne pouvez pas vous permettre de faire appel à un programme aléatoire et sur la possibilité de ne pas stocker votre clé de cryptage pour un second volume de sauvegarde dans votre trousseau.

De cette façon, la première destination de sauvegarde pourrait fonctionner souvent mais être vulnérable aux logiciels malveillants. La seconde destination vous signalerait toutes les deux semaines environ qu'elle est périmée si vous ne la montez pas et déclencherait une sauvegarde plus manuelle.

Ce n'est pas idéal, mais je suppose qu'Apple pourrait réorganiser le système si ce risque potentiel devenait plus important au fil du temps sur OS X. Le seul point positif de la protection Gatekeeper et du code signé est que plus les logiciels malveillants sont répandus, plus il est probable qu'Apple leur interdira de s'exécuter sur les machines qui optent pour la protection Gatekeeper. Dans ce cas, il semble qu'il ait fallu moins de 48 heures entre l'annonce publique de la menace et la mise à disposition du remède par Apple.

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X