Its so easy when you work in an office that uses computers purely for administration and standard software isn't it. Out in research land they develop and tweak software to enable them to perform the research and analyse the results, or do you think that you can do everything with off the shelf software, or perhaps Excel macros and a pivot table?
. . . Which has what to do with an SRP denying access to execute from %temp%? Other than nothing, obviously. Straw man argument.
Microsoft overview of SRP's for those people who have just heard of them for the first time:-
because we all know that viruses only come as compiled binaries and never anything like a java package, a PDF, or really any other file format (None are safe). Most e-mail / internet borne viruses are just using scripting in PDFs or Java applets to infect the machines.
Just add "JAR" extensions to your designated file types to block it as well if it's appropriate in your enviroment?
I maintain that you cannot rationally allow users run executable code sent as attachments on emails and then write a policy saying that the end user is responsible for not running stuff they are sent. Doing so is patently absurd and deserves all the riddicule that can be thrown at it given the number of infections via this entry vector.
User education is important, but it should not be the sole line of defence.
If you want to knock holes in SRP's, the appropriate place to start would be the utterly absurd handling of shortcuts which limits their usefulness in locking systems down completely. This does not inhibit their effectiveness in blocking preventing software from running from specific folders like %temp%, however! Like anti-virus software, SRP's are not a cure all, but should be considered an important tool.