Question aux pro-UAC

MCI \(ex do ré Mi chel la si do\) [MVP]

06/01/2008 à 13:54

Bonjour à tous !

Après moult recherches, retour sur tout ce que j'avais expérimenté /
recherché pour RunLike, et après avoir lu vos réponses, je suis arrivé
aux conclusions suivantes :

- avec l'UAC activé, il est actuellement impossible d'avoir une
élévation automatique de privilège. Une intervention manuelle est
obligatoire, à chaque lancement d'un logiciel la nécessitant.

- Contrairement à ce que dit Microsoft, notamment là :
http://msdn2.microsoft.com/fr-fr/library/aa905330.aspx#wvduac_topic6
il arrive souvent que l'UAC ne détecte pas les installations, qui
sont alors lancées avec un niveau de privilèges insuffisant. De même,
l'UAC se trompe souvent sur l'identification de programmes (il confond
souvent documents et programmes). De plus, il ne sait pas gérer
convenablement les logiciels dynamiques, , ou ceux qui utilisent une
machine virtuelle. Dans ces cas là, c'est "tout ou rien", tous les
logiciels sont élevés, ou aucun.
De plus, les processus enfants n'héritent pas toujours du niveau
de privilège du parent. Dès fois, ça marche, des fois non.

- les fichiers manifest, ce n'est pas une solution intéressante. En
pratique, elle ne s'applique qu'aux exécutables simples, programmés en
statique, essentiellement avec les outils de Microsoft. Prenez le cas de
programmes utilisant une machine virtuelle (par exemple, les batchs, qui
utilisent cmd.exe ou command.exe) ;
soit vous définissez un fichier manifest pour chaque batch, ce
qui va vite en faire plusieurs centaines, d'une taille souvent
supérieure, et pénibles à manipuler ;
soit vous définissez un fichier manifest pour cmd.exe ; et alors
TOUT ce qui lancé par cmd.exe va utiliser le même manifest. Sans
possibilités de choix. Ce qui enlève tout intérêt au principe.
Les fichiers manifest utilisent XML ; ce qui entraîne une
débauche de moyens, pour gérer 3 ou 4 informations textuelles. D'où
perte de place, et ralentissements. En plus, il s'agit de XML 1.0 ; je
ne suis pas sûr du tout que Vista suive, si on utilise un fichier XML
1.1 (je rappelle qu'une des caractéristiques de XML 1.1, c'est la
possibilité d'utiliser d'autres langues que l'anglais dans les tags ;
plus exactement, d'autres alphabets que l'ASCII).
Bref, pour moi, les fichiers manifest, ce n'est qu'une lourdeur
(de plus) sans intérêt.

Au final, même si on veut travailler avec l'UAC, on est strictement
limité à une utilisation simpliste de Windows, avec beaucoup trop de
limitations fonctionnelles.
Donc, je confirme ma position : IL FAUT DESACTIVER L'UAC PAR DEFAUT !
L'UAC devrait être réservé à certains postes sensibles, ou ayant des
utilisateurs inconséquents ; mais il faut le désactiver sur l'immense
majorité des postes de travail. En fait ce serait un excellent outil,
si, à l'installation de Windows, la question était posée : "voulez-vous
activer ou non l'UAC ?"

Et puis, un truc, pour rassurer les utilisateurs de Windows : si vous
utilisez Ubuntu, le même problème existe sur cet OS : il est quasi
impossible d'automatiser quoique ce soit, car des validations manuelles
à tout bout de champ.
Si ça continue, on finira par n'utiliser plus que des serveurs...

@-salutations

Michel Claveau

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour à tous !

Après moult recherches, retour sur tout ce que j'avais expérimenté /
recherché pour RunLike, et après avoir lu vos réponses, je suis arrivé
aux conclusions suivantes :

- avec l'UAC activé, il est actuellement impossible d'avoir une
élévation automatique de privilège. Une intervention manuelle est
obligatoire, à chaque lancement d'un logiciel la nécessitant.

- Contrairement à ce que dit Microsoft, notamment là :
http://msdn2.microsoft.com/fr-fr/library/aa905330.aspx#wvduac_topic6
il arrive souvent que l'UAC ne détecte pas les installations, qui
sont alors lancées avec un niveau de privilèges insuffisant. De même,
l'UAC se trompe souvent sur l'identification de programmes (il confond
souvent documents et programmes). De plus, il ne sait pas gérer
convenablement les logiciels dynamiques, , ou ceux qui utilisent une
machine virtuelle. Dans ces cas là, c'est "tout ou rien", tous les
logiciels sont élevés, ou aucun.
De plus, les processus enfants n'héritent pas toujours du niveau
de privilège du parent. Dès fois, ça marche, des fois non.

- les fichiers manifest, ce n'est pas une solution intéressante. En
pratique, elle ne s'applique qu'aux exécutables simples, programmés en
statique, essentiellement avec les outils de Microsoft. Prenez le cas de
programmes utilisant une machine virtuelle (par exemple, les batchs, qui
utilisent cmd.exe ou command.exe) ;
soit vous définissez un fichier manifest pour chaque batch, ce
qui va vite en faire plusieurs centaines, d'une taille souvent
supérieure, et pénibles à manipuler ;
soit vous définissez un fichier manifest pour cmd.exe ; et alors
TOUT ce qui lancé par cmd.exe va utiliser le même manifest. Sans
possibilités de choix. Ce qui enlève tout intérêt au principe.
Les fichiers manifest utilisent XML ; ce qui entraîne une
débauche de moyens, pour gérer 3 ou 4 informations textuelles. D'où
perte de place, et ralentissements. En plus, il s'agit de XML 1.0 ; je
ne suis pas sûr du tout que Vista suive, si on utilise un fichier XML
1.1 (je rappelle qu'une des caractéristiques de XML 1.1, c'est la
possibilité d'utiliser d'autres langues que l'anglais dans les tags ;
plus exactement, d'autres alphabets que l'ASCII).
Bref, pour moi, les fichiers manifest, ce n'est qu'une lourdeur
(de plus) sans intérêt.

