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,
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,
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 ?
> 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.
> 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.
> 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.
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 ?
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 ?
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 ?
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,
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,
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 ?
"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.
[...]
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 :-)
"HD" <hd@anti.spam.fr> a écrit dans le message de news:
go3pt3$87m$1@biggoron.nerim.net...
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.
[...]
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 :-)
"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.
[...]
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 :-)
"Alain Naigeon" a écrit dans le message deDonc 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é !
"Alain Naigeon" <anaigeon@free.fr> 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é !
"Alain Naigeon" a écrit dans le message deDonc 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é !
"Jean-Claude BELLAMY" a écrit dans le
message de news:"Alain Naigeon" a écrit dans le message deDonc 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 :-)
"Jean-Claude BELLAMY" <Jean-Claude.Bellamy@wanadoo.fr> a écrit dans le
message de news: OlQbvn3lJHA.4128@TK2MSFTNGP02.phx.gbl...
"Alain Naigeon" <anaigeon@free.fr> 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 :-)
"Jean-Claude BELLAMY" a écrit dans le
message de news:"Alain Naigeon" a écrit dans le message deDonc 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 :-)
"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 deDonc 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!
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 !
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!)
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,
NONou bien est-ce seulement son interprétation
qui varie selon la nature présumée de l'objet ?
OUI
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,
"Alain Naigeon" <anaigeon@free.fr> a écrit dans le message de
news:%23mOBSl4lJHA.3644@TK2MSFTNGP03.phx.gbl...
"Jean-Claude BELLAMY" <Jean-Claude.Bellamy@wanadoo.fr> a écrit dans le
message de news: OlQbvn3lJHA.4128@TK2MSFTNGP02.phx.gbl...
"Alain Naigeon" <anaigeon@free.fr> 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!
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 !
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!)
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
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,
"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 deDonc 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!
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 !
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!)
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,
NONou bien est-ce seulement son interprétation
qui varie selon la nature présumée de l'objet ?
OUI
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,