OS X Mountain Lion : les développeurs, Gatekeeper et le sandboxing

Anthony Nelzin-Santos |
À partir du 1er mars, toutes les applications distribuées dans le Mac App Store devront utiliser le système de sandboxing d'OS X. La transition n'est pas simple : ce système permet certes d'augmenter la sécurité de l'utilisateur, mais n'est d'une part pas infaillible et d'autre part pas toujours aussi complet que les développeurs le voudraient. Pire : à deux semaines de l'échéance, Apple a présenté dans OS X Mountain Lion une alternative potentielle au sandboxing. Qu'en est-il vraiment ?

Sécurité

Sandboxing : jouer dans un bac à sable
Le sandboxing est une pratique héritée d'iOS : une application placée dans le "bac à sable" doit demander la permission au système d'utiliser un jeu réduit de fonctions et d'accéder à un ensemble réduit de fichiers. Apple détermine l'étendue du bac à sable en restreignant le nombre de permissions et en contrôlant le fonctionnement du système par un jeu de signatures. Le tout est censé répondre à un double argument, sécuritaire et pratique (pour aborder plus en détail le sandboxing : lire : OS X Lion : comprendre le casse-tête du sandboxing).

Ce système restrictif pose néanmoins de nombreux problèmes aux développeurs, notamment à ceux d'utilitaires ou d'applications complexes, exclus de facto du Mac App Store. Beaucoup s'en sont émus, et certains ont rempli des rapports de bogues pour obtenir l'attention d'Apple — à l'écoute, la firme de Cupertino leur a répondu. OS X 10.7.3 contient ainsi de nouvelles permissions et des permissions mises à jour :


  • interaction avec les appareils FireWire (sauf accès direct aux appareils audio / vidéo comme les caméras DV) ;

  • interaction avec les appareils Bluetooth ;

  • interaction avec les appareils série ;

  • accès aux appareils HID (joysticks, etc.) via la permission d'interaction avec les appareils USB ;

  • possibilité de graver des disques optiques ;

  • accès plus permissif au Carnet d'adresses ;

  • modification de la luminosité du système ;

  • exécution de commandes depuis /bin, /sbin, /usr/bin et /usr/sbin ;

  • création et connexion libres de sockets du domaine UNIX ;

  • transmission de signaux aux processus enfants.



Certaines de ces nouvelles règles lèvent les doutes sur des applications : la gestion du FireWire et du Bluetooth, par exemple, ne limite plus certains utilitaires. Reste que la liste est encore et toujours trop limitée, et certains développeurs n'ont d'autre choix que de quitter le Mac App Store. Atlassian a ainsi annoncé que SourceTree, son client Git, Mercurial et Subversion, ne serait désormais plus disponible que sur son site web. Manton Reece a aussi des doutes concernant le maintien de son application Clipstart dans le Mac App Store, comme Pieter Omvlee, le développeur de Fontcase.

Sandboxing

De manière générale, le bac à sable est conçu avec l'idée que le système est une machinerie de moins en moins visible et de plus en plus transparente, un ensemble de services assemblé comme un moteur pour de multiples applications spécialisées, et non une immense plateforme généraliste. Il est donc très adapté aux applications d'édition de documents, qui sont par essence confinées dans un « espace » réduit — mais des applications comme SourceTree, Transmit qui ont besoin d'un accès permanent au système de fichiers, ou des surcouches système comme TextExpander s'accommodent très mal au sandboxing.