Au final, même si on veut travailler avec l'UAC, on est strictement
limité à une utilisation simpliste de Windows, avec beaucoup trop de
limitations fonctionnelles.
Donc, je confirme ma position : IL FAUT DESACTIVER L'UAC PAR DEFAUT !
L'UAC devrait être réservé à certains postes sensibles, ou ayant des
utilisateurs inconséquents ; mais il faut le désactiver sur l'immense
majorité des postes de travail. En fait ce serait un excellent outil,
si, à l'installation de Windows, la question était posée : "voulez-vous
activer ou non l'UAC ?"

Et puis, un truc, pour rassurer les utilisateurs de Windows : si vous
utilisez Ubuntu, le même problème existe sur cet OS : il est quasi
impossible d'automatiser quoique ce soit, car des validations manuelles
à tout bout de champ.
Si ça continue, on finira par n'utiliser plus que des serveurs...

@-salutations

Michel Claveau

Phil

06/01/2008 à 16:23

Merci Michel,
Ca confirme ce que l'on pressentait.
Ta réponse à l'avantage de la clarté.

Pour moi, particulier avec un boitier internet en mode routeur et un réseau
local sur des adresses IP non routables (192.168. ...) la protection restera
du ressort de :
- la translation d'adresse faite par la crétinBox
- le pare-feu de l'OS
- l'anti-virus
et bien évidemment la protection physique de mon domicile et des règles de
prudence évidentes :
* poubelliser tout mail douteux,
* ne pas installer tous les softs en beta "juste pour voir",
* éviter les softs gratuits trouvés dans les magazines,
* gérer des sauvegardes des documents précieux : photos, carnets
d'adresse
* mettre à jour l'antivirus quotidiennement
* mettre à jour windows régulièrement
* conserver les logiciels achetés en lieu sur sur CD ou DVD

Jean Passe et D Meyer

Phil

"MCI (ex do ré Mi chel la si do) [MVP]" a
écrit dans le message de news:%

Bonjour à tous !

Après moult recherches, retour sur tout ce que j'avais expérimenté /
recherché pour RunLike, et après avoir lu vos réponses, je suis arrivé aux
conclusions suivantes :

- avec l'UAC activé, il est actuellement impossible d'avoir une
élévation automatique de privilège. Une intervention manuelle est
obligatoire, à chaque lancement d'un logiciel la nécessitant.

- Contrairement à ce que dit Microsoft, notamment là :

http://msdn2.microsoft.com/fr-fr/library/aa905330.aspx#wvduac_topic6
il arrive souvent que l'UAC ne détecte pas les installations, qui
sont alors lancées avec un niveau de privilèges insuffisant. De même,
l'UAC se trompe souvent sur l'identification de programmes (il confond
souvent documents et programmes). De plus, il ne sait pas gérer
convenablement les logiciels dynamiques, , ou ceux qui utilisent une
machine virtuelle. Dans ces cas là, c'est "tout ou rien", tous les
logiciels sont élevés, ou aucun.
De plus, les processus enfants n'héritent pas toujours du niveau de
privilège du parent. Dès fois, ça marche, des fois non.

