Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Windows Windows XP Discussions Générales Interdire d'Exécuter en tant que... pour les comptes restreint

Interdire d'Exécuter en tant que... pour les comptes restreint

8 réponses
Avatar
HD
Bonjour,

Je voudrais interdire l'affichage du panneau proposant d' "exécuter en
tant que" pour les comptes restreint... Quelle est la valeur à changer dans
la Base de registre ?

Vous en remerciant d'avance...
--
@+
HD
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Alain Naigeon
"HD" a écrit dans le message de news:
go3mpv$7ut$
Bonjour,

Je voudrais interdire l'affichage du panneau proposant d' "exécuter en
tant que" pour les comptes restreint... Quelle est la valeur à changer
dans la Base de registre ?



Bonjour,

Pour l'affichage je ne sais pas, mais le plus sûr c'est quand même
d'en empêcher l'usage avec l'onglet sécurité à partir de la boîte
Propriétés de l'exécutable. Retirer tous les droits aux comptes
ordinaires.
Supprimer l'affichage n'empêche pas quelqu'un qui connaît
l'existence du programme de le lancer malgré tout.

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Oberhoffen/Moder, France
http://fr.youtube.com/user/AlainNaigeon
Avatar
HD
> Pour l'affichage je ne sais pas, mais le plus sûr c'est quand même
d'en empêcher l'usage avec l'onglet sécurité à partir de la boîte
Propriétés de l'exécutable.


Empêcher l'usage de l'exécutable qui permet de lancer les programmes en tant
que autres utilisateurs ?

Retirer tous les droits aux comptes ordinaires.


J'ai passé les comptes "ordinaires" d'Administrateur à Compte restreint...
Où peut on affiner les droits des comptes ?

@+
HD
Avatar
Alain Naigeon
"HD" a écrit dans le message de news:
go3pt3$87m$
Pour l'affichage je ne sais pas, mais le plus sûr c'est quand même
d'en empêcher l'usage avec l'onglet sécurité à partir de la boîte
Propriétés de l'exécutable.


Empêcher l'usage de l'exécutable qui permet de lancer les programmes en
tant que autres utilisateurs ?

Retirer tous les droits aux comptes ordinaires.


J'ai passé les comptes "ordinaires" d'Administrateur à Compte restreint...
Où peut on affiner les droits des comptes ?



Je suppose que tu es sous XP Pro (sinon il te faut aller sur
le site de JCB pour installer une gestion des droits d'accès
plus subtile).
Donc manip sous compte admin :
Ben tu cherches runas.exe dans C:windowssystem32
Tu fais un clic droit sur le programme, tu choisis Propriétés..
Tu vas sur l'onglet Sécurité
Tu cliques sur Utilisateurs (les comptes ordinaires), et tu vois
que sont cochées les cases "Lecture" et "Lecture et exécution".
Tu décoches ces cases, et tu fais Ok.

Après ça tu vas sous compte ordinaire ; runas est toujours affiché
(je pense), mais si tu essaie de le lancer tu te fais jeter avec un
message du genre "Vous n'avez pas les droits pour..." ou encore
"Accès refusé", quelque chose de ce genre.

Tu peux même raffiner en cas de besoin : dans l'onglet Sécurité,
tu peux créer une entrée pour l'utilisateur (ordinaire) "Monsieur
le privilégié", et lui cocher, à lui seul, les deux cases évoquées
plus haut ! Ce sera alors leul compte ordinaire qui gardera le
droit de lancer le programme. Ceci dit juste pour la beauté ;-)


Maintenant j'ai une question personnelle rusée pour les experts.
Je suppose qu'un exécutable est chargé de gérer la boîte
Propriétés et, en particulier, l'onglet Sécurité.
Si je connais cet exécutable et que je fais un raccourci vers lui
avec un runas /savecred est-ce que désormais n'importe qui
aura accès aux modifs de sécurité ??
Juste histoire de me faire un peu peur :-)

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Oberhoffen/Moder, France
http://fr.youtube.com/user/AlainNaigeon
Avatar
Jean-Claude BELLAMY
"HD" a écrit dans le message de
news:go3mpv$7ut$
Bonjour,

