visual studio - Kaspersky is choking on my pre/post build events -

apparently vs wraps post- , pre-build events in cmd file pops in localsettings/temp folder. kaspersky has (it worked fine yesterday) decided threat (rootshell risk), , puts them in quarantine, leaves me hung vs, , no way compile projects (other going through them manually removing events).

the sysadmin here - understandably - not keen on doing wildcard exception *.tmp.exec.cmd files in localsettings/temp folder. google-fu hasn't helped me far.

anyone encountered problem or got tips?

edit fwiw, having same problem git, smartgit, , load of other programs. kaspersky getting smart own good...

wait, company's own policy preventing getting work done?

@greg: pains me see mentality perpetuated in guise of technical answer. should encourage working sysadmin, not against them. in probability, merely result of default setting within kaspersky, combined slightly-odd practice visual studio and, sysadmin aware, trying find workable solution.

that said, having dismissed idea of wildcard, if sysadmin not actively looking alternative solution, not doing job properly. reportable issue. of course, office's politics going play heavily on wins in developer vs sysadmin argument -- higher-ups panicky when sysadmin's stock 'company security' card played!

as sysadmin, uncomfortable arbitrarily allowing *.tmp.exec.cmd files execute unchecked -- local settings\temp surprisingly easy write many places , plenty of (insert well-known software) exploits can allow execution.

that said, developer, have experienced same issue , love see solution.

so, both hats on (and bit of googling), @ kaspersky policy/events relating our client machines , can see build event batch files triggering input/output redirection rule in application activity analyser. guess problem way visual studio captures output build events.

much of following going brain-dump of things have tried around issue, varying degrees of success. run cruisecontrol.net on couple of separate build machines (this first noticed issue), break off on tangent cover too.

it belief recent kaspersky update might have altered default action allow/prompt quarantine, or definitions over-zealous.

kaspersky documentation can little light (at best), particularly regards proactive defence component , checking for.

i can see 4 possible solutions this, besides aforementioned wildcard exclusion:

1. changing aaa settings in kaspersky make i/o redirection prompatable activity
2. add exclusion rule *.tmp.exec.cmd limit not being subject proactive defense component threat type rootshell
3. turning off check i/o redirection
4. adding "trusted zone" exclusion %windir%\microsoft.net\framework\*\msbuild.exe, (and framework64) do not restrict application activity

option #1 might sufficient, puts control end user (if considered reliable enough make decision) may lock cc.net build process while waits response.

option #2 might supply enough of edge case sysadmin more amenable including rule. may able qualify rule temp path, such %temp%\*.tmp.exec.cmd further reduce concern. service session, environment variables don't seem be loaded, though (at least rule didn't seem triggered), have around running cc.net under known domain service account , adding rule explicitly specifying temp location.

option #3 smells as wildcard exception, if not worse. although, i/o redirection big of deal? should ability pipe output of process tightly controlled? kaspersky seems think so, i'm not sure. surely many automation/scheduler-style apps adversly affected this?

option #4 preference sysadmin. if can find correct combination of settings msbuild allowed job, else still covered, must correct way, surely?

unfortunately not, msbuild.exe process spawns cmd.exe process run *.tmp.exec.cmd files , under context of cmd.exe process kaspersky scans file. means trusted application rule have defined cmd.exe, do not control application activity. seems worse wildcard exclusion *.tmp.exec.cmd because mean batch files excluded test, rather subset.

so come combination of options #1 , #2. add exclusion rules %temp%\*.tmp.exec.cmd, %userprofile%\local settings\temp\*.tmp.exec.cmd , %userprofile%\appdata\local\temp\*.tmp.exec.cmd (if %temp% not defined, %userprofile%-based path should there on xp , w7 respectively). change default action i/o redirection prompt so, if overly-aggressive new rule/definition, other programs might affect can explicitly controlled end users (or, @ least, might scare them enough come ask me it).

as far cc.net goes, plan two-fold: either install cc.net on actual servers, running kaspersky server edition (which not include aaa module) or, if deliberately installing cc.net workstation build (e.g. if want automagically see if app works in w2k/wxp/w7 using unit tests, etc), make part of standard operating procedure configure cc.net service run under dedicated domain service account, svc-ccnet, , add fixed exclusion rules our kaspersky policy c:\documents , settings\svc-ccnet\local settings\temp\*.tmp.exec.cmd , c:\users\svc-ccnet\appdata\local\temp\*.tmp.exec.cmd, threat type of rootshell , component set proactive defense. @ push might add cc.net devices different kav group relaxes aaa restriction.

i hope helps (actually, hope else comes along , says "you've missed simple" , explains is!!).

---

tl;dr version: options i've found in kav prevent or reduce effect of follows. sysadmin pick 1 comfortable with:

1. set action i/o redirect allow or prompt in policy's application activity analyzer settings
2. uncheck i/o redirect option in policy's application activity analyzer settings
3. add %comspec% policy's list of trusted applications, checking "do not control application activity"
4. add %temp%\*.tmp.exec.cmd policy's exclusion rules, using threat type rootshell , component proactive defense

my preference #4; others may differ.