- les fichiers manifest, ce n'est pas une solution intéressante. En
pratique, elle ne s'applique qu'aux exécutables simples, programmés en
statique, essentiellement avec les outils de Microsoft. Prenez le cas de
programmes utilisant une machine virtuelle (par exemple, les batchs, qui
utilisent cmd.exe ou command.exe) ;
soit vous définissez un fichier manifest pour chaque batch, ce qui
va vite en faire plusieurs centaines, d'une taille souvent supérieure, et
pénibles à manipuler ;
soit vous définissez un fichier manifest pour cmd.exe ; et alors
TOUT ce qui lancé par cmd.exe va utiliser le même manifest. Sans
possibilités de choix. Ce qui enlève tout intérêt au principe.
Les fichiers manifest utilisent XML ; ce qui entraîne une débauche
de moyens, pour gérer 3 ou 4 informations textuelles. D'où perte de place,
et ralentissements. En plus, il s'agit de XML 1.0 ; je ne suis pas sûr du
tout que Vista suive, si on utilise un fichier XML 1.1 (je rappelle qu'une
des caractéristiques de XML 1.1, c'est la possibilité d'utiliser d'autres
langues que l'anglais dans les tags ; plus exactement, d'autres alphabets
que l'ASCII).
Bref, pour moi, les fichiers manifest, ce n'est qu'une lourdeur (de
plus) sans intérêt.

Au final, même si on veut travailler avec l'UAC, on est strictement limité
à une utilisation simpliste de Windows, avec beaucoup trop de limitations
fonctionnelles.
Donc, je confirme ma position : IL FAUT DESACTIVER L'UAC PAR DEFAUT !
L'UAC devrait être réservé à certains postes sensibles, ou ayant des
utilisateurs inconséquents ; mais il faut le désactiver sur l'immense
majorité des postes de travail. En fait ce serait un excellent outil, si,
à l'installation de Windows, la question était posée : "voulez-vous
activer ou non l'UAC ?"

Et puis, un truc, pour rassurer les utilisateurs de Windows : si vous
utilisez Ubuntu, le même problème existe sur cet OS : il est quasi
impossible d'automatiser quoique ce soit, car des validations manuelles à
tout bout de champ.
Si ça continue, on finira par n'utiliser plus que des serveurs...

@-salutations

Michel Claveau

Merci Michel,
Ca confirme ce que l'on pressentait.
Ta réponse à l'avantage de la clarté.

Pour moi, particulier avec un boitier internet en mode routeur et un réseau
local sur des adresses IP non routables (192.168. ...) la protection restera
du ressort de :
- la translation d'adresse faite par la crétinBox
- le pare-feu de l'OS
- l'anti-virus
et bien évidemment la protection physique de mon domicile et des règles de
prudence évidentes :
* poubelliser tout mail douteux,
* ne pas installer tous les softs en beta "juste pour voir",
* éviter les softs gratuits trouvés dans les magazines,
* gérer des sauvegardes des documents précieux : photos, carnets
d'adresse
* mettre à jour l'antivirus quotidiennement
* mettre à jour windows régulièrement
* conserver les logiciels achetés en lieu sur sur CD ou DVD

Jean Passe et D Meyer

Phil

"MCI (ex do ré Mi chel la si do) [MVP]" <enleverlesO.OmcO@OmclaveauO.com> a
écrit dans le message de news:%23YWmpfGUIHA.4532@TK2MSFTNGP02.phx.gbl...

Bonjour à tous !

Après moult recherches, retour sur tout ce que j'avais expérimenté /
recherché pour RunLike, et après avoir lu vos réponses, je suis arrivé aux
conclusions suivantes :

- avec l'UAC activé, il est actuellement impossible d'avoir une
élévation automatique de privilège. Une intervention manuelle est
obligatoire, à chaque lancement d'un logiciel la nécessitant.

- Contrairement à ce que dit Microsoft, notamment là :

http://msdn2.microsoft.com/fr-fr/library/aa905330.aspx#wvduac_topic6
il arrive souvent que l'UAC ne détecte pas les installations, qui
sont alors lancées avec un niveau de privilèges insuffisant. De même,
l'UAC se trompe souvent sur l'identification de programmes (il confond
souvent documents et programmes). De plus, il ne sait pas gérer
convenablement les logiciels dynamiques, , ou ceux qui utilisent une
machine virtuelle. Dans ces cas là, c'est "tout ou rien", tous les
logiciels sont élevés, ou aucun.
De plus, les processus enfants n'héritent pas toujours du niveau de
privilège du parent. Dès fois, ça marche, des fois non.

- les fichiers manifest, ce n'est pas une solution intéressante. En
pratique, elle ne s'applique qu'aux exécutables simples, programmés en
statique, essentiellement avec les outils de Microsoft. Prenez le cas de
programmes utilisant une machine virtuelle (par exemple, les batchs, qui
utilisent cmd.exe ou command.exe) ;
soit vous définissez un fichier manifest pour chaque batch, ce qui
va vite en faire plusieurs centaines, d'une taille souvent supérieure, et
pénibles à manipuler ;
soit vous définissez un fichier manifest pour cmd.exe ; et alors
TOUT ce qui lancé par cmd.exe va utiliser le même manifest. Sans
possibilités de choix. Ce qui enlève tout intérêt au principe.
Les fichiers manifest utilisent XML ; ce qui entraîne une débauche
de moyens, pour gérer 3 ou 4 informations textuelles. D'où perte de place,
et ralentissements. En plus, il s'agit de XML 1.0 ; je ne suis pas sûr du
tout que Vista suive, si on utilise un fichier XML 1.1 (je rappelle qu'une
des caractéristiques de XML 1.1, c'est la possibilité d'utiliser d'autres
langues que l'anglais dans les tags ; plus exactement, d'autres alphabets
que l'ASCII).
Bref, pour moi, les fichiers manifest, ce n'est qu'une lourdeur (de
plus) sans intérêt.

Au final, même si on veut travailler avec l'UAC, on est strictement limité
à une utilisation simpliste de Windows, avec beaucoup trop de limitations
fonctionnelles.
Donc, je confirme ma position : IL FAUT DESACTIVER L'UAC PAR DEFAUT !
L'UAC devrait être réservé à certains postes sensibles, ou ayant des
utilisateurs inconséquents ; mais il faut le désactiver sur l'immense
majorité des postes de travail. En fait ce serait un excellent outil, si,
à l'installation de Windows, la question était posée : "voulez-vous
activer ou non l'UAC ?"

Et puis, un truc, pour rassurer les utilisateurs de Windows : si vous
utilisez Ubuntu, le même problème existe sur cet OS : il est quasi
impossible d'automatiser quoique ce soit, car des validations manuelles à
tout bout de champ.
Si ça continue, on finira par n'utiliser plus que des serveurs...

@-salutations

Michel Claveau

Vous avez filtré cet utilisateur ! Consultez son message

Merci Michel,
Ca confirme ce que l'on pressentait.
Ta réponse à l'avantage de la clarté.

Pour moi, particulier avec un boitier internet en mode routeur et un réseau
local sur des adresses IP non routables (192.168. ...) la protection restera
du ressort de :
- la translation d'adresse faite par la crétinBox
- le pare-feu de l'OS
- l'anti-virus
et bien évidemment la protection physique de mon domicile et des règles de
prudence évidentes :
* poubelliser tout mail douteux,
* ne pas installer tous les softs en beta "juste pour voir",
* éviter les softs gratuits trouvés dans les magazines,
* gérer des sauvegardes des documents précieux : photos, carnets
d'adresse
* mettre à jour l'antivirus quotidiennement
* mettre à jour windows régulièrement
* conserver les logiciels achetés en lieu sur sur CD ou DVD

Jean Passe et D Meyer

Phil

"MCI (ex do ré Mi chel la si do) [MVP]" a
écrit dans le message de news:%

Bonjour à tous !

Après moult recherches, retour sur tout ce que j'avais expérimenté /
recherché pour RunLike, et après avoir lu vos réponses, je suis arrivé aux
conclusions suivantes :

- avec l'UAC activé, il est actuellement impossible d'avoir une
élévation automatique de privilège. Une intervention manuelle est
obligatoire, à chaque lancement d'un logiciel la nécessitant.

- Contrairement à ce que dit Microsoft, notamment là :

http://msdn2.microsoft.com/fr-fr/library/aa905330.aspx#wvduac_topic6
il arrive souvent que l'UAC ne détecte pas les installations, qui
sont alors lancées avec un niveau de privilèges insuffisant. De même,
l'UAC se trompe souvent sur l'identification de programmes (il confond
souvent documents et programmes). De plus, il ne sait pas gérer
convenablement les logiciels dynamiques, , ou ceux qui utilisent une
machine virtuelle. Dans ces cas là, c'est "tout ou rien", tous les
logiciels sont élevés, ou aucun.
De plus, les processus enfants n'héritent pas toujours du niveau de
privilège du parent. Dès fois, ça marche, des fois non.

- les fichiers manifest, ce n'est pas une solution intéressante. En
pratique, elle ne s'applique qu'aux exécutables simples, programmés en
statique, essentiellement avec les outils de Microsoft. Prenez le cas de
programmes utilisant une machine virtuelle (par exemple, les batchs, qui
utilisent cmd.exe ou command.exe) ;
soit vous définissez un fichier manifest pour chaque batch, ce qui
va vite en faire plusieurs centaines, d'une taille souvent supérieure, et
pénibles à manipuler ;
soit vous définissez un fichier manifest pour cmd.exe ; et alors
TOUT ce qui lancé par cmd.exe va utiliser le même manifest. Sans
possibilités de choix. Ce qui enlève tout intérêt au principe.
Les fichiers manifest utilisent XML ; ce qui entraîne une débauche
de moyens, pour gérer 3 ou 4 informations textuelles. D'où perte de place,
et ralentissements. En plus, il s'agit de XML 1.0 ; je ne suis pas sûr du
tout que Vista suive, si on utilise un fichier XML 1.1 (je rappelle qu'une
des caractéristiques de XML 1.1, c'est la possibilité d'utiliser d'autres
langues que l'anglais dans les tags ; plus exactement, d'autres alphabets
que l'ASCII).
Bref, pour moi, les fichiers manifest, ce n'est qu'une lourdeur (de
plus) sans intérêt.

Au final, même si on veut travailler avec l'UAC, on est strictement limité
à une utilisation simpliste de Windows, avec beaucoup trop de limitations
fonctionnelles.
Donc, je confirme ma position : IL FAUT DESACTIVER L'UAC PAR DEFAUT !
L'UAC devrait être réservé à certains postes sensibles, ou ayant des
utilisateurs inconséquents ; mais il faut le désactiver sur l'immense
majorité des postes de travail. En fait ce serait un excellent outil, si,
à l'installation de Windows, la question était posée : "voulez-vous
activer ou non l'UAC ?"

Et puis, un truc, pour rassurer les utilisateurs de Windows : si vous
utilisez Ubuntu, le même problème existe sur cet OS : il est quasi
impossible d'automatiser quoique ce soit, car des validations manuelles à
tout bout de champ.
Si ça continue, on finira par n'utiliser plus que des serveurs...

@-salutations

Michel Claveau

MCI \(ex do ré Mi chel la si do\) [MVP]

06/01/2008 à 17:05

Re !

Je suis globalement d'accord, mais à cause d'une particularité.

- le pare-feu de l'OS

Parmi les "box", une seule n'est pas configurée comme routeur, par
défaut. Si tu es dans ce cas, l'utilisation du parefeu peut se
comprendre. (mais, il est possible de la configurer comme un routeur).

En effet un routeur protège de toutes les requêtes (TCP/IP, HTTP, etc.)
externes non prévues (sauf avoir expressément configuré le routeur ;
mais là, on sait ce qu'on fait).

Quoique...
En pratique, depuis longtemps, Windows n'a pas d'accès ouverts par
défaut. Alors, même sans routeur (avec un simple modem), je cherche
encore qu'est-ce qui pourrait entrer...

@-salutations

Michel Claveau

Pierre TORRIS

06/01/2008 à 21:00

Phil a écrit dans ce message
<news: :

J'ai suivi tes recommandations et j'ai réactivé l'UAC. Je n'ai qu'un seul
soft rébarbatif : AsusProbe.
Comment puis-je éviter la demande de confirmation au boot de la machine ?
J'ai probe2.exe dont je dois systématiquement confirmer le démarrage. C'est
pas bien grave, mais ça serait plus propre si ça démarrait en silence.

Bonjour,

Pour ma part, c'était Windows Defender qui le bloquait (bizarre ce
bidule)...

Comme je souhaite qu'il surveille un moment le voltage et la
température de mon nx jouet, j'ai utilisé ce petit outil indispensable
conçu par James Brush (traduit par Laurent Gébeau [MVP]) :

Startup Program Unblocker
http://www.jimmah.com/vista/Applications/autostart_admin_program.aspx

En fait, je crois que l'élévation de privilège n'était pas disponible
pour le logiciel, alors j'ai désactivé son démarrage automatique, et
j'ai créé un raccourci dans le groupe de démarrage. On peut ensuite le
régler avec l'outil, et zou. :)

Si ça peut servir à d'autres. ;-)

--
Bien à vous. Pierre TORRIS
www.ptorris.com

David Legrand

07/01/2008 à 02:05

Un utilisateur qui veut lancer un programme, doit faire une action
(valider, cliquer) ; qu'il y ait une deuxième validation (mot de passe,
confirmation, autre clic) ne changera rien. Il lancera quand même le
logiciel.

Remplace le mot utilisateur par le mot virus (par exemple). Sauf si le virus

connaît les mots de passes, il ne peut pas s'exécuter (il ne peut pas faire
sudo mypassword sur UNIX ou l'exemple que je donne plus haut pour Windows)

C'est comme pour la suppression : certain ont fait suivre la question
"voulez-vous supprimer ?" par "Etes-vous sûr ?" et/ou par "Voulez-vous
vraiment supprimer ?" . Résultat : ils cliquent deux ou trois fois, sans
chercher plus loin.
Là je suis d'accord quoique des virus peuvent aussi supprimer les

fichiers/dossiers...

Conclusion : on a rendu le travail plus pénible,

sans le sécuriser plus pour autant.
Juste pour voir ce que ça fait, peux-tu créer un compte standard (en plus de

ton compte actuel qui est admin), réactiver l'UAC et tenter de modifier des
paramêtres important/installer...

Si tu le fais, tu devras rentrer le mot de passe administrateur, là avec ton
compte actuel tu ne peux pas voir grand chose puisque tu es déjà admin.
En gros, l'UAC c'est un sudo graphique (je ne connais pas le niveau de
sécurité derrière mais je déconseille de le désactiver même si c'est embétant
de faire plusieurs fois ok (le clavier est plus rapide que la souris ^^))

Prochaine étape, créer par défaut (et à l'installation) un compte admin et
des comptes normaux bien séparés.

Et pour "pour lequel l'instruction "sudo" permet de contourner le truc.",
viens dans mon école d'ingé informatique pour voir si tu peux faire ce que tu
veux sur les UNIX... En fait, le truc à ne pas faire sur les UNIX, c'est se
déclarer root (avec sudo tu deviens root que pour un processus et pour ses
fils (si je ne me trompe pas et c'est limité dans le temps) mais pas pour le
reste)

Pour revenir au sujet, l'UAC c'est bien ^^
@+

Un utilisateur qui veut lancer un programme, doit faire une action
(valider, cliquer) ; qu'il y ait une deuxième validation (mot de passe,
confirmation, autre clic) ne changera rien. Il lancera quand même le
logiciel.

Remplace le mot utilisateur par le mot virus (par exemple). Sauf si le virus

connaît les mots de passes, il ne peut pas s'exécuter (il ne peut pas faire
sudo mypassword sur UNIX ou l'exemple que je donne plus haut pour Windows)

C'est comme pour la suppression : certain ont fait suivre la question
"voulez-vous supprimer ?" par "Etes-vous sûr ?" et/ou par "Voulez-vous
vraiment supprimer ?" . Résultat : ils cliquent deux ou trois fois, sans
chercher plus loin.
Là je suis d'accord quoique des virus peuvent aussi supprimer les

fichiers/dossiers...

Conclusion : on a rendu le travail plus pénible,

sans le sécuriser plus pour autant.
Juste pour voir ce que ça fait, peux-tu créer un compte standard (en plus de

ton compte actuel qui est admin), réactiver l'UAC et tenter de modifier des
paramêtres important/installer...

Si tu le fais, tu devras rentrer le mot de passe administrateur, là avec ton
compte actuel tu ne peux pas voir grand chose puisque tu es déjà admin.
En gros, l'UAC c'est un sudo graphique (je ne connais pas le niveau de
sécurité derrière mais je déconseille de le désactiver même si c'est embétant
de faire plusieurs fois ok (le clavier est plus rapide que la souris ^^))

Prochaine étape, créer par défaut (et à l'installation) un compte admin et
des comptes normaux bien séparés.

Et pour "pour lequel l'instruction "sudo" permet de contourner le truc.",
viens dans mon école d'ingé informatique pour voir si tu peux faire ce que tu
veux sur les UNIX... En fait, le truc à ne pas faire sur les UNIX, c'est se
déclarer root (avec sudo tu deviens root que pour un processus et pour ses
fils (si je ne me trompe pas et c'est limité dans le temps) mais pas pour le
reste)

Pour revenir au sujet, l'UAC c'est bien ^^
@+

Vous avez filtré cet utilisateur ! Consultez son message

David Legrand

07/01/2008 à 02:24

Donc, je confirme ma position : IL FAUT DESACTIVER L'UAC PAR DEFAUT !
L'UAC devrait être réservé à certains postes sensibles, ou ayant des
utilisateurs inconséquents ; mais il faut le désactiver sur l'immense
majorité des postes de travail. En fait ce serait un excellent outil,
si, à l'installation de Windows, la question était posée : "voulez-vous
activer ou non l'UAC ?"

Sauf si un virus est transmis via une page web (disons une copie d'un site
connu qui passe premier après un google bombing (ou un live search bombing)),
avec l'UAC et un compte standard (non admin), le virus ne peut pas
s'installer (après ça dépend des failles de l'UAC et de Windows mais là c'est
un domaine que je ne connais pas).
Par conséquent, j'ai une position juste opposée à la tienne ^^ (mais j'ai
peut-être tord).

@+

MCI (ex do ré Mi chel la si do) [MVP]

07/01/2008 à 07:54

Bonjour !

Il y a plusieurs cas qui me gênent, dans ta réponse.

Perso je travaille avec des professionnels. Cas typique (réel) : un
réseau avec 70 postes.

1) j'ai un logiciel, dont l'installation passe par l'installation de
plusieurs modules ; or, l'UAC, sensé détecter automatiquement
l'installation ne le fait pas (pas pour tous les modules). Et alors, les
installations (comme les mises à jour) s'effectuent mal (et sans
messages). D'où 70 remontées d'incidents, à chaque fois !

2) certaines applications ont besoin, par moment de droit plus étendus.
Comme l'élévation de privilèges est impossible à programmer/scripter, on
tombe sur les deux cas suivants :
- l'utilisateur est admin local, mais il n'a pas lancé en tant
qu'administrateur, du coup, ça fonctionne mal, ET PERSONNE N'EST
PREVENU.
- l'utilisateur n'est pas admin local, et alors, soit un
administrateur doit se déplacer, pour choisir le compte administrateur
et saisir le mot de passe, ce qui prend 2 jours, pour l'ensemble des
postes ; soit l'utilisateur a pu lancer un truc limité, qui ne
fonctionnera pas correctement (même cas que le 1er).

