2009-03-16 10 views
6

Pour comprendre ce que je demande, il est important de distinguer parmi les nombreuses utilisations de SUID dans Unix.Quels choix ai-je sur les plates-formes MS Windows pour l'équivalent de SUID à partir de plates-formes Unix?

J'ai un projet qui utilise un exécutable dans le PATH de l'utilisateur qui appartient au projet et dont le bit SUID est défini. De cette façon, lorsqu'il s'exécute, il s'exécute dans le contexte du propriétaire du fichier, pas de l'utilisateur appelant. De cette façon, il a accès à des choses que l'utilisateur n'a pas, et ainsi ces choses sont protégées de l'utilisateur par des protections de système de fichiers normales. Cela fonctionne raisonnablement bien. Les plans sont de déplacer le projet vers une architecture client-serveur, mais cela prendra du temps. En attendant, comment puis-je répliquer ce type de comportement sur les systèmes Windows?

Notez que les exécutables du projet n'appellent pas l'appel de la bibliothèque SETUID bien, franchement, ce serait une grande fonctionnalité à ajouter, à mon avis, compte tenu de ce que le projet fait. Le projet n'a pas besoin des privilèges root du système. Son premier souci de sécurité est qu'il doit protéger ses propres fichiers de l'utilisateur (qui est simplement n'importe quel utilisateur autre que le propriétaire du fichier) et ce serait très bien s'il avait la possibilité de passer en "contexte utilisateur" pour accéder au fichier système comme s'il s'agissait de l'utilisateur appelant. (De cette façon, il pourrait plus facilement déterminer ce qui est OK pour le projet à toucher et ce qui ne l'est pas.)

Le projet est écrit dans une combinaison de C et Java - un programme C avec SUID ensemble appelle le code Java ...

Je suis désireux de connaître tous ces mécanismes, et je suis particulièrement concentré sur ceux qui sont:

  1. Convient C et Java, et;
  2. Facile à mettre en œuvre pour les programmeurs non-Windows, et;
  3. Nécessite un codage minimal propre à Windows.

Si certaines solutions sont supérieures, veuillez nous faire part de vos réflexions sur ce que vous savez de ce point de vue.

NOTES:

  1. LogonUser: demande un mot dans le texte brut. Comment cela peut-il être une réponse?
  2. RunAs: Vous devez entrer le mot de passe à PROMPT! ... Comme avec LogonUser seulement pire; Je ne vois pas comment c'est une réponse.
+0

La solution appropriée consiste à installer un service. –

Répondre

3

Je ne pense pas qu'il existe un équivalent de SETUID dans Windows, mais vous pouvez lancer un processus en tant qu'un autre utilisateur. Si vous utilisez C, il n'y a vraiment que deux grandes fonctions de Windows spécifiques, vous devez examiner:

LogonUser

CreateProcessAsUser

Les docs pour ces fonctions sont très bonnes, donc il shouldn » t être cet énorme défi. Fondamentalement, vous utiliserez LogonUser pour emprunter l'identité de l'utilisateur, puis CreateProcessAsUser pour lancer la machine virtuelle Java en tant qu'utilisateur.

Vous pouvez également consulter la commande RUNAS, mais je ne sais pas si cela répondrait à vos besoins ou non.

+0

Merci, en les regardant ... RT –

4

Cygwin a une excellente discussion sur la façon dont ils le font sans que le mot de passe utilisateur ici: Using Windows security in Cygwin

Fondamentalement, ils installent un package d'authentification LSA personnalisé qui fournit des jetons de sécurité sans exiger un mot de passe. En tant que solution de secours, lorsque le package d'authentification n'est pas installé, ils utilisent l'API NtCreateToken non documentée.

Une application qui souhaite emprunter l'identité peut effectuer un appel cygwin setuid avant d'appeler java.

+0

Oui, il se trouve que c'est EXACTEMENT ce que nous avons fait depuis les mi-naughts. Mais, il faut que l'utilisateur installe Cygwin - un bonus dans mon esprit, mais les utilisateurs ne sont pas ravis d'avoir à installer trop de paquets, surtout quand ils ne comprennent pas/perçoivent la valeur pour eux. Il semble cependant (compte tenu du manque d'autres réponses) que ce soit le seul autre moyen. –

+0

Ouch. Quel cauchemar du point de vue de la sécurité. Une raison de plus pour éviter Cygwin, IMO! –