Je voudrais interdire l'affichage du panneau proposant d' "exécuter en
tant que" pour les comptes restreint... Quelle est la valeur à changer
dans la Base de registre ?





Même si c'était possible (je n'ai pas cherché), cela ne servirait
STRICTEMENT A RIEN !

En effet, comment voudrais-tu empêcher un utilisateur à faire appel à la
fonction "CreateProcessWithLogon" ou "CreateProcessAsUser" (de l'API
Advapi32.dll), utilisée entre autres par "runas.exe" ?

Il n'y a rien de plus facile, pour qui sait programmer un tout petit peu, de
créer une appli nommée p.ex. "notepad.exe" ou "calc.exe" (pour tromper
l'ennemi!) qui fasse la même chose que runas !

On trouve des tas d'utilitaires de ce style sur le NET, ne serait-ce que
chez ce bon vieux Mark Russinovich, qui a prévu un "runas amélioré", sachant
gérer l'UAC (sur VISTA et Seven), avec interface graphique ("ShellRunas").
http://technet.microsoft.com/en-us/sysinternals/cc300361.aspx


La solution EXISTE, mais elle n'est pas dans une hypothétique interdiction
qui serait dans la BDR !!!

Il suffit tout simplement que les utilisateurs "lambdas" n'aient aucune
raison d'utiliser "runas" et dérivés, et pour cela il faut et il suffit
qu'ils ne connaissent pas les mots de passe des comptes "intéressants" (=
administrateurs).

Ce n'est pas plus compliqué que cela ...



--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Avatar
Jean-Claude BELLAMY
"Alain Naigeon" a écrit dans le message de
news:
"HD" a écrit dans le message de news:
go3pt3$87m$
Pour l'affichage je ne sais pas, mais le plus sûr c'est quand même
d'en empêcher l'usage avec l'onglet sécurité à partir de la boîte
Propriétés de l'exécutable.


Empêcher l'usage de l'exécutable qui permet de lancer les programmes en
tant que autres utilisateurs ?

Retirer tous les droits aux comptes ordinaires.


J'ai passé les comptes "ordinaires" d'Administrateur à Compte
restreint... Où peut on affiner les droits des comptes ?



Je suppose que tu es sous XP Pro (sinon il te faut aller sur
le site de JCB pour installer une gestion des droits d'accès
plus subtile).
Donc manip sous compte admin :
Ben tu cherches runas.exe dans C:windowssystem32
Tu fais un clic droit sur le programme, tu choisis Propriétés..
Tu vas sur l'onglet Sécurité
Tu cliques sur Utilisateurs (les comptes ordinaires), et tu vois
que sont cochées les cases "Lecture" et "Lecture et exécution".
Tu décoches ces cases, et tu fais Ok.



Et cela ne servira strictement à rien car il suffira de copier un runas.exe
depuis un autre PC, ou depuis internet, de le renommer "radada.exe", et le
tour sera joué !


Après ça tu vas sous compte ordinaire ; runas est toujours affiché
(je pense), mais si tu essaie de le lancer tu te fais jeter avec un
message du genre "Vous n'avez pas les droits pour..." ou encore
"Accès refusé", quelque chose de ce genre.



Mais çà on s'en fiche, puisqu'on peut TRÈS FACILEMENT le contourner !

[...]
Maintenant j'ai une question personnelle rusée pour les experts.
Je suppose qu'un exécutable est chargé de gérer la boîte
Propriétés et, en particulier, l'onglet Sécurité.
Si je connais cet exécutable et que je fais un raccourci vers lui
avec un runas /savecred est-ce que désormais n'importe qui
aura accès aux modifs de sécurité ??



OUI si le RUNAS a été effectué avec un compte admin, dont évidemment on
connait le password !

NON dans le cas contraire (mais là, çà n'aurait AUCUN intérêt!)

Juste histoire de me faire un peu peur :-)


A partir du moment où un utilisateur lambda connait le password d'un admin,
oui, tu peux avoir TRÉS peur !