Conclusion : dans ces deux cas, l'UAC est une source de perte
d'intégrité des données et/ou des sauvegardes. Autrement dit,
l'utilisation incontrôlée de l'UAC est un risque majeur pour
l'informatique.

3) tu parles d'empêcher un virus de s'exécuter. Or, si un virus cherche
à s'exécuter, c'est qu'il est déjà là ! Ce qui veut dire que les
protections anti-virus auront été inefficaces. AMHA, Il vaut mieux
prévenir, et empêcher les virus d'arriver. Et, si un virus est là, il
vaut mieux l'enlever, plutôt que de seulement bloquer certaines de ses
actions.
En plus, non seulement l'UAC ne supprimera pas un virus, mais il peut
fort bien bloquer le programme qui pourrait l'éliminer. L'UAC sera alors
complice du (maintien) du virus !

4) pour sudo, le fait de devoir taper un mot de passe oblige
l'utilisateur à le connaitre. Ou oblige un administrateur à passer sur
tous les postes. Or, entre les bureaux fermés, les absents pour congés,
maladie, réunions, formations, etc. cela peut prendre beaucoup, mais
alors beaucoup de temps...

Conclusion : pour pouvoir travailler, on est obligé de désactiver l'UAC.

@+

Michel Claveau

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour !

Il y a plusieurs cas qui me gênent, dans ta réponse.

