Calculer Girl
  1. Calculer Girl
  3. Puis-je créer un mutex Windows globalement pour les processus qui connaissent le mot de passe du mutex?
Intereting Posts
Comment tuer un processus après un temps réel donné dans Bash? Problème SVN 1.7.1 Redéfinition des clés dans Emacs sous Windows Qu’est-ce que vous utilisez pour développer des applications sur Linux? Script bluetooth sous Linux Build.xml pose problème. “Erreur CreateProcess = 87, le paramètre est incorrect” configure: erreur: APR introuvable. Veuillez lire la documentation Les mêmes en-têtes de nom avec un contenu différent dans le système Ubuntu Reverse proxy pour un sous-répertoire avec les applications nginx et Play 2.1 Message d’erreur `marshal data too short` lors de l’installation de watir-webdriver sur Windows XP installation personnalisée de pyodbc Comment cibler plusieurs versions de Windows Python – Récupère les valeurs des capteurs et la vitesse des ventilateurs – Windows 10 Python ne parvient pas à ouvrir csv 11 Go en mode r + mais s’ouvre en mode r Liste tous les exécutables dans le cwd avec grep

Puis-je créer un mutex Windows globalement pour les processus qui connaissent le mot de passe du mutex?

Je veux créer un mutex Windows en utilisant WinAPI, CreateMutex() et OpenMutex() . Mais pour des raisons de sécurité, je souhaite que le mutex soit ouvert par les processus qui connaissent le “mot de passe” ou le code magique du code dur. Je ne veux pas que le mutex soit accessible par tous les processus.

Par exemple, créez un mutex nommé “Globel \ cd689f00-0462-11e5-b939-0800200c9a66”. Donc, seul le processus qui connaît le nom du mutex peut accéder à ce mutex. Mais ce n’est pas une bonne solution car vous pouvez simplement utiliser Winobj.exe et vous avez encore une chance de trouver ce mutex. Je veux que ce mutex soit protégé par quelque chose comme ACL (Access Control Lists). Le problème est que je ne peux pas trouver un moyen de créer mon propre SID pour ACL.

Voici ce que je sais et ce que je veux: 1. Je sais que je peux faire accéder mutex par de nombreux processus en le nommant “Global \ MyMutexName”. 2. J’essaie également de comprendre les ACL et SID mentionnés sur MSDN. Mais je ne peux toujours pas trouver un moyen de créer mon propre SID (peut-être que cela n’a pas de sens?). 3. Je ne souhaite pas élever mes processus à Admin.

Ce que vous essayez de faire n’est pas naturel pour le modèle de sécurité utilisé par Windows. Les permissions sont toujours accordées en fonction de l’utilisateur exécutant l’exécutable et non de l’exécutable lui-même. Cependant, en fonction de votre scénario, il peut exister des options appropriées.

Si tous les processus impliqués se situent dans le contexte du même utilisateur, vous pouvez utiliser IPC (par exemple, des canaux nommés) pour identifier vos processus “amis” et DuplicateHandle () pour passer un handle à un mutex sans nom entre les processus.

Si les processus doivent être dans des contextes utilisateur différents, une option consisterait à faire fonctionner un service système dans un contexte privilégié pour agir en tant que courtier. Bien sûr, cela nécessite que le service système soit installé avec le privilège administrateur, mais cela est généralement acceptable. il suffit de le faire une fois.

Si l’application doit être portable (aucune installation ou installation possible sans access administrateur) et doit franchir les frontières des utilisateurs, je pense que vous devrez utiliser IPC pour implémenter votre propre mutex. Bien sûr, ce serait très inefficace.

Gardez à l’esprit que dans l’un de ces scénarios, un utilisateur malveillant peut toujours accéder au mutex – le mieux que vous puissiez faire est de le rendre légèrement plus difficile. Si vous utilisez un mutex réel, par exemple, l’attaquant pourrait énumérer les descripteurs de l’un des processus, identifier le mutex et dupliquer le handle. (Ou simplement injecter du code malveillant dans l’un des processus soi-disant “amis” pour utiliser le handle directement). Même l’IPC pourrait être espionné et dupliqué.

Vous devriez sérieusement examiner si l’avantage de sécurité marginal vaut la hausse significative de la complexité. IMO, il est peu probable que ce soit.

(En passant, la solution appropriée consiste pour un service système à effectuer tout le travail nécessitant un access au mutex; l’application que les utilisateurs exécutent est généralement un client léger qui ne fait que fournir l’interface graphique.)

Vous laisseriez Windows créer un nouveau SID; n’essayez pas d’en créer un vous-même. Avec ce SID, vous pouvez ensuite créer une liste de contrôle d’access (Access Control List) qui accorde l’access à tous les processus contenant ce SID et (implicitement) refuse à tout le monde ce droit. Cette ACL peut alors être appliquée au mutex, ce qui la protège.

Maintenant, pour avoir access, vous devez créer un jeton d’emprunt d’ identité pour ce SID. Si je comprends MSDN, le processus consiste à ouvrir votre jeton de thread, à définir TokenUser via SetTokenInformation , puis à appliquer le jeton modifié via SetThreadToken .

Ce jeton d’emprunt d’identité est maintenant utilisé lors de la vérification de la liste de contrôle d’access du mutex.

MSDN n’est pas tout à fait clair sur le processus de création d’un SID d’utilisateur valide; il peut être nécessaire de remplacer “User SID” par “Group SID” dans le processus ci-dessus.