--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Avatar
Alain Naigeon
"Jean-Claude BELLAMY" a écrit dans le
message de news:

"Alain Naigeon" a écrit dans le message de
Donc manip sous compte admin :
Ben tu cherches runas.exe dans C:windowssystem32
Tu fais un clic droit sur le programme, tu choisis Propriétés..
Tu vas sur l'onglet Sécurité
Tu cliques sur Utilisateurs (les comptes ordinaires), et tu vois
que sont cochées les cases "Lecture" et "Lecture et exécution".
Tu décoches ces cases, et tu fais Ok.



Et cela ne servira strictement à rien car il suffira de copier un
runas.exe depuis un autre PC, ou depuis internet, de le renommer
"radada.exe", et le tour sera joué !



Il y 2 trucs qui me choquent dans ce que tu rapportes (dont je ne doute
pas) :
1)
Cela veut donc dire que les permissions sont attachées à un *nom*
et non pas à un contenu !! Pourquoi pas une hashtable qui permettrait
au gestionnaire des ACL d'identifier chaque objet (dossier, fichier, ou
exécutable) quel que soit le nom qu'il pourrait recevoir par la suite ? :-o
2)
Je ramène un truc de l'extérieur, donc encore inconnu du système, il me
semble que dans un souci de sécurité ça devrait n'avoir qu'un minimum
de permissions par défaut, jusqu'à ce que quelqu'un prenne la responsabilité
d'en décider autrement (ce quelqu'un ne pouvant, bien entendu, pas être
n'importe qui).

En fin de compte si je comprends bien : je vais sur un autre ordi
où j'ai les droits sur runas pour le renommer en faux-jeton.exe
Je le balance en mail sur un compte de mon autre ordi, je sauve la pièce
jointe, et tu me dis que ce truc reçoit automatiquement la permission
"Lecture et exec" ? Mais c'est pure folie ! :-o

Je sais bien qu'il y a moyen de filtrer les exe dans les mails, mais là
je parle de la conception de l'OS en amont : voyons, une construction
aussi chiadée que les ACL est contournée par une manip aussi bête
comme chou que celle que tu indiques ? Il y a là quelque chose qui
me choque, ne pourrait-on alléger l'OS en supprimant cette pitoyable
"ligne Maginot" ? :-)
En tout cas, pourquoi les logiciels qui importent (mail, réseau, etc)
ne forcent-ils pas à "off" les permissions d'exécution à la réception ?
Et puis je me demande : si je déguise un exe en fichier de données,
à quoi correspondent les droits "Lecture et exécution" qui étaient
attachés avant renommage ? Sont-ils logés au même endroit que
le droit de modifier un fichier de données ? J'espère que ma question
est claire, je vais essayer de préciser : est-ce que pour un exécutable
et un fichier de données ou un répertoire, la structure des ACL est
différente dans chaque cas, ou bien est-ce seulement son interprétation
qui varie selon la nature présumée de l'objet ?
Parce qu'en plus, si la nature de l'objet est déduite de son extension,
tout cela paraît finalement assez fragile...

Bouh je n'aimerais pas m'occuper de sécurité, on devient facilement
parano :-)

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Oberhoffen/Moder, France
http://fr.youtube.com/user/AlainNaigeon
Avatar
Jean-Claude BELLAMY
"Alain Naigeon" a écrit dans le message de
news:%
"Jean-Claude BELLAMY" a écrit dans le
message de news:
"Alain Naigeon" a écrit dans le message de
Donc manip sous compte admin :
Ben tu cherches runas.exe dans C:windowssystem32
Tu fais un clic droit sur le programme, tu choisis Propriétés..
Tu vas sur l'onglet Sécurité
Tu cliques sur Utilisateurs (les comptes ordinaires), et tu vois
que sont cochées les cases "Lecture" et "Lecture et exécution".
Tu décoches ces cases, et tu fais Ok.



Et cela ne servira strictement à rien car il suffira de copier un
runas.exe depuis un autre PC, ou depuis internet, de le renommer
"radada.exe", et le tour sera joué !