Perso je travaille avec des professionnels. Cas typique (réel) : un
réseau avec 70 postes.

1) j'ai un logiciel, dont l'installation passe par l'installation de
plusieurs modules ; or, l'UAC, sensé détecter automatiquement
l'installation ne le fait pas (pas pour tous les modules). Et alors, les
installations (comme les mises à jour) s'effectuent mal (et sans
messages). D'où 70 remontées d'incidents, à chaque fois !

2) certaines applications ont besoin, par moment de droit plus étendus.
Comme l'élévation de privilèges est impossible à programmer/scripter, on
tombe sur les deux cas suivants :
- l'utilisateur est admin local, mais il n'a pas lancé en tant
qu'administrateur, du coup, ça fonctionne mal, ET PERSONNE N'EST
PREVENU.
- l'utilisateur n'est pas admin local, et alors, soit un
administrateur doit se déplacer, pour choisir le compte administrateur
et saisir le mot de passe, ce qui prend 2 jours, pour l'ensemble des
postes ; soit l'utilisateur a pu lancer un truc limité, qui ne
fonctionnera pas correctement (même cas que le 1er).

Conclusion : dans ces deux cas, l'UAC est une source de perte
d'intégrité des données et/ou des sauvegardes. Autrement dit,
l'utilisation incontrôlée de l'UAC est un risque majeur pour
l'informatique.