[MàJ] Quelques heures après la parution de notre article, Apple a annoncé qu'elle repoussait la date limite d'adoption du sandboxing du 1er mars au 1er juin 2012 (lire : Apple repousse la date limite pour l'adoption du sandboxing).

Gatekeeper : jouer librement dans un parc fermé
L'obligation pour les applications du Mac App Store, canal privilégié de distribution, d'utiliser le sandboxing est conçue par Apple comme un moyen de renforcer la sécurité de l'utilisateur. Le Gatekeeper d'OS X Mountain Lion va encore plus loin : il impose certains éléments de la sécurisation du Mac App Store à l'ensemble des applications distribuées par d'autres moyens (lire : Gatekeeper : le garde-chiourme de Mountain Lion & Gatekeeper : des satisfecit teintés de prudence ).

Apple se pose en autorité de certification et va fournir un système de signatures numériques à l'ensemble des développeurs OS X, comme c'est déjà le cas pour ceux qui distribuent leurs applications via le Mac App Store. Cette signature identifiera l'application et son développeur : si une application récupérée depuis Internet se révèle malintentionnée, Apple peut la désactiver, la signaler comme malveillante à son installation, voire étendre la protection à l'ensemble des applications du développeur concerné.

Par défaut, seules les applications signées, qu'elles proviennent du Mac App Store ou d'autres sources, pourront s'exécuter sur OS X Mountain Lion. Les utilisateurs avancés auront le choix de restreindre un poste aux seules applications de la boutique d'Apple, ou au contraire d'ignorer cette couche supplémentaire de sécurité. Ce système, qui avait notamment été suggéré par Wil Shipley, permet d'obtenir un bon niveau de protection tout en gardant une grande flexibilité : il ne fait que mettre en lumière les limites du sandboxing.

Les déboires récents de l'équipe de validation d'Apple montrent que les App Store ne sont pas infaillibles, et peuvent laisser passer des applications qui ne font aucun mal… sauf peut-être à votre porte-monnaie (lire : App Store : Apple fait la chasse aux imitations). Aucun système de sécurité ne pourra s'interposer face à ces véritables arnaques qui fonctionnent grâce à l'inattention et l'inexpérience de la majorité des utilisateurs.

Le sandboxing lui-même n'est pas infaillible : à partir de quelques permissions anodines et au travers d'une potentielle faille, une application malintentionnée peut causer le chaos dans votre système… avec la bénédiction de celui-ci ! Pourquoi s'encombrer de ce système donc, s'il est si incomplet et si Gatekeeper est si sûr et flexible ? Tout simplement parce que le système des signatures n'est pas non plus à l'abri de potentiels problèmes (lire : OS X Lion et le problème des certificats TLS/SSL).

Gatekeeper

C'est bel et bien la combinaison du sandboxing et de la signature numérique qui permet d'améliorer globalement la sécurité, au prix de quelques ajustements pour les développeurs. C'est ainsi que fonctionnent les applications du Mac App Store — mais même dans OS X 10.8 Mountain Lion, les applications obtenues hors du Mac App Store pourront se passer du sandboxing et potentiellement causer des dommages avant la révocation de leur signature. Ainsi Craig Hockenberry explique maintenir désormais deux versions de XScope : une sandboxée et signée, distribuée dans le Mac App Store, et une sans bac à sable, distribuée sur son site web. On le comprend bien dans son cas — et c'est un développeur connu et reconnu — mais on peut voir les éventuels problèmes que cela pourrait poser dans la situation d'un développeur moins bien intentionné.

La solution est peut-être l'approche proposée par Daniel Jaikut, le développeur de MarsEdit : obliger tous les développeurs, qu'ils distribuent leurs applications dans le Mac App Store ou d'ailleurs, à utiliser le sandboxing et la signature numérique. Cela représenterait certes une plus grande charge de travail au moment de l'adaptation, mais Apple a toujours privilégié la sécurité et le plaisir de l'utilisateur au confort du développeur. Cette décision forcerait les développeurs à adopter les deux mécanismes, et participerait à maintenir la relative sécurité d'OS X. Elle requiert néanmoins qu'Apple soit plus à l'écoute, et réagisse plus rapidement pour inclure les permissions nécessaires à l'exécution des applications les plus complexes (quitte à permettre à celles-ci de franchir le bac à sable contre une surveillance renforcée).

On atteint là la limite de ces mécanismes : la volonté d'Apple de les promouvoir, et sa capacité à le faire. Cette approche mixte qui se dessine dans OS X Mountain Lion et qui pourrait devenir obligatoire dans ses successeurs ne fait que renforcer la frustration causée par le manque chronique de communication à moyen et long terme par Apple, qui ne permet pas à ses partenaires de valider certains choix financièrement lourds. Un véritable défi, mais qui pourrait être une des plus belles réussites de la firme de Cupertino dans le domaine, si elle parvenait à le relever.
avatar Armas | 
Je privilégierais toujours les applications qui ne seront pas tirées de l'app store. Le sandboxing est une régression technologique trop contraignante par rapport à ce qu'elle apporte. Elle ne sera utile que pour les néophytes qui ne connaissant pas encore bien l'environnement mac mais risque de devenir un vrai boulet à trainer pour les utilisateurs avancés qui utilisent des logiciels un soupçon plus évolués. Je me demande comment peuvent fonctionner des logiciels comme little snitch dans de telles conditions.
avatar Francis Kuntz | 
J'allais justement dire le contraire. Je privilégies les applications du Mac App Store et en particulier avec l'application du sandboxing qui fera le ménage dans les applications codées avec les pieds.
avatar Jimmy_ | 
Apple a réussi à faire pire que Palladimum. Mais bon restreindre les libertés au nom de la sécurité c'est dans l'air du temps. Prochaine étape, envoyer son empreinte génétique à Apple pour être certains que c'est le bon utilisateur.
avatar lmouillart | 
@Francis Kuntz le passe au sandboxing ne s'effectue pas en un claquement de doigts, typiqmement Redhat met ce type de solutions en oeuvre depuis 2004. Il y a effectivement beaucoup de code à modifier et de règles d'accès à définir. Ce que je ne comprends pas c'est pourquoi ils ne se sont visiblement pas basé sur les architectures FLASK qu'on peu trouver dans TrustedBSD et notamment la partie SEBSD. Ensuite il faudrait que les applications standards : safari/apercu/itunes/apache/le moteur de composition ... soient sandboxés, car ce sont celles qui sont les susceptible d'être attaquée. Sinon le sandboxing est une bonne chose pour l'amélioration de la sécurité des outils informatiques.
avatar Armas | 
Une application codée avec les pieds en dehors de l'appstore le restera dans l'appstore. Le fait est que la majorité des applications présentées sur cette plateforme viennent de développeurs qui ont fait leurs premiers pas sur iphone. Ce sont des devs qui en général ne maîtrisent pas complètement l'environnement mac, voir ne maîtrisent pas l'informatique. Ils proposent pour la très grande majorité des applications basées sur l'utilisation de trois ou quatre scripts systèmes emballés dans un joli packaging mais il faudra se faire une raison. Les développeurs des meilleurs logiciels de l'environnement mac proposent également voir uniquement leurs produits en dehors de l'appstore.
avatar SolMJ | 
[quote]Ensuite il faudrait que les applications standards : safari/apercu/itunes/apache/le moteur de composition ... soient sandboxés, car ce sont celles qui sont les susceptible d'être attaquée.[/quote] Tu es sûr d'avoir bien compris le principe du sandboxing ? Le sandboxing ne protège pas les applications des "attaques". Elle protège le système des applications (qui sont "sandboxées").
avatar Psylo | 
[i]Le sandboxing est une pratique héritée d'iOS[/i] mais qui existe depuis belle lurette, comme par exemple les chroot jail sous FreeBSD. Macgénération, la Pravda, en pire.
avatar Artanis | 
@ Armas: le bac à sable est très utile d'un point de vue sécurité. C'est juste trop limité pour certains programmes. Pas grave, ça n'empêche pas de l'utiliser la plupart du temps, et de passer outre pour le reste.
avatar Artanis | 
@ lmouillart: J'avoue que je n'ai pas suivi ça de très près, mais il me semble que Safari progresse, de ce côté-là. Les infrastructures sont un peu longues à se mettre en place, mais ça va dans le bon sens.
avatar Artanis | 
@ Psylo: Remplace mentalement "pratique" par "implémentation", peut-être?
avatar Anthony Nelzin-Santos | 
@Psylo : parce que FreeBSD est produit par Apple, de laquelle on parle dans cet article ? @lmouillart : Safari, Mail et Aperçu sont sandboxés.
avatar joneskind | 
@Psylo C'est quoi ton problème ? En quoi le fait de dire "j'ai hérité du gout de la musique de mon père" sous-entend "mon père a inventé la musique" ? J'commence vraiment à en avoir marre de tous ces rageux complètement abrutis.
avatar lmouillart | 
@SolMJ "Le sandboxing ne protège pas les applications des "attaques". Elle protège le système des applications (qui sont "sandboxées")." C'est exactement le cas : l'idée est qu'un débordement de pile ou autre d’aperçu/apache/... ne puisse permettre de sortir du contexte du bac à sable pour mettre en péril l'OS.
avatar Kringe | 
Bien moi je trouve qu'il y a beaucoup d'application de l'appstore qui ne sont pas sandboxées alors qu'elles devraient l'être. Il faudrait donc choisir d'imposer un sandbox au cas par cas selon moi.
avatar Philactere | 
Question aux spécialistes sur un point pas clair pour moi : le sendboxing protege-t'il le système uniquement des applications volontairement malveillantes en les confinant dans un bac à sable ou également de bugs d'applications "honnêtes" qui ouvriraient des failles (cas de buffer overflow comme dit par lmouillart ?) exploitables par des applications malveillantes sendboxees ou non ? C'est une question qui peu intéresser l'utilisateur (averti). Je pourrais m'imaginer installer des applications non sendboxées quant j'ai une entière confiance dans l'honnêteté de l'éditeur mais privilégier uniquement des applications sendboxées dans le cas de petits éditeurs moins reconnus par exemple. Bref ce qui peu être intéressant dans le sendboxing c'est de pouvoir faire le tri entre le bon grain et l'ivraie tout en pouvant utiliser l'ivraie de manière sécurisée.
avatar lmouillart | 
@philactere Le sandboxing permet d'isoler une application/ un composant et de la faire communiquer par le biais de canaux identifier avec l'OS ou d'un système. En gros disons que ton OS correspond au centre des nations unis, tu veux laisser des personnes (les programmes) communiquer avec les émissaires (l'OS) mais tu ne souhaite pas qu'ils se fassent trucider. Tu vas donc passer par des sas de sécurité montrer tes papiers (gatekeeper), dire ce que tu souhaite y faire (liste d'accès), et faire des choses suivant le protocole des nations unis (l'objectif de ton programme). Ca ne t'empeche pas d'être porteur de virus biologique (ton identité reste la même). D'être en fait mal intentionné mais de montrer patte blanche De te faire corrompre par des organisations terroriste. Ce bien évidemment soumis aux capacité de contrôle des services de sécurité des UN (possibilité de sortir du bac a sable) Si tu as confiance à part égale dans tous les éditeurs les applications à sandboxé en premier sont celles qui ont beaucoup de failles de sécurités : itunes, safari, cups, appercu, flash, acrobat reader, apache. Si tu n'as pas confiance en ton éditeurs le sandboxing est préférable dans tous les cas. Les logiciels des gros éditeurs sont souvents très exigeants en terme de besoins d'accès à l'OS et bypassent touts ces mécanisme ou nécessitent leurs désactivation.
avatar Domsou | 
@Armas : 'Les développeurs des meilleurs logiciels de l'environnement mac proposent également voir uniquement leurs produits en dehors de l'appstore.' Lesquels ? Et pourquoi les logiciels sur le Ac App Store devraient être moins bons ? Pixelmator ?
avatar liocec | 
"obliger tous les développeurs, qu'ils distribuent leurs applications dans le Mac App Store ou d'ailleurs, à utiliser le sandboxing et la signature numérique." C'est pas mal ça... Après on impose de valider les sources, on impose de donner sa CB, de baisser son froc... Que c'est beau la liberté made Apple ! Heureusement il y aura la passoire Windows qui permetra de développer instablement, mais librement !
avatar lmouillart | 
@liocec Windows à ce fonctionnement depuis 2004 pour les des DRM, signatures des archives et executables, et le mécanisme de sandboxing date de Windows 2000. Ensuite Windows n'est pas une passoire, ce sont les paramétrages par défaut qui sont permissifs. Utilise un Windows sécurisé tu verra que ce n'est pas spécialement passoire.
avatar thierry37 | 
Y'a un truc que je ne comprends pas avec ces signatures. Un gars fait un logiciel signé et accepté par Apple. Ensuite il fait une mise à jour avec de mauvaises intentions cachées. Ça passe. Tout le monde met à jour et Ça fout le bordel ds leurs macs tant que la signature n'est pas révoquée ? Y'a le temps de faire de gros dégâts. Non ?
avatar denmakesmusic | 
moi je n'ai jamais eu aucun problème de sécurité sur Mac depuis 1995 en installant tout un tas de logiciels... c'est de la parano doublée d'une volonté de forcer les developpeurs à passer par l'AppStore (et donc de payer) et de les enfermer dedans.
avatar Anthony Nelzin-Santos | 
@thierry37 : oui. D'où le fait que seul, ce n'est pas le système ultime. Et d'où le fait que ce n'est pas le seul système pour le Mac App Store, où il est associé au sandboxing.
avatar PierreBondurant | 
@denmakesmusic : c'est vrai mais avec l'augmentation des ventes de macs et le profil financier des acheteurs de mac, l'OS va devenir une cible de plus en plus tentante pour les voleurs d'identité, de données Perso (numéro de carte CB...) Je trouve ça bien qu'apple montre qu'elle se soucie de ça et qu'elle implemente des solutions ambitieuses. Même s'il risque d'y avoir une période de transition un peu bordélique pour les devs (lister toutes les fonctionnalités de leur soft et les déclarer lors de l'envoi de leur soft pour validation) et les utilisateurs (pourquoi mon soft préferé n'a plus telle ou telle fonction) En espérant que ça finisse bien...
avatar liocec | 
@lmouillart : 'Windows n'est pas une passoire, ce sont les paramétrages par défaut qui sont permissifs. Utilise un Windows sécurisé tu verra que ce n'est pas spécialement passoire.' Tu te contredis : un windows sécurisé n'est pas une passoire, mais un windows fraîchement installé avec les paramétrages par défaut (sans parefeu ni anti-virus additionnel) est une vraie passoire. Je peux t'affirmer qu'un simple fichier et hop on place un hook sur ta machine, on utilise ton email ou le web pour transmettre des données. Évidement avec un bon parefeu, c'est beaucoup, beaucoup plus compliqué. Idem, l'accès à la machine, aux registres est très aisé sous window Par contre, d'expérience, sur le Mac c'est vachement plus difficile et pour ma part je m'y suis souvent cassé les dents sur la protection système.
avatar liocec | 
[edit] suite.... D'autre part, windows tolère la mise en place des dll un peu où ça arrange le dev, et on se retrouve très rapidement avec un système instable. Si tu veux faire un pari, je te compile un petit binaire rien que pour toi... Ça va t'occuper un moment et windows aussi.... Juste un thread, niveau critique, qui boucle sur lui même... sans écouter ton CTRL+ALT+SUPR Après même si tout n'est pas rose sur OSX, tu comprendras qu'il n'y a rien à voir, c'est vraiment 2 systèmes très différents.
avatar lmouillart | 
"D'autre part, windows tolère la mise en place des dll un peu où ça arrange le dev, et on se retrouve très rapidement avec un système instable." Aucun rapport de cause à effet. "un windows sécurisé n'est pas une passoire, mais un windows fraîchement installé avec les paramétrages par défaut (sans parefeu ni anti-virus additionnel) est une vraie passoire. " => ou est la contradiction ?, Beaucoup d'Unix ont un fonctionnement similaire. "Je peux t'affirmer qu'un simple fichier et hop on place un hook sur ta machine, on utilise ton email ou le web pour transmettre des données."=> idem sur OS X ou n'importe quel système qui n'est pas très sécurisé. "Évidement avec un bon parefeu, c'est beaucoup, beaucoup plus compliqué." => aucun rapport "Idem, l'accès à la machine, aux registres est très aisé sous window" Cela dépend de la politique de sécurité mise en oeuvre. "Si tu veux faire un pari, je te compile un petit binaire rien que pour toi... Ça va t'occuper un moment et windows aussi.... Juste un thread, niveau critique, qui boucle sur lui même... sans écouter ton CTRL+ALT+SUPR" HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\PriorityControl\ Win32PrioritySeparation à configurer suivant ce que tu souhaite.
avatar mfam | 
J'ai l'impression que le sandboxing a un agenda pas si caché et que la sécurité est un prétexte pour plus de contrôle. Puisque je n’a pas souvenance de m’être senti attaqué si souvent par de vilains trucs qui sentent pas bon sur Mac.
avatar boussiko | 
Allez y apple. Conitunez a fermer le systeme et nombreux seront ceux qui quitteront la pomme.
avatar J.C | 
Quelle horreur le sandboxing, mais que leur a t'il pris chez Apple? Ah oui c'est vrai ils vendent des téléphones maintenant et accessoirement ils continuent OSX...
avatar tokugawa | 
Ils vendent aussi de la musique et des films. Est-ce que des applis comme Handbrake pourront être sur le MAS ? Pourquoi cette restriction sur les accés aux devices Audio/Video sur l'USB ?
avatar tokugawa | 
Firewire (pas USB)
avatar lmouillart | 
"Est-ce que des applis comme Handbrake pourront être sur le MAS ?" Oui, mais pas aux USA et dans certains autres pays car il violent un certain nombre de brevets logiciels. La partie décodage de DVD de sera jamais proposé. "Pourquoi cette restriction sur les accés aux devices Audio/Video sur l'USB ?" Ce n'est pas une interdiction mais l'ajout d'une autorisation d'accès.
avatar xatigrou | 
"Si tu veux faire un pari, je te compile un petit binaire rien que pour toi... Ça va t'occuper un moment et windows aussi.... Juste un thread, niveau critique, qui boucle sur lui même... sans écouter ton CTRL+ALT+SUPR" ouais mais ça c'est pas spécifique à Windows, tu peux faire ça sur n'importe quel OS, unix ou pas. Un bon hacker te programme ça quand tu veux, et c'est pas particulièrement courant de voir ça tous les jours, hein ? Et ça n'a rien d'évident ; il faut créer un processus noyau, sans quoi ton fameux thread sera éjecté une fois son quantum de 6ms terminé (on n'est plus à l'époque de Windows 95, avec NT c'est préemptif et réentrant). Ton fameux thread magique ne pourra pas grand chose contre les interruptions du processeur aux ordres noyau de l'OS. Et le noyau des Windows 64 bits étant patché contre toute modif, je le redis, ça n'a rien d'évident. Pour le sempiternel couplet sur les DLL qui rendent le système instable, blablabla =troll Aller, je vais donc faire mon troll moi aussi : "ouais, j'te files une .dylib mac OS daubée du derche qui va te faire planter ton système" 15 ans d'âge mental (désolé de me mettre au niveau) mais tout aussi crédible
avatar lmouillart | 
"Et ça n'a rien d'évident ; il faut créer un processus noyau, sans quoi ton fameux thread sera éjecté une fois son quantum de 6ms terminé (on n'est plus à l'époque de Windows 95, avec NT c'est préemptif et réentrant)." Il me semble que Windows va traiter en round robin les threads real time puis passer à l'étage avec une priorité moindre (la où se situe le contrôle des entrée clavier). Sous Linux il y a un live lock check qui empeche ça, puis à la limite les magicsys req si cela ne passe pas. Sous Windows/OS X je ne sais pas si il existe l'équivalent des magicsys req.
avatar san lee | 
Ce que je ne comprends pas, c'est ceux qui disent que ce sera plus sécuritaire avec le sandboxing… Parce que vous vous sentez menacé en ce moment ? Vous ne savez pas ce que vous installer sur votre machine, ni ou vous le telecharger ? Perso, je pense que le sandboxing risque de limiter les applications du MAS par rapport aux appli qu'on trouvera en dehors ; a partir de la, les meilleures appli risquent d'etre ailleurs que sur le MAS…
avatar Nicolas_D | 
Quid des app scientifiques qui sont très rarement mises à jour, la plupart multiplateformes, et quelquefois dépendantes d'une très petite communauté Open Source ?
avatar lmouillart | 
Quid des app scientifiques qui sont très rarement mises à jour => le fonctionnement sera comme actuellement. Le sandboxing étant un sous ensemble d’exécution pour les applications du MAS. "la plupart multi plateformes, et quelquefois dépendantes d'une très petite communauté Open Source ?" Si les développeurs sont motivés ils adapteront l'application pour l'utilisation du bac à sable et l'activeront, dans le cas contraire cela ne changera rien.
avatar Faabb | 
Mes 2 centimes : Handbrake ne permet plus de ripper les dvd du commerce depuis la version 0.9.4/0.9.5 . Il est cependant toujours possible de ripper ses dvd de famille/non encryptés.
avatar liocec | 
@lmouillart : 'Juste un thread, niveau critique, qui boucle sur lui même... sans écouter ton CTRL+ALT+SUPR" HKEY_LOCAL_MACHINESystemCurrentControlSetControlPriorityControl Win32PrioritySeparation à configurer suivant ce que tu souhaite.' Que de mauvaise foi ! Tu te recomptes qu'il te faut rentrer dans les registres et paramétrer une clé pour protéger windows, donc à l'évidence sans ta manip, ce n'est pas protégé.
avatar liocec | 
@lmouillart : '"Je peux t'affirmer qu'un simple fichier et hop on place un hook sur ta machine, on utilise ton email ou le web pour transmettre des données."=> idem sur OS X ou n'importe quel système qui n'est pas très sécurisé.' On ne parle que de se que l'on a testé : tu prends un Mac avec Lion ou snow, produit neuf, tout juste déballé, et installes moi un hook clavier/souris sans taper le code admin. On fait la même démarche avec windows et on compare. Et tu verras que j'ai raison.
avatar liocec | 
@xatigrou : ' Et ça n'a rien d'évident ; il faut créer un processus noyau, sans quoi ton fameux thread sera éjecté une fois son quantum de 6ms terminé' C'est vrai que c'est plus difficile avec Seven ou les versions 64 bits, de prendre 100% de la machine, mais dès qu'on travaille avec les entrées/sorties de la machine, il y a beaucoup de processus bloquants, en particulier à cause de la volonté de MS de garder la compatibilité sur les anciens programmes.
avatar apenspel | 
Le SandBoxing, GateKeeper et le MAS, c'est Apple qui envoie ses clients jouer au bac à sable sur leurs propres bécanes en gardant leur carte de crédit car de toute façon en cédant au principe, ils ont prouvé qu'ils manquaient de totale maturité de gestion.
avatar lmouillart | 
@liocec démarrage en mode single, puis hop. C'est comme tous les OS, c'est livré out of the box avec certain parti pris au niveau de la sécurité. Sinon cela fait comme sur certaine ancienne distrib Linux : X pas autorisé, la quasi totalité des applications n'ont pas accès au réseau et tu as des tripotés de gens au support, donc tu ouvre les vannes et t'es tranquille.

CONNEXION UTILISATEUR