up vote 1 down vote favorite
1
share [g+] share [fb]

I was looking here

Now, it sounds promising to be able to restrict where programs are executed from, making sure they only execute from %PROGFILES% and %WINDIR%, but I have to wonder how enforceable and lock-downable that is to do. Assuming that page is followed, and there are no current vulnerabilities(only for the purposes of my question).

Can you ensure that programs can't be executed from %TEMP%, that programs couldn't just be launched from cmd or start commands, or from within other programs? Basically, are there any ways around this, and if so, how too could you lock them down?

link|improve this question
33% accept rate
feedback

4 Answers

up vote 1 down vote

I think Software Restriction Policies, introduced with Windows XP and Windows Server 2003 are a valid instrument to prevent unwanted programs from running.

If the Path rules you describe are not secure enough in your opinion, you could always add hash rules (cryptographic "fingerprints" of the executables that remain the same regardless of the file name or location.) and certificates.

The only way (that I know) to bypass Software Restriction Policies in Windows XP, is using a secondary logon account (start with "Run As").

link|improve this answer
Software Restriction Policies works very well, and I can't believe more people don't use it. Combined w/ keeping users running as limited user accounts you can stop most "end running" of the IT department w/ respect to user-"installed" software. Using it in a "default permit" manner w/ hash rules is silly and easy to bypass, but using it in a "default deny" manner is quite powerful. I thought I'd try it with digital signatures sometime, but we've ended up never needing it. Path rules and limited user accounts have been enough. Give it a try in a lab setting-- you'll like it. – Evan Anderson Jun 7 '09 at 16:41
If I could give a +2 here I would. You want Software Restriction Policies. It's good stuff. – Evan Anderson Jun 8 '09 at 19:10
If you have Win7 Enterprise or Ultimate SKUs available in your environment you want to use AppLocker instead. – Brian Reiter Dec 1 '10 at 13:33
feedback
up vote 1 down vote

Coming in Windows 7 Enterprise & Server 2008 R2: AppLocker

I saw a demo of this at a recent TechNet Conference. You can restrict / allow based on the folowing characteristics of the executable:

-Path Rules

-Hash Rules

-Publisher Rules

Using the above rules together, you can "ensure that programs can't be executed from %TEMP%, that programs couldn't just be launched from cmd or start commands, or from within other programs?"

More info here.

Anapologetos

link|improve this answer
This sounds like a fancy rebranding of what is already possible, based on the link I provided, which doesnt necessarily stop the workarounds I mentioned – Bill Gray Jun 7 '09 at 19:29
Bill, with Hash Rules, as mentioned mine, and in another answer, it does not matter where the exe is run, what privilege level, etc. If it matches a "restricted" hashed exe, it will not run. – Josh Brower Jun 7 '09 at 20:34
What you seem to be talking about is a blacklist of hashed exe's, which is impossible. I'm asking if it is possible to launch an untrusted exe from a trusted exe(cmd.exe) or via rundll or such – Bill Gray Jun 7 '09 at 22:30
1  
Bill, I was not meaning neccesarily a restricted hash blacklist, though this is possible (and would be useful in certain environments). "AppLocker’s management tools are optimized towards creating an “allow list” of applications i.e. the list of applications that are allowed to run. Applications not on the allow list are blocked by the system." You create policies, "using publisher rules for signed binaries and hash rules for any unsigned binaries it might encounter." It doesnt matter where or how it is run, because Applocker sits at such a low level. Source: tinyurl.com/otdo8a – Josh Brower Jun 8 '09 at 0:16
Anapologetos, that does seem quite similar to what is already available in the link I posted, and does not show why it would not be possible to get around it by simply launching via the start command, or calling the program via a dll or such – Bill Gray Jun 8 '09 at 1:30
show 1 more comment
feedback
up vote 0 down vote

A public lab at our university apparently uses this policy in a Vista environment, but it doesn't seem to be completely restricted. I'm not sure what the rules are. Portable putty works from my desktop, for instance. One time I wanted to run the simple lame executable from my desktop to encode a wave file and it wouldn't run.

link|improve this answer
feedback
up vote 0 down vote

I am personally not a big fan, but McAfee Enterprise 8.5i (and prob others) will allow you to easily create custom rules that restrict where .exe's fire off from.

link|improve this answer
In my experience such commercial tools are easily bypassed, e.g. by simply running the program from within cmd.exe – Bill Gray Jun 8 '09 at 1:25
@Bill Gray. That's not case with Software Restriction Policies or AppLocker (the re-do of SFP for Win7). AppLocker even has a facility to control what DLLs will execute as well as script execution for Batch, WSH and PowerShell engines. You can't bypass the execution policy. AppLocker is muuuuuuuch easier to configure than SFP. The default rulesets are pretty close to what you would want. – Brian Reiter Dec 1 '10 at 13:31
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.