3) tu parles d'empêcher un virus de s'exécuter. Or, si un virus cherche
à s'exécuter, c'est qu'il est déjà là ! Ce qui veut dire que les
protections anti-virus auront été inefficaces. AMHA, Il vaut mieux
prévenir, et empêcher les virus d'arriver. Et, si un virus est là, il
vaut mieux l'enlever, plutôt que de seulement bloquer certaines de ses
actions.
En plus, non seulement l'UAC ne supprimera pas un virus, mais il peut
fort bien bloquer le programme qui pourrait l'éliminer. L'UAC sera alors
complice du (maintien) du virus !

4) pour sudo, le fait de devoir taper un mot de passe oblige
l'utilisateur à le connaitre. Ou oblige un administrateur à passer sur
tous les postes. Or, entre les bureaux fermés, les absents pour congés,
maladie, réunions, formations, etc. cela peut prendre beaucoup, mais
alors beaucoup de temps...

Conclusion : pour pouvoir travailler, on est obligé de désactiver l'UAC.

@+

Michel Claveau

MCI (ex do ré Mi chel la si do) [MVP]

07/01/2008 à 08:00

Bonjour !

La quasi totalité des virus récents nécessitent, pour s'exécuter, une
validation de l'utilisateur. L'UAC n'y changera rien. Il existe des
logiciels autrement plus efficaces pour bloquer/filtrer les lancements
de processus (PSurv, pour n'en citer qu'un).
De plus, non seulement l'UAC ne supprimera pas un virus, mais il peut
très bien bloquer le programme qui pourrait supprimer ce virus.

@-salutations

Michel Claveau

Jean-Claude BELLAMY

07/01/2008 à 09:20

"MCI (ex do ré Mi chel la si do) [MVP]" a
écrit dans le message de news:%

[... rien que des choses sensées!] Donc, je confirme ma position : IL FAUT
DESACTIVER L'UAC PAR DEFAUT ! L'UAC devrait être réservé à certains postes
sensibles, ou ayant des utilisateurs inconséquents ; mais il faut le
désactiver sur l'immense majorité des postes de travail. En fait ce serait
un excellent outil, si, à l'installation de Windows, la question était
posée : "voulez-vous activer ou non l'UAC ?"

Ah que çà fait plaisir de lire de genre de propos, inspirés par le bon sens,
la logique, un esprit rationnel et pratique, ... :-)

Et ne prends pas çà pour une quelconque flagornerie ! ;-)

J'ai toujours dit que DANS SON ESPRIT, UAC était une BONNE chose (en
particulier pour les "neuneus"- sans aucune connotation péjorative, moi
aussi j'ai été un "neuneu" un jour - et pour les poste très "sensibles"),
mais dont la mise en PRATIQUE s'est révélée DÉSASTREUSE !
En particulier cette IMPOSITION SILENCIEUSE, c'est à dire SANS prévenir
l'utilisateur.
Une fois de plus on est devant l'attitude "hégémononeuronale" de Microsoft
qui veut "penser" pour l'utilisateur!

Cela n'est hélas pas une nouveauté, çà date de plus d'une douzaine d'années
(essentiellement à partir de Windows 95), avec ces IDIOTIES de masquage des
extensions connues (bonjour les virus "I love You" et autres!), le "partage
simple" sous XP PRO (combien d'utilisateurs se sont arrachés les cheveux
pour faire fonctionner un workgroup!), les filtrages insensés du coupe-feu
de XP, les interdictions maladives de IIS6 dans Windows 2003, ..., et pour
finir en apothéose la parano d'UAC de VISTA!

Dans tous ces exemples, Microsoft a fait preuve du MÉPRIS le plus total pour
ses "clients" habituels, utilisant DÉJA les versions précédentes de ses OS,
car à aucun moment il n'y a eu d'avertissement du style : "Attention, à
partir de cette version, ......"

--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org

"MCI (ex do ré Mi chel la si do) [MVP]" <enleverlesO.OmcO@OmclaveauO.com> a
écrit dans le message de news:%23YWmpfGUIHA.4532@TK2MSFTNGP02.phx.gbl...

