Rien compris!

Une session graphique sous Windows > Vista contient des processus avec des niveaux d''intégrités (IL) différents.
Une processus dit élevé a le plus haut niveau d’intégrité et dispose réellement des droits administrateurs.

La plupart des processus tournent en IL moyen et passe en IL haut via une élévation UAC.
Les navigateurs de Microsoft et celui de Google font tourner les plugins et autres générateurs de rendu dans une IL basse en plus d'une sandbox.

Comme les processus IL bas n'ont que très peu d'accès aux IL moyen et haut; il n'est pas possible à du code dans une sandbox IL bas de s'échapper via une shatter attack contre un processus IL moyen ou haut.
Windows empêche deux processus bash.exe de niveau IL différents de s’exécuter en même temps car le sous-système lxss ne connaît pas les IL (violation de layer) et ne peut pas empêcher un process IL haut d'être ptrace() par un process IL bas.
La réservation de la WindowsStation0 aux services (kikou UI0Detect) et la création du conhost.exe pour retirer l’accès graphique à crss.exe de la WindowStation active ont été fait pour la même raison.
 
C'est plus clair?

Comme les processus IL bas n'ont que très peu d'accès aux IL moyen et haut; il n'est pas possible à du code dans une sandbox IL bas de s'échapper via une shatter attack contre un processus IL moyen ou haut.

Ta page WP, c'est de la merde. Ils décrivent IL comme barrière de sécurité dans Vista alors qu'à la sortie de Vista MS a bien précisé que si un contournement de l'UAC était trouvé il ne serait pas considéré comme une faille, donc ta page est la propagande mensongère pro-MS.

D'ailleurs l'informatique, la plupart du temps, c'est de la...

Tu confonds tout !

Content de l'apprendre.

Cela confirme que Windows est totalement incompréhensible et donc non sûr.

Integrity Level est un mécanisme de securité qui ne dépend pas d'UAC (il fonctionne même avec UAC désactivé) et de toute façon la page WP parle de User Interface Privilege Isolation (UIPI).
Ce sont des mécanismes complèmentaires.

Donc une faille dans l'UAC n'est pas une faille dans IL?

Très drôle.

Et Microsoft précise dans la page que j'ai linké (que tu aurais du lire) qu'ils considèrent IL comme un mécanisme de securité et ils ont déjà patché des failles dedans.

Et bien ils peuvent considérer que c'est un mécanisme, mais dans Vista on pouvait se demander si c'était une barrière de sécurité. En tout cas ils ont bien manipulé tout le monde avec un truc qui demande confirmation et donc TOUT LE MONDE considère a priori comme un contrôle de sécurité alors qu'en fait officiellement c'était une manière d'emm... l'utilisateur.

Difficile de prendre au sérieux Windows et MS après ça.

Au passage, Microsoft est en train de patcher les UAC bypass dans Windows 10 petit à petit.
Un bash.exe elevé via UAC et ayant un IL haut pouvait être manipulé par un bash.exe ayant un IL médium ou bas (c'était le cas dans build insiders encore recement).
Cela parce que bash.exe est une interface à un sous système qui n'est pas Win32 et qui ne connait pas les IL (ce n'est juste pas disponible à ce niveau dans le kernel).
Donc au lieu d'écrire des hacks baveux violant le layering du kernel Windows (et on sait ce qu'ont donnée les dernières violations de layer dans le kernel Windows (crash des drivers graphiques, failles de sécurité dans la gestion des polices, ...)), bash.exe (et son interface COM) ne se lance pas dans cette situation. Du code non exploitable est du code qui ne tourne pas après tout.

Beurk.

Et oui, cela peut aussi t'arriver d'avoir tort

Je maintiens que c'est une subtilité sémantique formelle.

L'UAC est l'interface principale qui permet à l'utilisateur de manipuler les IL. C'est comme si tu me disais "contrairement à ce que tu dis, la colonne de direction de la voiture est fiable; en revanche, le volant n'est pas opérant".

C'est l'UAC qui permet d'autoriser ou d'interdire des opérations. C'est ce mécanisme qui emm... les utilisateurs afin de leur faire croire qu'ils sont protégés, comme les files d'attentes dans les aéroports qui n'ont pour but que d'humilier les passagers pour leurs faire croire à l'Etat fort et à la sécurité des contrôles (qui sont des passoires d'après toutes les simulations effectuées).

Si l'UAC autorise plus que ce qui est explicitement indiqué, c'est bien une faille du mécanisme UAC/IL. L'UAC fait parti de Windows Visa, on ne parle pas de composants indépendants et interchangeable. L'UAC a été introduite pour manipuler de façon simple les IL.

Il existe la possibilité de compiler et d'utiliser linux sans GNU, et GNU sans linux, et donc tu peux parler de faille spécifique à GNU. Mais linux vient avec des utilitaires spécifiques à linux, qui n'ont de sens que sur linux. Une faille dans un tel utilitaire serait un faille linux même si ce n'est pas une faille du noyau.

Si l'UAC n'est même pas une barrière de sécurité, c'est manifestement que toute l'architecte du machin est bousesque.

Heureusement,ce n'est pas parce que tu ne comprends pas quelque chose que c'est le cas de tout le monde.

J'espère que tu ne vas pas soutenir que l'immense majorité des utilisateurs ne croit pas que UAC n'est pas une barrière de sécurité.

Et non
Je zappe le reste de ton texte car ton erreur est à la base.

Une imprécision plus qu'une erreur.

Tu as raté ce que j'ai écris: les IL fonctionnent même avec UAC désactivé (le AlwaysOff).

Les IL continuent à avoir un intérêt; ils servent à augmenter la sécurité des sandbox IE, Chrome, Office, Edge, Adobe Reader, etc en empêchant les shatter attack...

Ne joue pas sur les mots, l'UAC dont il est question ici ne concerne pas les sandbox qui sont surbaissées mais les processus d'installation de programmes et autres qui sont surélevés.

Bien sûr qu'il y a un intérêt à avoir un bac à sable garanti par des permissions au niveau du noyau.

Les sandbox surbaissées sont programmées dans les logiciels et l'utilisateur n'a rien à faire, d'ailleurs la plupart du temps il ne sait même pas que certains processus de Google Chrome ont des permissions inférieures : il peut toujours déposer n'importe où un fichier téléchargé, sans passer par l'UAC.

En revanche, dès qu'un utilisateur qui est administrateur tente de modifier un fichier auquel il n'a pas accès, il a le droit à une série ridicule de confirmation UAC (alors qu'il serait simple de faire une seule confirmation : voulez-vous une fenêtre gestion de fichier avec privilèges admin).

Dans ce cadre, fonctionnellement, il reste 2 niveau d'IL; bas dans les sandbox et haut dans le reste.

CQFD

Mais pourquoi tu continue à me parler d'UAC ?
On a commencé le débat parce que Microsoft a viré la possibilité d'avoir au sein de la même session deux instance WSL avec des IL différentes et j’expliquai pourquoi c'est normal dans l'architecture de sécurité Windows.