FileVault juste pour les dossiers /Users/[user], comme dans Snow Leopard

Je sais qu'il y a beaucoup de questions comme celle-ci sur AskDifferent, mais je n'en ai trouvé aucune qui traite spécifiquement de l'omission assez flagrante dans les versions plus modernes de Mac OS du cryptage du dossier personnel par utilisateur via FileFault.

Je ne sais pas quand Apple l'a changé, mais les anciennes versions de OS X FileVault vous permettaient de crypter l'intégralité des dossiers /Users/[user] d'un utilisateur individuel. Non seulement c'était "possible", mais il avait une interface super facile qui semblait encourager les utilisateurs à découvrir la fonctionnalité, et à la réaliser.

Par exemple, j'ai un Macbook Pro 6,2 2010 fonctionnant sous Snow Leopard, avec des dossiers /Users/[utilisateur] chiffrés individuellement. C'est une fonctionnalité formidable et très nécessaire pour de nombreux cas d'utilisation. (Par exemple, la plupart des scénarios où plusieurs utilisateurs utilisent le même macbook, que ce soit à la maison ou au travail). Je ne mettrai jamais à jour l'OS, pour ne pas perdre cette fonctionnalité !

J'utilise également un Macbook Pro 11,3 de 2014 fonctionnant sous El Capitan. FileVault n'a pas une telle option pour crypter /Users/[utilisateur]. Cela semble être un énorme pas en arrière. Le chiffrement de l'ensemble du disque - bien que génial si vous perdez votre ordinateur portable alors qu'il est complètement éteint - ne répondra en rien au cas d'utilisation courant mentionné ci-dessus. (D'ailleurs, certains experts considèrent que le fait d'avoir des dossiers personnels cryptés - plus un compte "invité" sans mot de passe [plus un service de récupération en cours d'exécution] - est un bon moyen d'améliorer vos chances de récupérer l'ordinateur. Ce n'est pas parfait et cela ne correspond pas aux voleurs professionnels qui l'effacent de toute façon, mais c'est mieux que rien).

Cette question comporte donc deux parties : 1) Existe-t-il une solution, idéalement native, pour le cryptage par utilisateur /Users/[utilisateur] ; et 2) Pourquoi Apple a-t-elle supprimé une fonction aussi essentielle de FileVault ? Peut-être que seul Apple le sait. Mais souvent, les "pourquoi" derrière des décisions controversées sont publiquement connus ou du moins connus. Par exemple, ils sont expliqués dans les blogs des développeurs, les notes de mise à jour, les vidéos des conférences publiques des utilisateurs/développeurs, les discours lors des congrès, les interviews des développeurs par les blogs techniques, etc.

Je sais parfaitement qu'il est très facile de créer un fichier de bouclage crypté que je peux monter après la connexion et même automatiser le montage, pour y stocker des documents sensibles. Mais comme nous le savons, il y a pas mal d'informations potentiellement sensibles qui sont stockées automatiquement dans /User/[home], par conception et comme prévu par Apple, y compris des paramètres dont nous ne sommes peut-être même pas conscients, qui rendent impératif le chiffrement par utilisateur de l'ensemble du dossier /User/[user]. (Et d'ailleurs, plutôt que d'utiliser un fichier de bouclage crypté, j'utiliserai simplement un dossier eCryptFS partagé via SMB vers une VM exécutant Linux, ce qui est ma solution standard sur Windows et Mac lorsqu'on n'exécute pas Linux en natif).

BTW - Je n'utilise pas TimeMachine.

Mise à jour : La raison fondamentale du chiffrement par utilisateur de son dossier /User/[utilisateur], avec des clés de chiffrement uniques, est la suivante . protéger les données de l'utilisateur contre les autres utilisateurs du même système . Bien que l'on puisse ne pas être d'accord avec le fait de donner des droits sudo à plusieurs utilisateurs d'un même système, il existe de nombreux cas d'utilisation légitimes pour le faire. FileVault2 ne "sécurise" les utilisateurs que les uns par rapport aux autres, via les permissions de fichiers unix. Mais l'accès aux données d'autrui n'est possible qu'avec un "sudo chmod -R". Ce n'est pas une réel à l'exigence de sécurisation des données des utilisateurs entre eux. Une véritable solution implique des clés de chiffrement uniques pour l'ensemble des dossiers personnels des utilisateurs (/home/[user] ou /Users/[user]). De nombreuses distributions Linux rendent cela trivialement facile, tout comme les anciennes versions de Mac OS X / FileVault.

Mise à jour 2 : Les dossiers système tels que Library et var "pourraient" contenir des données utilisateur sensibles - soit stockées à dessein par des applications conçues de manière négligente, soit divulguées accidentellement - mais 1) ne le font presque jamais dans le monde réel des systèmes unix et similaires à unix, 2) par convention pour les applications qui se comportent bien ne sont pas censées le faire, et 3) plus important encore - ne sont même pas physiquement en mesure de le faire à une époque de sandbox-iness croissante - par exemple mac OS ne permettant pas aux applications fonctionnant en mode utilisateur d'écrire dans des emplacements sensibles comme celui-ci. De plus, le simple fait que des applications malveillantes et/ou mal conduites puissent faire fuir des données sensibles de l'utilisateur vers un dossier système n'est pas un argument rationnel contre l'exigence d'un utilisateur ou d'une organisation de sécuriser les utilisateurs sudo entre eux sur le même système. Mais plutôt que d'ajouter un débat inutile à cette question, mettons simplement à jour l'exigence :

"Sécuriser les données des utilisateurs les unes par rapport aux autres avec leurs propres clés de chiffrement uniques appliquées à l'ensemble du dossier /User/[user] de chaque utilisateur, que tous les utilisateurs aient ou non des droits sudo, afin de sécuriser toutes leurs données en mode utilisateur normal, à l'exception du cas limite intrinsèquement difficile à couvrir de la fuite de données sensibles de l'utilisateur vers les dossiers système globaux qui, bien sûr, est censé être impossible au niveau du système d'exploitation lorsque les applications sandboxées sont exécutées en mode utilisateur normal."