[... rien que des choses sensées!] Donc, je confirme ma position : IL FAUT
DESACTIVER L'UAC PAR DEFAUT ! L'UAC devrait être réservé à certains postes
sensibles, ou ayant des utilisateurs inconséquents ; mais il faut le
désactiver sur l'immense majorité des postes de travail. En fait ce serait
un excellent outil, si, à l'installation de Windows, la question était
posée : "voulez-vous activer ou non l'UAC ?"

Ah que çà fait plaisir de lire de genre de propos, inspirés par le bon sens,
la logique, un esprit rationnel et pratique, ... :-)

Et ne prends pas çà pour une quelconque flagornerie ! ;-)

J'ai toujours dit que DANS SON ESPRIT, UAC était une BONNE chose (en
particulier pour les "neuneus"- sans aucune connotation péjorative, moi
aussi j'ai été un "neuneu" un jour - et pour les poste très "sensibles"),
mais dont la mise en PRATIQUE s'est révélée DÉSASTREUSE !
En particulier cette IMPOSITION SILENCIEUSE, c'est à dire SANS prévenir
l'utilisateur.
Une fois de plus on est devant l'attitude "hégémononeuronale" de Microsoft
qui veut "penser" pour l'utilisateur!

Cela n'est hélas pas une nouveauté, çà date de plus d'une douzaine d'années
(essentiellement à partir de Windows 95), avec ces IDIOTIES de masquage des
extensions connues (bonjour les virus "I love You" et autres!), le "partage
simple" sous XP PRO (combien d'utilisateurs se sont arrachés les cheveux
pour faire fonctionner un workgroup!), les filtrages insensés du coupe-feu
de XP, les interdictions maladives de IIS6 dans Windows 2003, ..., et pour
finir en apothéose la parano d'UAC de VISTA!

Dans tous ces exemples, Microsoft a fait preuve du MÉPRIS le plus total pour
ses "clients" habituels, utilisant DÉJA les versions précédentes de ses OS,
car à aucun moment il n'y a eu d'avertissement du style : "Attention, à
partir de cette version, ......"

--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org

Vous avez filtré cet utilisateur ! Consultez son message

"MCI (ex do ré Mi chel la si do) [MVP]" a
écrit dans le message de news:%

[... rien que des choses sensées!] Donc, je confirme ma position : IL FAUT
DESACTIVER L'UAC PAR DEFAUT ! L'UAC devrait être réservé à certains postes
sensibles, ou ayant des utilisateurs inconséquents ; mais il faut le
désactiver sur l'immense majorité des postes de travail. En fait ce serait
un excellent outil, si, à l'installation de Windows, la question était
posée : "voulez-vous activer ou non l'UAC ?"

Ah que çà fait plaisir de lire de genre de propos, inspirés par le bon sens,
la logique, un esprit rationnel et pratique, ... :-)

Et ne prends pas çà pour une quelconque flagornerie ! ;-)

J'ai toujours dit que DANS SON ESPRIT, UAC était une BONNE chose (en
particulier pour les "neuneus"- sans aucune connotation péjorative, moi
aussi j'ai été un "neuneu" un jour - et pour les poste très "sensibles"),
mais dont la mise en PRATIQUE s'est révélée DÉSASTREUSE !
En particulier cette IMPOSITION SILENCIEUSE, c'est à dire SANS prévenir
l'utilisateur.
Une fois de plus on est devant l'attitude "hégémononeuronale" de Microsoft
qui veut "penser" pour l'utilisateur!

Cela n'est hélas pas une nouveauté, çà date de plus d'une douzaine d'années
(essentiellement à partir de Windows 95), avec ces IDIOTIES de masquage des
extensions connues (bonjour les virus "I love You" et autres!), le "partage
simple" sous XP PRO (combien d'utilisateurs se sont arrachés les cheveux
pour faire fonctionner un workgroup!), les filtrages insensés du coupe-feu
de XP, les interdictions maladives de IIS6 dans Windows 2003, ..., et pour
finir en apothéose la parano d'UAC de VISTA!

Dans tous ces exemples, Microsoft a fait preuve du MÉPRIS le plus total pour
ses "clients" habituels, utilisant DÉJA les versions précédentes de ses OS,
car à aucun moment il n'y a eu d'avertissement du style : "Attention, à
partir de cette version, ......"

--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org

David Sebban [MS]

07/01/2008 à 13:29

Après moult recherches, retour sur tout ce que j'avais expérimenté /
recherché pour RunLike, et après avoir lu vos réponses, je suis arrivé aux
conclusions suivantes :

- avec l'UAC activé, il est actuellement impossible d'avoir une
élévation automatique de privilège. Une intervention manuelle est
obligatoire, à chaque lancement d'un logiciel la nécessitant.

c'est le but d'UAC, espère que tu n'as pas passé trop de temps la dessus :)

De plus, les processus enfants n'héritent pas toujours du niveau de
privilège du parent. Dès fois, ça marche, des fois non.

ce n'est pas la première fois que je lis ca mais je suis curieux car je n'ai
pas encore constaté cela moi même aurais tu un exemple concret ?

Au final, même si on veut travailler avec l'UAC, on est strictement limité
à une utilisation simpliste de Windows, avec beaucoup trop de limitations
fonctionnelles.

je ne suis pas d'accord, du moins je n'ai pas l'impression d'avoir une
utilisation simpliste de mon pc et pourtant UAC est activé et membre d'une
infrastructure relativement importante :)

Et puis, un truc, pour rassurer les utilisateurs de Windows : si vous
utilisez Ubuntu, le même problème existe sur cet OS : il est quasi
impossible d'automatiser quoique ce soit, car des validations manuelles à
tout bout de champ.

au final tu nous dis que Microsoft a fait ce choix, que Linux le fait
également, mais que c'est le mauvais puisqu'il faut le désactiver :)

Si ça continue, on finira par n'utiliser plus que des serveurs...

je vais en parler a Monsieur et Madame Toulemonde qui ne savent pas ce
qu'est UAC et a qui Microsoft permet d'avoir un peu plus de sécurité lors de
leur utilisation quotidienne.