Il y 2 trucs qui me choquent dans ce que tu rapportes (dont je ne doute
pas) :
1)
Cela veut donc dire que les permissions sont attachées à un *nom*
et non pas à un contenu !!



Exactement !!!!
Et c'est bien là le problème (mais qui n'en est pas un si on gère
correctement les comptes et leurs passwords).

Lors des derniers Techdays, j'ai assisté à un exposé sur la sécurité dans
SEVEN où il était clairement dit que la "Restriction logicielle" n'est
toujours pas au point, et ne le sera peut-être jamais, car trop complexe
et/ou trop bloquante, et de toute façon on peut faire AUTREMENT !

Pourquoi pas une hashtable qui permettrait
au gestionnaire des ACL d'identifier chaque objet (dossier, fichier, ou
exécutable) quel que soit le nom qu'il pourrait recevoir par la suite ?
:-o



C'est déjà prévu (dans XP, Vista, Seven,... cf SECPOL.MSC et les
"stratégies de restriction logicielle"), mais c'est très contraignant, car
il faut que ce "hash" puisse être CERTIFIÉ (sinon cela ne sert à rien), et
dans ce cas comment fait-on avec les logiciels qui ne le sont pas (style
freewares, open source, mini utilitaires persos, scripts, ...) ?

Ensuite, en admettant que le hash existe et soit certifié, comment gérer les
différentes versions, que ce soit les mises à jour ou les versions
linguistiques ? A chaque fois il faudra saisir un nouvel hash, recertifié
qui plus est!

2)
Je ramène un truc de l'extérieur, donc encore inconnu du système, il me
semble que dans un souci de sécurité ça devrait n'avoir qu'un minimum
de permissions par défaut, jusqu'à ce que quelqu'un prenne la
responsabilité
d'en décider autrement (ce quelqu'un ne pouvant, bien entendu, pas être
n'importe qui).



Mais si l'utilisateur lambda qui l'utilise CONNAIT le password d'un admin,
pour peu que le logiciel "alien" ait un "manifest" qui demande l'élévation
de privilèges, il n'y a AUCUNE PARADE, même sous Seven avec UAC "plein pot"
! !


En fin de compte si je comprends bien : je vais sur un autre ordi
où j'ai les droits sur runas pour le renommer en faux-jeton.exe
Je le balance en mail sur un compte de mon autre ordi, je sauve la pièce
jointe, et tu me dis que ce truc reçoit automatiquement la permission
"Lecture et exec" ? Mais c'est pure folie ! :-o


Si tu veux interdire lecture et exec à cela, tu dois l'interdire à tout le
reste !
Mais à la limite, on s'en tamponne le coquillard que l'on puisse l'exécuter,
car si on ignore le password d'un compte admin, à quoi cela servira-t-il ?
A RIEN !


Je sais bien qu'il y a moyen de filtrer les exe dans les mails,


On ne filtre que leur exécution automatique !

mais là
je parle de la conception de l'OS en amont : voyons, une construction
aussi chiadée que les ACL est contournée par une manip aussi bête
comme chou que celle que tu indiques ?



Mais pas du tout !
Excuse moi de te demander pardon, mais tu n'as rien compris ! ;-)
Ou plutôt tu as complètement oublié le SUJET du fil initial :
"Interdire d'Exécuter en tant que... pour les comptes restreints"

TOUT repose sur la connaissance du password d'un compte admin, c'est tout,
rien d'autre...
Et çà, c'est valable QUEL QUE SOIT l'OS !
Même du côté du "pingouin", si tu connais le password de "root", tu peux
aller te rhabiller vite fait bien fait pour tenter une quelconque limitation
d'utilisation de "su" ("super user")!!!
Et inversement, si tu ignores le password de root, tu n'iras pas bien loin
avec la commande "su" !


Il y a là quelque chose qui me choque, ne pourrait-on
alléger l'OS en supprimant cette pitoyable "ligne Maginot" ? :-)


Il n'y a rien de choquant ici ...
La réalité est que c'est un FAUX PROBLÈME !

