Base de registre, ACL et C#

nicolaslepot Messages postés 23 Date d'inscription dimanche 19 décembre 2004 Statut Membre Dernière intervention 20 décembre 2006 - 19 déc. 2006 à 18:45
cs_coq Messages postés 6349 Date d'inscription samedi 1 juin 2002 Statut Membre Dernière intervention 2 août 2014 - 20 déc. 2006 à 19:24
Bonjour,

Dans un programme destiné à des supers end-users , il est impératif que je modifie le contenu d'une clé de registre qui se trouve dans la HKLM\Software. Mais je sais que là bas, par défaut les utilisateurs  n'ont pas le droit d'aller lorsqu'ils sont dans un domaine.

Alors, j'ai pensé que plutôt que de laisser décrouvrir à mes collègues que mon programme plante à un endroit à cause de ça, ce serait bien de pouvoir définir un droit d'accès plus léger uniquement sur cette clé.

Donc ma question est la suivante, comment définir en C# un droit d'accès genre tout le monde en lecture/écriture pour une clé de la base de registre ?

Merci d'avance,

nico

3 réponses

cs_coq Messages postés 6349 Date d'inscription samedi 1 juin 2002 Statut Membre Dernière intervention 2 août 2014 101
19 déc. 2006 à 19:17
Salut,

C'est plutôt une tâche administrative ça.
Le "problème" est que si tes utilisateurs n'ont pas accès en écriture à cette clé, il n'auront probablement pas non plus le droit de changer leurs droits sur cette clé (et heureusement).

Sinon la classe RegistryKey possède une méthode SetAccessControl.

/*
coq
MVP Visual C#
CoqBlog
*/
0
nicolaslepot Messages postés 23 Date d'inscription dimanche 19 décembre 2004 Statut Membre Dernière intervention 20 décembre 2006
20 déc. 2006 à 16:36
Salut,

Merci pour cette réponse. Ca marche :)

En fait j'ai un 1 er programme qui s'exécute au démarrage, juste après la phase de logon, mais malheureusement juste avant la création de l'environnement utilisateur. Donc ce 1 er programme tourne avec l'identité de l'utilisateur système. Donc j'écris dans HKLM\Software\... car HKCU n'existe pas encore a ce moment là. Mon soucis était qu'une fois le user bien connecté, un deuxième programme devait aller lire puis modifier la clé dans HKLM\Software\.... Et là, ca foirait à cause des droits. En redéfinissant les droits adéquats dans le premier programme j'arrive maintenant à lire avec le deuxième... Et ce en laissant bien les utilisateurs du domaine en tant qu'utilisateurs sans pouvoir sur leur machine!!!

Mais je pense qu'il y a encore moyen d'un peu améliorer...

Je crois savoir que la branche HKCU n'est en fait qu'un raccourcis vers HKU\[id_user]\.
Si j'arrive a écrire dans HKU\[id_user]\Software\... avec mon 1er programme, mon deuxième programme n'aura pas besoin de droit spécifique pour récupérer/modifier cette valeur de clé car il y accédera directement via HKCU\Software\...
Ce serait d'autant mieux (et plus sécurisé) car la donnée que j'écris dans le registre n'est autre que le mot de passe d'authentification entré par l'utilisateur au logon de Windows (je l'ai quand même chiffré au passage)...
De plus, en stockant ma donnée dans HKLM avec la modif de droit d'accès, la donnée se trouve à la portée de tous les users locaux ou du domaine qui se connectent sur cette machine. Si la donnée en question était écrite dans le bon HKU\[id_user]\ (autrement dit dans la branche HKCU de cet utilisateur), seul l'utilisateur en question aurait la capacité de manipuler sa propre donnée...
> Sécurité++ :)

Du coup, je pousse la réflexion plus loin en me demandant ceci :

comment savoir à quel utilisateur correpond les [id_user] sous la branche HKU\ du registre ???

Si je peux le détecter avec mon 1er prog et y écrire ma donnée, il n'y a plus besoin d'ACL et la sécurité globale du SI augmenterait. Ce serait génial.

Voulou voilou, désolé pour le roman,

Merci d'avance pour vos idées,

nico
0
cs_coq Messages postés 6349 Date d'inscription samedi 1 juin 2002 Statut Membre Dernière intervention 2 août 2014 101
20 déc. 2006 à 19:24
Logiquement une méthode des API permet de récupérer le nom d'utilisateur à partir du SID.
LookupAccountSid il me semble.

/*
coq
MVP Visual C#
CoqBlog
*/
0
Rejoignez-nous