Attendez, propre politique informatique de votre entreprise vous empêche de faire votre travail?
@ Greg: Cela me fait mal de voir cette mentalité perpétué sous la forme d'une réponse technique. Nous devrions encourager le travail avec votre administrateur système, pas contre eux. Selon toute vraisemblance, ceci est simplement le résultat d'un réglage par défaut dans Kaspersky, combiné avec une pratique légèrement étrange de Visual Studio et, maintenant que l'administrateur système est au courant, ils essaient de trouver une solution réalisable. Cela dit, ayant rejeté l'idée du caractère générique, si votre administrateur système ne cherche pas activement une solution alternative, alors il ne fait pas son travail correctement. C'est un problème à signaler. Bien sûr, la politique de votre bureau va jouer lourdement sur qui gagne dans un argument de développeur vs sysadmin - même certains supérieurs deviennent paniqués lorsque la carte de sécurité de l'entreprise sysadmin stock est jouée!
En tant que sysadmin, je suis aussi mal à l'aise avec les fichiers permettant arbitrairement *.tmp.exec.cmd d'exécuter sans contrôle - Local Settings\Temp est étonnamment facile à écrire de nombreux endroits et beaucoup de (insérer logiciel bien connu) exploits peuvent permettre l'exécution. Cela dit, en tant que développeur, j'ai récemment rencontré le même problème et j'aimerais voir une solution. Donc, avec les deux chapeaux (et un peu de googling), je regarde la politique/les événements de Kaspersky relatifs à nos machines client et je peux voir que les fichiers batch d'événement de construction déclenchent la règle Input/Output redirection dans l'analyseur d'activités d'application . Donc, je suppose que c'est un problème avec la façon dont Visual Studio capture la sortie de vos événements de construction.
Une grande partie de ce qui suit va être une décharge de ce que j'ai essayé de contourner ce problème, avec plus ou moins de succès. Je cours également CruiseControl.NET sur deux machines de construction séparées (c'est là que j'ai d'abord remarqué le problème), donc je vais rompre sur une tangente pour les couvrir aussi. Je pense qu'une récente mise à jour de Kaspersky pourrait avoir modifié l'action par défaut de Allow/Prompt to Quarantine, ou que les définitions de cette mise à jour sont trop zélées.
La documentation de Kaspersky peut être un peu légère (au mieux), en particulier en ce qui concerne le composant Proactive Defense et ce qu'il vérifie réellement.
Je peux voir quatre solutions possibles à cela, en plus de l'exclusion générique mentionné ci-dessus:
- Modification des paramètres AAA dans Kaspersky pour faire la redirection d'E/S une activité prompatable
- Ajouter la règle d'exclusion pour
*.tmp.exec.cmd mais limiter seulement à ne pas être soumis à la composante Défense proactive pour le type de menace RootShell
- Désactivation de la vérification de la redirection d'E/S
- Ajout d'une exclusion « zone de confiance » pour
%WINDIR%\Microsoft.NET\Framework\*\MSBuild.exe, (et Framework64) avec Do not restrict application activity
Option 1 pourrait être suffisante, car il met le contrôle à l'utilisateur final (si elles sont considérées comme suffisamment fiables pour prendre la décision), mais ils peuvent bloquer la CC.NET construire un processus pendant qu'il attend une réponse.
L'option n ° 2 peut fournir suffisamment d'un cas de contour que l'administrateur système est plus enclin à inclure la règle. Vous pouvez également être en mesure de qualifier la règle avec le chemin temporaire, tel que %TEMP%\*.tmp.exec.cmd pour réduire davantage le problème. Pour la session de service, les variables d'environnement ne semblent pas être chargées, (au moins la règle ne semble pas avoir été déclenchée), vous devez donc contourner ce problème en exécutant CC.NET sous un compte de service de domaine connu et en ajoutant une autre règle spécifiant explicitement son emplacement temporaire.
L'option 3 sent tout autant l'exception générique, sinon pire. Bien, est-ce que la redirection d'E/S est vraiment un gros problème? La capacité de canaliser la sortie d'un processus vers un autre doit-elle être étroitement contrôlée? Kaspersky semble le penser, mais je ne suis pas si sûr. Sûrement beaucoup d'applications d'automation/de style de planificateur seraient affectées par ceci?
L'option 4 est ma préférence en tant qu'administrateur système. Si je peux trouver la bonne combinaison de paramètres pour que MSBuild puisse faire son travail, mais tout le reste est toujours couvert, c'est sûrement la bonne façon, sûrement? Malheureusement, comme le processus MSBuild.exe engendre un processus cmd.exe pour exécuter les fichiers *.tmp.exec.cmd et que c'est dans le contexte de ce processus cmd.exe que Kaspersky analyse le fichier. Ce qui signifie que la règle d'application approuvée doit être définie pour cmd.exe, avec Do not control application activity. Cela semble pire que l'exclusion générique pour *.tmp.exec.cmd parce que cela signifierait effectivement que tous les fichiers de traitement par lots sont exclus du test, plutôt que seulement le sous-ensemble. Donc, je reviens à une combinaison des options 1 et 2. J'ajoute des règles d'exclusion pour %TEMP%\*.tmp.Exec.cmd, %USERPROFILE%\Local Settings\Temp\*.tmp.Exec.cmd et %USERPROFILE%\AppData\Local\Temp\*.tmp.Exec.cmd (si %TEMP% n'est pas défini, le chemin basé sur %USERPROFILE% devrait être sur XP et W7 respectivement). Je change également l'action par défaut pour I/O redirection en Prompt donc, s'il s'agit d'une nouvelle règle/définition trop agressive, tous les autres programmes que cela pourrait affecter peuvent être explicitement contrôlés par mes utilisateurs finaux (ou, à tout le moins, ils pourraient les effrayer suffisamment à venir me demander à ce sujet). En ce qui concerne CC.NET, le plan est double: soit j'installe CC.NET sur des serveurs réels, j'exécute Kaspersky Server Edition (qui n'inclut pas le module AAA) ou, si j'installe délibérément CC .NET à une construction de poste de travail (par exemple, si je veux voir automatiquement si mon application fonctionne en W2K/WXP/W7 en utilisant des tests unitaires, etc.), j'en fais partie de la procédure d'exploitation standard pour configurer le CC.Service NET à exécuter sous mon compte de service de domaine dédié, puis ajouter des règles d'exclusion fixes à notre politique Kaspersky pour C:\Documents and Settings\svc-ccnet\Local Settings\Temp\*.tmp.Exec.cmd et C:\Users\svc-ccnet\AppData\Local\Temp\*.tmp.Exec.cmd, avec un type de menace de RootShell et le composant défini sur Proactive Defense. En poussant, je pourrais ajouter les appareils CC.NET à un groupe KAV différent, ce qui relâche la restriction AAA.
J'espère que cela aide (en fait, j'espère que quelqu'un d'autre vient et dit "vous avez manqué quelque chose de très simple" et explique ensuite ce que c'est !!).
TL; DR Version: Les options que j'ai trouvé dans KAV pour prévenir ou réduire l'effet de ce sont les suivants. Obtenez votre sysadmin pour choisir celui qu'ils sont plus à l'aise:
- Définissez l'action pour redirect I/O Autoriser ou Demander dans l'application Activité paramètres Analyseur de la politique
- Décochez l'option de redirection d'E/S dans le activité application Analyseur de politique de paramètres
- Ajouter
%COMSPEC% à la liste de la politique des applications de confiance, cochant la case « ne pas contrôler l'activité de l'application »
- Ajouter
%TEMP%\*.tmp.exec.cmd aux règles d'exclusion de la politique, en utilisant le type de menace RootShell et la composante Proactive Defense
Ma préférence est # 4; d'autres peuvent différer.
Attendez, la politique informatique de votre entreprise vous empêche de faire votre travail? Prenez-le avec votre patron. Ce genre de chose n'est pas un problème de programmation. –
@Greg, ouais, je sais que c'est légèrement hors sujet, j'ai hésité à demander si c'est la faute du serveur, mais même si ce n'est pas un problème de programmation, c'est un problème pour les programmeurs. – Benjol