En tout cas, pourquoi les logiciels qui importent (mail, réseau, etc)
ne forcent-ils pas à "off" les permissions d'exécution à la réception ?
Et puis je me demande : si je déguise un exe en fichier de données,
à quoi correspondent les droits "Lecture et exécution" qui étaient
attachés avant renommage ? Sont-ils logés au même endroit que
le droit de modifier un fichier de données ?


OUI, c'est dans la MFT.
D'ailleurs, tu n'as qu'à prendre un fichier .TXT p.ex., tu verras que dans
son ACL, tu peux cocher ou non "lecture et exécution" !
Le type des permissions sur un fichier (lecture, exécution, écriture, ...)
est totalement INDÉPENDANT de son extension.
Ce qui va distinguer un fichier "exécutable" d'un autre, c'est le contenu de
la clef
HKCR<type de fichier>ShellOpenCommand
qui contient
%1 (ou %*)

Donc on peut très bien "définir" un fichier texte comme exécutable (en
remplaçant "notepad.exe %1" par "%1" dans HKCRtxtfileshellOpenCommand),
mais de la même façon que l'habit ne fait pas le moine, cela ne le rendra
pas pour autant exécutable auprès du microprocesseur ! (les codes ASCII ou
ANSI d'un fichier texte risquent fort d'être interprétés bizarrement par le
système!)


J'espère que ma question
est claire, je vais essayer de préciser : est-ce que pour un exécutable
et un fichier de données ou un répertoire, la structure des ACL est
différente dans chaque cas,


NON
ou bien est-ce seulement son interprétation
qui varie selon la nature présumée de l'objet ?


OUI
Parce qu'en plus, si la nature de l'objet est déduite de son extension,
tout cela paraît finalement assez fragile...

Bouh je n'aimerais pas m'occuper de sécurité, on devient facilement
parano :-)


Au contraire, on se rend mieux compte de l'endroit où se situent les
véritables FAILLES!
Dans le cas présent, la faiblesse du système est ... chez certains
administrateurs qui vont communiquer leur password aux utilisateurs lambdas.

Tu vas alors me rétorquer "Mais alors pourquoi publies-tu une page sur la
perte du password admin, ce qui revient à donner ce fameux password à
n'importe qui ...?"

Ce à quoi je te réponds : çà MONTRE bien où est la réelle faiblesse de
sécurité d'un ordinateur :
- dans son accès physique
- dans la possibilité de le démarrer sur des supports
externes (disquettes, CDROM, clef USB,...)

Si un PC en entreprise (ou milieu "sensible") doit être protégé, il doit :
- être verrouillé mécaniquement
- disposer d'un password au niveau du BIOS
- avoir ses lecteurs externes désactivés,
point barre !
Et la méthode de Petter NORDAHL que j'ai commentée est là UNIQUEMENT pour
dépatouiller un administrateur atteint de la maladie d'Alzheimer, ou tout au
moins distrait ! ;-)


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Avatar
Alain Naigeon
"Jean-Claude BELLAMY" a écrit dans le
message de news:
"Alain Naigeon" a écrit dans le message de
news:%
"Jean-Claude BELLAMY" a écrit dans le
message de news:
"Alain Naigeon" a écrit dans le message de
Donc manip sous compte admin :
Ben tu cherches runas.exe dans C:windowssystem32
Tu fais un clic droit sur le programme, tu choisis Propriétés..
Tu vas sur l'onglet Sécurité
Tu cliques sur Utilisateurs (les comptes ordinaires), et tu vois
que sont cochées les cases "Lecture" et "Lecture et exécution".
Tu décoches ces cases, et tu fais Ok.



Et cela ne servira strictement à rien car il suffira de copier un
runas.exe depuis un autre PC, ou depuis internet, de le renommer
"radada.exe", et le tour sera joué !



Il y 2 trucs qui me choquent dans ce que tu rapportes (dont je ne doute
pas) :
1)
Cela veut donc dire que les permissions sont attachées à un *nom*
et non pas à un contenu !!



Exactement !!!!
Et c'est bien là le problème (mais qui n'en est pas un si on gère
correctement les comptes et leurs passwords).