juste pour ne pas nourrir cette image de Pro UAC aveugle que certains me
prêtent je souhaiterais ajouter qu'il m'est arrivé d'intervenir chez des
clients pour lesquels la LOURDEUR de leur infrastructure et leur INCAPACITE
à s'en sortir (a moins d'engager des sommes astronomiques dont ils ne
disposaient pas) m'a amené a leur conseillé de désactiver UAC.
Je n'ai bien entendu pas le droit de citer le nom de ces entreprises
(gigantesques parfois) mais croyez moi, ce choix a toujours été fait en
dernier recours, a contre cour et en majeur partie a cause de choix
d'architecture tout a fait contestable fait par des administrateurs qui
travaillent de la même façon depuis longtemps.

--
David [MS]
http://blogs.msdn.com/dsebban

Après moult recherches, retour sur tout ce que j'avais expérimenté /
recherché pour RunLike, et après avoir lu vos réponses, je suis arrivé aux
conclusions suivantes :

- avec l'UAC activé, il est actuellement impossible d'avoir une
élévation automatique de privilège. Une intervention manuelle est
obligatoire, à chaque lancement d'un logiciel la nécessitant.

c'est le but d'UAC, espère que tu n'as pas passé trop de temps la dessus :)

De plus, les processus enfants n'héritent pas toujours du niveau de
privilège du parent. Dès fois, ça marche, des fois non.

ce n'est pas la première fois que je lis ca mais je suis curieux car je n'ai
pas encore constaté cela moi même aurais tu un exemple concret ?

Au final, même si on veut travailler avec l'UAC, on est strictement limité
à une utilisation simpliste de Windows, avec beaucoup trop de limitations
fonctionnelles.

je ne suis pas d'accord, du moins je n'ai pas l'impression d'avoir une
utilisation simpliste de mon pc et pourtant UAC est activé et membre d'une
infrastructure relativement importante :)

Et puis, un truc, pour rassurer les utilisateurs de Windows : si vous
utilisez Ubuntu, le même problème existe sur cet OS : il est quasi
impossible d'automatiser quoique ce soit, car des validations manuelles à
tout bout de champ.

au final tu nous dis que Microsoft a fait ce choix, que Linux le fait
également, mais que c'est le mauvais puisqu'il faut le désactiver :)

Si ça continue, on finira par n'utiliser plus que des serveurs...

je vais en parler a Monsieur et Madame Toulemonde qui ne savent pas ce
qu'est UAC et a qui Microsoft permet d'avoir un peu plus de sécurité lors de
leur utilisation quotidienne.

juste pour ne pas nourrir cette image de Pro UAC aveugle que certains me
prêtent je souhaiterais ajouter qu'il m'est arrivé d'intervenir chez des
clients pour lesquels la LOURDEUR de leur infrastructure et leur INCAPACITE
à s'en sortir (a moins d'engager des sommes astronomiques dont ils ne
disposaient pas) m'a amené a leur conseillé de désactiver UAC.
Je n'ai bien entendu pas le droit de citer le nom de ces entreprises
(gigantesques parfois) mais croyez moi, ce choix a toujours été fait en
dernier recours, a contre cour et en majeur partie a cause de choix
d'architecture tout a fait contestable fait par des administrateurs qui
travaillent de la même façon depuis longtemps.

--
David [MS]
http://blogs.msdn.com/dsebban

Vous avez filtré cet utilisateur ! Consultez son message

Après moult recherches, retour sur tout ce que j'avais expérimenté /
recherché pour RunLike, et après avoir lu vos réponses, je suis arrivé aux
conclusions suivantes :

- avec l'UAC activé, il est actuellement impossible d'avoir une
élévation automatique de privilège. Une intervention manuelle est
obligatoire, à chaque lancement d'un logiciel la nécessitant.

c'est le but d'UAC, espère que tu n'as pas passé trop de temps la dessus :)

De plus, les processus enfants n'héritent pas toujours du niveau de
privilège du parent. Dès fois, ça marche, des fois non.

ce n'est pas la première fois que je lis ca mais je suis curieux car je n'ai
pas encore constaté cela moi même aurais tu un exemple concret ?

Au final, même si on veut travailler avec l'UAC, on est strictement limité
à une utilisation simpliste de Windows, avec beaucoup trop de limitations
fonctionnelles.

je ne suis pas d'accord, du moins je n'ai pas l'impression d'avoir une
utilisation simpliste de mon pc et pourtant UAC est activé et membre d'une
infrastructure relativement importante :)

Et puis, un truc, pour rassurer les utilisateurs de Windows : si vous
utilisez Ubuntu, le même problème existe sur cet OS : il est quasi
impossible d'automatiser quoique ce soit, car des validations manuelles à
tout bout de champ.

au final tu nous dis que Microsoft a fait ce choix, que Linux le fait
également, mais que c'est le mauvais puisqu'il faut le désactiver :)

Si ça continue, on finira par n'utiliser plus que des serveurs...

je vais en parler a Monsieur et Madame Toulemonde qui ne savent pas ce
qu'est UAC et a qui Microsoft permet d'avoir un peu plus de sécurité lors de
leur utilisation quotidienne.

juste pour ne pas nourrir cette image de Pro UAC aveugle que certains me
prêtent je souhaiterais ajouter qu'il m'est arrivé d'intervenir chez des
clients pour lesquels la LOURDEUR de leur infrastructure et leur INCAPACITE
à s'en sortir (a moins d'engager des sommes astronomiques dont ils ne
disposaient pas) m'a amené a leur conseillé de désactiver UAC.
Je n'ai bien entendu pas le droit de citer le nom de ces entreprises
(gigantesques parfois) mais croyez moi, ce choix a toujours été fait en
dernier recours, a contre cour et en majeur partie a cause de choix
d'architecture tout a fait contestable fait par des administrateurs qui
travaillent de la même façon depuis longtemps.

--
David [MS]
http://blogs.msdn.com/dsebban

Question aux pro-UAC

10 réponses

Veuillez sélectionner un problème