Une faille 0-day a été découverte dans le noyau Linux. Les distributions pour ordinateurs travaillent déjà sur la création de correctifs qui devraient être diffusés très prochainement. La question se pose par contre pour Android, également concerné et pour qui la situation sera plus complexe.
La faille a été rapportée initialement la semaine dernière par la société Perception Point, mais l’information n’arrive réellement sur le devant qu’aujourd’hui. Tous les détails viennent en effet d’être publiés, permettant aux pirates de se jeter sur les informations qui leur permettront potentiellement d’en créer des exploitations.
Cette vulnérabilité 0-day touche le noyau Linux et s’est vu attribuer la référence CVE-2016-0728 (le bulletin est réservé, mais vide pour l'instant). Elle existe depuis 2012, avec l’arrivée de la version 3.8. Elle permet une escalade locale des privilèges et peut être exploitée si un malware sait où chercher. La faille en elle-même est entourée d’une certaine ironie car elle réside dans un mécanisme de sécurité, à savoir le stockage des clés d’authentification et de chiffrement pour les pilotes.
Les correctifs sont en préparation
Interrogé par le site Data Breach, le PDG d’Interception Point, Yevgeny Pats, indique que rien ne montre pour l’instant que la faille ait déjà été exploitée. Cependant, la remarque vaut uniquement jusqu’à aujourd’hui, car il explique lui-même qu’avec les détails de cette faille, les chercheurs auront eux aussi une idée beaucoup plus précise de ce qu’il faut chercher. Quoi qu’il en soit, l’équipe de développeurs du noyau Linux est déjà au courant, de même que des entreprises comme SUSE et Red Hat, dont Pats loue la « très, très grande réactivité ».
Facteur limitant, la faille n’est a priori pas exploitable à distance. Un pirate doit donc avoir accès à la machine pour exécuter du code. Mais l’exploitation, si elle a lieu, peut donner les droits root à un processus tiers. À partir de là, un malware peut sans problème créer une connexion depuis laquelle un pirate pourra contrôler la machine. L’exploitation peut se faire également en récupérant un binaire vérolé. On notera cependant que les mécanismes de sécurité Supervisor Mode Execution Protection et Supervisor Mode Access Prevention (SMEP et SMAP) rendent cette exploitation plus difficile.
Le cas Android
Sur Android cependant, la situation est plus complexe, car les téléchargements d’applications y sont monnaie courante. Là encore, l’exploitation sera rendue plus difficile (mais pas impossible) par la présence d’un mécanisme, SELinux, mais ce dernier n’est arrivé dans Android qu’à partir de la version 4.3. Ici, malheureusement, les politiques de support autour d’Android jouent contre les utilisateurs.
Les versions antérieures à 4.3 représentent encore un bon tiers des appareils en circulation, ce qui fait dire à Perception Point qu’en tenant compte de la date d’arrivée du bug dans le noyau Linux, 66 % des appareils en circulation sont vulnérables. Interrogé par Data Breach, Google n’a pas encore réagi sur ce point, mais le processus est toujours le même : l’entreprise prépare un correctif, qui sera ensuite fourni aux constructeurs.
Mais ce sont bien ces derniers qui décident en dernier recours du déploiement sur leurs smartphones et tablettes, et on a pu voir avec le faille Stagefright que 90 % des appareils n’étaient pas mis à jour, seules les versions récentes d’Android recevant des correctifs.
Commentaires (144)
La plupart des appareils Android sont directement passés de la version 3.4 à la version 3.10 du noyau avec l’arrivée de Lollipop. Je ne pense pas que la question se pose pour Android 4.x.
Bien lire le titre ;) la faille est apparue avec la version 3.8 de Linux et n’a pas été corrigée à ce jour. La version 3.10 est donc aussi concernée.
Ouch.
Oui, je n’ai pas dit le contraire.
Après vérification certains téléphones en version 4.4 disposent d’un noyau 3.10.
Heureusement que l’exploitation de cette faille requiert un accès physique
" />
Déjà patché dans Ubuntu. J’imagine qu’il en est de même dans les autres distros.
“La faille en elle-même est entourée d’une certaine ironie car elle
réside dans un mécanisme de sécurité, à savoir le stockage des clés
d’authentification et de chiffrement pour les pilotes.”
Je me demande si cela a un lien avec les divers blob que le noyau officiel autorise ? (mais bon ce n’est que de la spéculation)
“ la faille n’est a priori pas exploitable à distance. Un pirate doit donc avoir accès à la machine pour exécuter du code”
Donc peut de chose a craindre pour les entreprises qui ont des locaux fermée.
” 90 % des appareils n’étaient pas mis à jour, seules les versions récentes d’Android recevant des correctifs.”
Cela ne serez pas le cas pas si android était sous licence Gpl :danse:danse:
Effectivement, patch en attente sur debian.
" />
Reste la faille la plus importante non corrigée à ce jour : l’interface siège-clavier
Bof. Puisque ça requiert un accès à la machine, la surface d’attaque est quand même limitée.
L’accès “local” pour Linux est différent de l’accès “local” pour windows, un shell est un accès local. Si un attaquant a accès a un shell, il peut exploiter la faille.
Corrigé sur Jessie. Sur la branche Testing (stretch, c’est OK sur sid), il faut attendre que la nouvelle version du noyau soit mûre (à priori d’ici 5-6 jours)
Merci pour l’info, j’avais pas vu sur ce canal. Je vais patienter tranquillement pour les serveur web en prod. Mais cette faille ne les concerne pas, sauf à une intrusion dans le data center 
" />
" />
apt-get update && apt-get -y upgrade
Idem, patché également aujourd’hui.
Espérons que le patch pourra se répandre rapidement ! Sur les PC ça devrait pouvoir se faire rapidement, par contre sur Android ça risque d’être plus lent, voire ne pas arriver du tout sur certains terminaux…
Je pense que par accès on veut dire la capacité d’exécuter du code arbitraire sur le serveur. Donc une faille web qui pourrait donner accès à un shell en www-data par exemple pourrait avec cet exploit mener à une compromission totale du serveur. Cette faille est donc loin d’être négligeable.
Rappel : un accès “local” sous linux = accès a un shell, qu’il soit bash, sh, whatevershell, en ssh, ou accès clavier/souris, c’est la même chose, parce que rappel, Linux est multiseat, multiutilisateurs. En conséquence, je vais donner le bête exemple d’un xen mal sécurisé qui laisse accès a ses shells, ben c’est la même chose. Il faut avoir accès au shell, et les failles intrinsèques des shells sont suffisantes pour une élévation des privilèges d’un coté, et de l’autre exploiter cette faille (qui elle permet de modifier le comportement kernel pour masquer d’autres failles utilisées).
Mais SELinux est censé bloquer cette intrusion, d’après la news ?
" />
Je pense aux serveurs pour lesquels cette faille n’est peut-être pas anodine ?
Reste qu’il faut se pointer chez moi et piquer les clés privées SSH que j’utilise pour accéder aux machines (login SSH par MdP désactivé - pas fou)
" />
Attention Ricard car apparemment tu ne sembles pas au courant du fonctionnement de la version “testing” de Debian.
Il y a 3 versions de Debian :
Contrairement a ce que certain pourrai croire, la version testing est en faite la version la moins sécurisé de Debian (derrière la Sid).
En terme de sécurité : Stable > Sid > Testing
En terme de fiabilité : Stable > Testing > Sid
En terme d’évolution des logiciels : Sid > Testing > Stable
A noté que la version Sid est a éviter dans les environnements de production car c’est aussi dynamique qu’une ArchLinux.
Pour Android, je ne comprend pas que les constructeurs ne se laissent pas un accès via le store pour ce genre de patch….
je savais que linux n’était pas sur!!
j’ai jamais regardé mes comptes bancaires avec ce truc.
de toute façon ça marche pas sur iphone.
Merci Google pour cette bouse d’Android complètement abandonnée versions après versions…
Une tablette d’un grand fabricant de moins de deux ans est quasi bonne pour la poubelle….
Parcequ’ils poussent à l’achat d’une tablette neuve… c’est du consommable !
Semble pas tres efficace comme exploit…
[desmopro@archpc vul]\( ./cve\_2016\_0728 PP1
uid=1000, euid=1000
Increfing...finished increfing
forking...finished forking
caling revoke...
uid=1000, euid=1000
sh-4.3\) whoami
desmopro
SELinux ou pas j’arrive pas à reproduire, ça bloque :
uid=1000, euid=1000Increfing…
Ce serait pas mitigé par les CGroups aussi par hasard ?
Pas fan de la pomme, mais il me semble qu’Apple est un dérivé de UNIX (un fork quoi) tout comme Linux
Effectivement (ce soir 19/01/2016 à 20h00) :
Allez un petit reboot, parce qu’on n’en est pas encore au kernel patchable-en-live (ça vient !) un des deniers cas où on a vraiment à rebooter pour prendre en compte une modification, contrairement à d’autres O.S. !
Je suis en stable, et j’ai la mise à jour du kernel.
" />
Pendant ce temps, GNU/Hurd n’est pas touché.
" />
Rien pour l’instant sur Mageia.
Ca prend un bout de temps, de mon cote il a fallut 25 minutes avec un 4770k (100% d’un core constant).
question con, sur ma debian, après mon apt-get upgrade, je reboot ou pas pour que la maj soit prise en compte?
_commit_creds commit_creds = 0xffffffff81094250;
_prepare_kernel_cred prepare_kernel_cred = 0xffffffff81094550;
/* Addresses of commit_creds and prepare_kernel_cred functions are static and can be determined per Linux kernel version/android device.
*/
J’allais la faire, puis je me suis souvenue qu’un ou deux INpactiens l’utilise
" />
Pour une mise à jour du noyau le reboot reste encore nécessaire pour démarrer sur le nouveau.
Le patch à chaud n’est pas encore en service il me semble, et d’ailleurs je me demande si ce genre de chose fera partie du périmètre car j’avais cru comprendre que la fonctionnalité restera assez limitée.
Faudra voir comment s’en sort Blackberry sur le suivi des MAJ Android et anciennes versions. Pour le moment j’arrive pas à savoir s’ils vont faire comme “tout le monde” ou proposer un vrai suivi dans le temps
" />
Thanks ;)
Au passage sur Raspbian Jessie, la maj n’est pas encore dispo.
MaJ du noyau, oui il faut rebooter.
La branche 4.0 permet des mises à jours “à chaud” du noyau, mais ça n’empêche pas de redémarrer pour être sûr que tous les logiciels prennent bien en compte la nouvelle version
EDIT : demi-grillé
Il faut plus de 20 minutes pour exécuter la chose, il faut faire 2³² appels kernel…
Le noyau Raspbian suit un rythme bien particulier
" /> (il est en 4.1.15 aux dernières nouvelles - testé fin décembre)
Question con : on peut patcher ca avec Xposed ?
Pas encore sur les backports (je suis en kernel 4.3 backports). Je l’attends avec impatience (ça ne devrait pas tarder après la testing)
J’ai eu aussi un kernel panic, je retente la chose pour voir si j’arrive à reproduire…
J’espère que tu as pensé à modifier les constantes pour les adresses kernel… Car sinon c’est un peu normal d’avoir un kernel panic
Perso j’ai rajouté une barre de progression…
Je dois encore rate quelque chose, ou avoir un systeme patche (comment?), parceque meme en changant ca, je reste toujour sur mon compte standard.
Oui j’ai édité le code, jamais exécuter ce genre sans regarder un minimum ce que ça fait, sinon
" />
Un p’tit coup de sudo rpi-update de temps à autre pour mettre le bousin à jour et le tour est joué. (une fois par mois, quand on y pense
" /> )
l’intall à 3 jours…. il pourrais mettre à jours leurs images sur le site du raspi…. :/
" />
Maj en cours du coup
Je ne suis pas d’accord car si la licence GPL était mis en place, google ou n’importe quelle autre constructeur n’aurait pas le droit de bloquer quoi que ce soit, la GPL version 3 protege de ce genre d’abus c’est exactement le probleme qu’il y a eu avec le tivo (Tivoisation) et c’est pourquoi la GPLv3 fut créer et c’est aussi l’une des raison que le noyau linux reste sous GPLv2, car si c’était le cas (que le kernel sois sous GPLv3) Samsung Google ou autre pourrait se faire poursuivre en justice.
https://fr.wikipedia.org/wiki/Tivoisation
je rapelle que la GPL protège les utilisateurs avec quatres règles très simple:
-Le droit d’exécuter le programme.
-Le droit d’étudier et modifier le programme sous forme
de code source.
-Le droit d’en redistribuer des copies exactes.
-Le droit d’en redistribuer
des versions modifiées.
Et les constructeur viole une règle si le kernel était sous GPLv3 (Le droit d’étudier et modifier le programme sous formede code source)
TL;DR je sais je fais chier.
J’ai enfin “”“réussi”“” à aller jusqu’au bout en bootant sur openRC à la place de systemD, mais niet quand-même :
uid=1000, euid=1000
Increfing…finished increfing
forking…finished forking
caling revoke…
uid=1000, euid=1000
sh-4.3\( whoami maxime
sh-4.3\) touch /test
touch: impossible de faire un touch « /test »: Permission non accordée
sh-4.3$
Chiant ce bug de NXi avec les sauts de ligne en italique
J’obtiens un “disk quota exceeded”. Ca marche super leur truc…
" />
Je viens de comprendre pourquoi j’ai un kernel panic, c’est une sécurité du kernel : SMEP
Voirhttps://lwn.net/Articles/517475/
J’ai ceci dans les logs : unable to execute userspace code (SMEP?) (uid: 1000)
Le kernel se protège et il est interdit d’exécuter du code userspace depuis le kernel, et c’est exactement ce qu’essaye de faire le code
Donc si je ne dis pas de bêtise sur mon PC ce bug n’est pas possible à reproduire.
Et non !
Xposed peut (en gros) patcher des appels / fonctions Java dans les applications ou le système Android.
Il ne touche pas du tout au noyau Linux du système et donc ne pourra rien faire =/
“Oui, Android aussi”
Félicie, aussi
Ca fait toujours une possibilité de DOS, pas glop
" />
Si tu passe par un mandataire (proxy, reverse pour accéder a ta machine parce que pas d’ip fixe/DMZ merdique) c’est plausible que tes clés passent en clair, le tunnel ne commençant qu’une fois sur la zone WAN. La solution est de faire initier la connec par port knocking mais côté de ton serveur. Ta clé privé ne transitant pas dans ce cas. En gros, vaut mieux que ton serveur vérifie le ash, plutôt que tu lui envoie le sha.
" />
M’enfin on entre dans des cas assez capilotractés pour le coup et sont difficile a réunir pour choper de la clé. (pas impossible mais difficile, faudrait t’inciter a te logger en passant sur un proxy pipoté. Possible a faire sur des bornes wifi publique, vue que ça broadcast a mort, mais pas déconnant de remplacer une antenne, ou installer un sniff sur une borne de sortie dans des endroits que tu aime bien utiliser.)
Et sinon, reste la solution de l’effraction chez toi et de te menacer avec un annuaire du 18e. Mais dans ce cas, y’a mieux que de poser ce genre de failles. Coller un VPN dans ta box est plus discret et moins détectable.
L’annuaire du 18ème n’est pas si épais (j’y ai habité)
" />
" />
Nan, ça va j’ai accès direct aux machines (une par réseau local et l’autre à IP fixe). Par contre je note pour les fois où je serais sur du réseau pourri
hum il me semble voir colère dans ton poste mais bon…
(les chinois ça ne m’étonne pas j’arrive toujours pas daillieur a comprendre pourquoi on continue de commercer avec une dictature) Si les américain et euro se foute de la licence Torval aurait passer le noyau linux sous GPLv3 depuis longtemps enfin je dis ça, aurait tu des infos pour corroborer tes dires ?.
Lorsque tu dis c’est contournable sans problème tu parle de la licence GPL ou des téléphone ?
Et si c’est bien les téléphones je te dit et alors ? un constructeur na pas a limiter volontairement (désigne sans vis etc…) les possibles modification d’un appareil au consommateur, si je veut changer de batterie cela doit être accessible directement, si je n’ai pas envie d’avoir tout les crapware de google et compagnie je veut pouvoir les désinstaller en cliquant sur désinstaller.
Un utilisateur lambda a déjà du mal a savoir ce qu’est un navigateur tu le vois rooter son téléphone ou installer replicant?
Ce que font les constructeurs c’est de l’abus de position dominante est cela créer des logiciels avec de mauvaise intention, des logiciels non securisable, des utilisateurs de plus en plus ignare, des déchets via obsolescence programmer, une consommation d’énergie plus élever et j’en passe.
pour les rom non flashable il y a toujours des malins qui arrivent a contourner ca ^^
https://libreboot.org/docs/install/t400_external.html
Merci
Bizarre, sur mon OnePlus One sous la dernière nightly Cyanogenmod 12.1 (Android 5.1.1), la version du noyau n’est que 3.4.110…
Non, Linux n’est pas un dérivé d’UNIX mais un clone.
Rappel : SElinux développé majoritairement par la NSA ….
" />
Ne mettez pas SELinux, c’est une merde pour vous espionner !
https://www.nsa.gov/research/selinux/
https://www.nsa.gov/research/selinux/faqs.shtml
Et pour ceux qui ont Android > 4.3
“Sur Android cependant, la situation est plus complexe, car les téléchargements d’applications y sont monnaie courante. Là encore, l’exploitation sera rendue plus difficile (mais pas impossible) par la présence d’un mécanisme, SELinux, mais ce dernier n’est arrivé dans Android qu’à partir de la version 4.3. Ici, malheureusement, les politiques de support autour d’Android jouent contre les utilisateurs.”
vous êtes mouquer !
Pour les curieux, la correction est ici:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=23567…
Bizarre, mon Sony Xperia Z3 est sous Androïd 5.1.1 et a comme noyau : 3.4.0-perf-gbe52486
D’où sort ton 3.10 sous Kitkat ?
Coluche: “Il parait que Sheila a encore fait des progrès. ça fait des années qu’elle fait des progrès. Moi j’attends qu’elle ai fini pour l’écouter”.
La même avec Linux, depuis le temps que c’est mieux que Windows et que ça s’améliore grâce à sa philosophie…
Non sérieusement, je compte bien réessayer Linux, mais je pense attendre encore que sa Michuisation soit améliorée. On a tous en nous une part de Michu.
Pour revenir à l’actu, pas mieux que les autres: aucun espoir de voir la faille corrigée sur les wiko ou les archos…
Y’a t’il une raison pour ne pas mettre à jour le noyau ? Trop de boulot peut-être ?
Perso j’ai installé une distri Unbutu chez un pote pour en faire un machine multi fonction sous la TV avec un vieux ordi (apres avoir rajouté un CG nv et un clavier sans fil). Ça marche pas mal (mieux qu’avec steamos qui gère assez mal les fonctions multi média).
A noter que le streaming local marche super bien avec le mode “big picture” (avec son gros pc à l’autre bout de la maison qui sert de serveur)
MAIS je suis désolé mais c’est quand même bien moins userfriendly qu’un windows !
Exemple, mon pote veux du son 5.1 (assez mélomane et le son par CM, ça lui va pas), achète une carte Creative et là c’est le drame ! Impossible que le système trouve la carte, il faut aller chercher un pilote puis changer en ligne de code etc….
Il s’est pris la tête, il m’a appelé, je me suis pris la tête et ça marche pas !
Bref, la carte est dans le pc, mais sans être vu par le système….
Sous window$, je branche, j’installe le pilote ça marche !
Par curiosité, c’est quelle carte exactement ?
“Ou pas selon ta version de windows et le support ou non du matériel pour ta version de Windows. “Oui enfin il faut pas tomber dans la mauvaise fois, linux c’est très bien mais le support matériel user friendly (sans ligne de code pour résumer) est très, TRES en dessous d’un windows récent… 
" /> 
" />
Et oui, figure toi, les gens achètent leurs matériels sans regarder si c’est compatible sous windows, car à de très rares exceptions près, c’est le cas. Tu en doutais, ou tu as volontairement pris tous les exemples les moins pertinents plutôt que celui là ?
Il faut mettre à jour le programme avec les adresses de ton noyau sinon c’est normale que cela ne marche pas.
Pour vérifier si il faut rebooter après un upgrade, il suffit de regarder si tu as un fichier vide appelé reboot_required dans /var/run. C’est le cas pour cette MàJ.
celle-ci :http://www.ldlc.com/fiche/PB00157402.html
Sinon
ok je note ne plus utiliser de Carte son Creative, ( quand meme les ex-leaders quoi) mais xonar. Mon pote va étre super content d’avoir fout en l’air 40€…
Apres t avouera quand meme que madame Michun va pas aller vérifier si l’imprimane Canon qu’elle viens d’acheter est compatible ou pas…. D’ailleurs pour Madame Michun, tout est compatible
Xonar pas de drivers officiel asus non plus, tu a des pilotes libre fonctionnel par contre, enfin pour les fonctions de base, sur une xonar DSX quand on branche un casque sur le front, la carte coupe bien les sortie arrière mais ne démute pas le casque, obliger de lancer alsamixer pour démute a chaque fois … ou alors il y a une manip ou une config que je n’ai jamais trouvée.
Dans tout les cas va faire un tour pour voir la compatibilité ici :
http://www.alsa-project.org/main/index.php/Matrix:Vendor-Asus
Ouai enfin tu prends 2 cas ou l’écart entre le matériel est de 10 ans pas vraiment représentatif, les machines sous XP ne sont plus monnaie courante en france (hors entreprise ou la le problème des drivers n’existe pas) et à partir du moment ou le pilote existe sous 7 dans 99% du temps il sera la sous win 10.
Sur quasiment l’ensemble des périphériques, il y a quand même la mention “Systèmes d’exploitation pris en charge” dessus.
Sauf que :
Si tu utilises linux, on te dit que c’est la faute de linux.
Dans le cas de Mme Michu, on lui dit que c’est son PC (ou l’imprimante) qui est trop vieux, et qu’il faut en racheter un.
Déjà fait, t’a pas lu tous les comms toi ;)
d’ailleurs question subsidiaire pour une belle âme… Vous pensez que sa carte créative peut marcher et on a fait une fausse manip ou c’est foutu?
Après, je m’écarte grave de la news….
non c’est le tord de Creative en l’occurence… Mais bon c’est pas userfrienlit tout ça !
J’ai parlé de clés privé qui transitent ?
" />
J’ai parlé des clés qui passent par les mandataire (clé publique donc, enfin ash de clé publique). J’ai bien dit que les clés privées ne transitent pas. Mais c’est bien vrai que le serveur envoie un sha. Je décrit le challenge sha/ash, qui est défaillant dans un sens mais pas dans l’autre. Relit, avec le doigt. :)
(et si tu crois que je vais donner la solution exacte, parce qu’on parle quand même d’intrusion dans un réseau, passible de prison même sur un pentest “pour rire” dans le cadre privé.)
Oui
" /> : « La solution est de faire initier la connec par port knocking mais côté de ton serveur. Ta clé privé ne transitant pas dans ce cas. »
Et donc, sinon c’est quoi le problème avec les clés publiques qui transitent en clair ?
étonnant que win n’es pas un peu tousser… Je croyais que la clef licence était en fonction de la CM…. Tant mieux dans un sens
Cela dépend sûrement des distros mais je ne pense pas que linux soit capable d’installer des pilotes au démarrage du système et je ne suis pas sûr que windows soit capable de faire ça non plus.
Ce que linux arrive à faire c’est charger automatiquement les pilotes qui sont déjà installés. Comme il y a des tonnes de drivers installés de base sous linux, souvent compilés dans le noyau, ça marche plutôt bien lorsqu’on change de matos.
Oui pour ce qui est de la carte mère et du CPU, ça n’a jamais été un soucis sous Linux. Tu n’as rien a installe juste a rebooter ^^ . Ca n’a pas toujours été le cas sur les anciennes versions de Windows, tant mieux si les choses se sont améliorées.
Excellent, ce que linux sait faire.
Le début de mon commentaire était destiné aussi à ceux qui préfèrent NE PAS passer à Windows 10, soit disant que ça n’apporte rien mais que ça t’espionne.
Ils font des progrès (celui-ci peut-être déjà présent sous w8?), c’est leur marketing qui est naze.
J’ai eu l’occasion de tester un Win7 installé sur un HDD externe et il était capable de démarrer sans gros problèmes sur des machines au hardware sensiblement différent (modulo les périphériques “exotiques” ou trop récents dont les pilotes ne seraient pas dans l’install de base, et si c’est la carte réseau ou qu’on a pas d’accès au net sur la machine à dépanner c’est mort pour aller chercher ce qui manque sur WU mais il en serait tout autant avec Linux dans un cas similaire)
En fait le plus gros problème de Windows niveau “portabilité” c’est le principe même de l’activation liée au matériel : s’il y a trop de choses qui changent dans la config l’activation saute ce qui interdit quasiment son installation sur clé USB/HDD externe pour se faire une solution de dépannage portable par exemple (sauf utilisation de cracks plus ou moins fiables pour passer outre le système d’activation) mais bon ça c’est inhérent à un OS proprio payant qu’il faut ben trouver un moyen de protéger un minimum.
Avec Linux l’OS est libre et gratuit donc pas de système d’activation et pas de prise de tête : on compile un noyau avec la totalité des pilotes dispos en modules et ça roule sur à peu près n’importe quelle machine.
J’avais raté ça, m’enfin vu les limitations imposées le truc n’a pas grand intérêt.
Il y a quelques années j’avais récupéré un XP bricolé pour tourner sur une clé USB mais ça n’était si stable ni fiable mais les possibilités étaient bien plus étendues que ce Windows to Go
Étonnament, j’ai une vision différente de Canon:
Au début, il a fallu bien chercher (et parfois jouer avec les compatibilités pour installer le driver d’un modèle différent de l’imprimante que j’avais). Maintenant, il me semble que les distributions reconnaissent mon modèle qui existe depuis assez longtemps.