Aïe, voyons donc la suite.

Lors des derniers Techdays, j'ai assisté à un exposé sur la sécurité dans
SEVEN où il était clairement dit que la "Restriction logicielle" n'est
toujours pas au point, et ne le sera peut-être jamais, car trop complexe
et/ou trop bloquante, et de toute façon on peut faire AUTREMENT !

Pourquoi pas une hashtable qui permettrait
au gestionnaire des ACL d'identifier chaque objet (dossier, fichier, ou
exécutable) quel que soit le nom qu'il pourrait recevoir par la suite ?
:-o



C'est déjà prévu (dans XP, Vista, Seven,... cf SECPOL.MSC et les
"stratégies de restriction logicielle"), mais c'est très contraignant, car
il faut que ce "hash" puisse être CERTIFIÉ (sinon cela ne sert à rien), et
dans ce cas comment fait-on avec les logiciels qui ne le sont pas (style
freewares, open source, mini utilitaires persos, scripts, ...) ?



Certes, ça râlerait sec dans les chaumières bruxelloises :-)

Ensuite, en admettant que le hash existe et soit certifié, comment gérer
les différentes versions, que ce soit les mises à jour ou les versions
linguistiques ? A chaque fois il faudra saisir un nouvel hash, recertifié
qui plus est!



Encore un coup du père colation :-)

Je ramène un truc de l'extérieur, donc encore inconnu du système, il me
semble que dans un souci de sécurité ça devrait n'avoir qu'un minimum
de permissions par défaut, jusqu'à ce que quelqu'un prenne la
responsabilité
d'en décider autrement (ce quelqu'un ne pouvant, bien entendu, pas être
n'importe qui).



Mais si l'utilisateur lambda qui l'utilise CONNAIT le password d'un admin,
pour peu que le logiciel "alien" ait un "manifest" qui demande l'élévation
de privilèges, il n'y a AUCUNE PARADE, même sous Seven avec UAC "plein
pot" ! !



Ok d'accord si je donne mes clés tout le monde peut entrer, bien sûr.


En fin de compte si je comprends bien : je vais sur un autre ordi
où j'ai les droits sur runas pour le renommer en faux-jeton.exe
Je le balance en mail sur un compte de mon autre ordi, je sauve la pièce
jointe, et tu me dis que ce truc reçoit automatiquement la permission
"Lecture et exec" ? Mais c'est pure folie ! :-o


Si tu veux interdire lecture et exec à cela, tu dois l'interdire à tout le
reste !



Cette réponse m'échappe. Je parle quand même d'un fichier bien différent
de ses congénères, en ce que :
1) il arrive *de l'extérieur* ;
2) et pour la première fois.
Est-ce qu'un inconnu au bataillon ne pourrait pas être plus surveillé ?


Mais à la limite, on s'en tamponne le coquillard que l'on puisse
l'exécuter, car si on ignore le password d'un compte admin, à quoi cela
servira-t-il ?
A RIEN !



Oui bien sûr tu as raison : runas demande un Mdp censé donner
plus de droits (sauf utilisateur neuneu :-) ), et alors il faut le
connaître.
J'ai oublié ce "détail" en cours de discussion.


Je sais bien qu'il y a moyen de filtrer les exe dans les mails,


On ne filtre que leur exécution automatique !



Vrai aussi (si tu avais la couleur tu me verrais rosir)

mais là
je parle de la conception de l'OS en amont : voyons, une construction
aussi chiadée que les ACL est contournée par une manip aussi bête
comme chou que celle que tu indiques ?



Mais pas du tout !
Excuse moi de te demander pardon, mais tu n'as rien compris ! ;-)
Ou plutôt tu as complètement oublié le SUJET du fil initial :
"Interdire d'Exécuter en tant que... pour les comptes restreints"

TOUT repose sur la connaissance du password d'un compte admin, c'est tout,
rien d'autre...
Et çà, c'est valable QUEL QUE SOIT l'OS !



Oui, tu sais je pense à haute voix parfois, ça doit bien t'arriver aussi de
remonter
un sous-arbre quand tu es tombé sur une impasse ;-)


Et puis je me demande : si je déguise un exe en fichier de données,
à quoi correspondent les droits "Lecture et exécution" qui étaient
attachés avant renommage ? Sont-ils logés au même endroit que
le droit de modifier un fichier de données ?


OUI, c'est dans la MFT.
D'ailleurs, tu n'as qu'à prendre un fichier .TXT p.ex., tu verras que dans
son ACL, tu peux cocher ou non "lecture et exécution" !
Le type des permissions sur un fichier (lecture, exécution, écriture, ...)
est totalement INDÉPENDANT de son extension.
Ce qui va distinguer un fichier "exécutable" d'un autre, c'est le contenu
de la clef
HKCR<type de fichier>ShellOpenCommand
qui contient
%1 (ou %*)

Donc on peut très bien "définir" un fichier texte comme exécutable (en
remplaçant "notepad.exe %1" par "%1" dans
HKCRtxtfileshellOpenCommand), mais de la même façon que l'habit ne
fait pas le moine, cela ne le rendra pas pour autant exécutable auprès du
microprocesseur ! (les codes ASCII ou ANSI d'un fichier texte risquent
fort d'être interprétés bizarrement par le système!)



Sûr ! Mais je pensais à la manip inverse, déguiser un exécutable en .txt
et trouver une façon de le lancer ?
Oui, je crois que je commence à voir : il faudrait que je puisse modifier la
clé ci-dessus.

est-ce que pour un exécutable
et un fichier de données ou un répertoire, la structure des ACL est
différente dans chaque cas,


NON
ou bien est-ce seulement son interprétation
qui varie selon la nature présumée de l'objet ?


OUI



Merci c'est très clair.


Bouh je n'aimerais pas m'occuper de sécurité, on devient facilement
parano :-)


Au contraire, on se rend mieux compte de l'endroit où se situent les
véritables FAILLES!
Dans le cas présent, la faiblesse du système est ... chez certains
administrateurs qui vont communiquer leur password aux utilisateurs
lambdas.

Tu vas alors me rétorquer "Mais alors pourquoi publies-tu une page sur la
perte du password admin, ce qui revient à donner ce fameux password à
n'importe qui ...?"

Ce à quoi je te réponds : çà MONTRE bien où est la réelle faiblesse de
sécurité d'un ordinateur :
- dans son accès physique
- dans la possibilité de le démarrer sur des supports
externes (disquettes, CDROM, clef USB,...)



Tiens mais au fait, je me souviens que j'avais fait (suite à conseil affiché
à l'écran ? je ne me souviens plus) une disquette de récupération au
cas où j'oublierais mon mot de passe. Apparemment peu de gens l'ont
créée ou alors c'est obsolete ? Je l'ai encore quelque part.

Si un PC en entreprise (ou milieu "sensible") doit être protégé, il doit :
- être verrouillé mécaniquement
- disposer d'un password au niveau du BIOS



Ouauh là t'as pas intérêt à oublier le MdP.

- avoir ses lecteurs externes désactivés,



Ah là je vais me venger un peu : ça ressemble quand même à ma méfiance
de ce qui arrive de l'extérieur :-)
Mais en fait il y a plus qu'une boutade dans ma remarque : comment se
fait-il qu'on sache (on qu'on croie) sécuriser les apports extérieurs d'un
réseau, et qu'on soit si vulnérable devant une disquette ?? :-o
Je crois que j'ai la réponse : pour te faire une sale blague il faudrait que
je puisse faire booter ton ordi depuis chez moi sans te demander ton avis !
Et ça, j'espère que c'est pas pour demain la veille (car si le Bios permet
un
réveil à distance, par contre, évidemment, les données de boot restent
fort heureusement locales !)

point barre !
Et la méthode de Petter NORDAHL que j'ai commentée est là UNIQUEMENT pour
dépatouiller un administrateur atteint de la maladie d'Alzheimer,



Je vais essayer de profiter des quelques années qui me restent :-)

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Oberhoffen/Moder, France
http://fr.youtube.com/user/AlainNaigeon