Hello, On Server 2008 we were successfully using Software Restriction Policies to prevent child processes such as cmd.exe (any anything else for that matter) being started by services running under custom service user accounts that we created in the Guest group. With Server 2008 R2, Software Restriction Policies does not seem to affect services. I am able to start a service under a guest account even if the executable is explicitly denied in Software Restriction Policies. Any assistance with this is greatly appreciated. Thanks in advance

Hi, I perform the following test on a Windows Server 2008 R2 system: 1. Copy notepad.exe file to c:\test folder. 2. Configure a SRP policy to disallow c:\test\notepad.exe. 3. Confirm that user cannot run this file. 4. Create Scheduled Task to run c:\test\notepad.exe. Normal user with administrator rights failed to run. Only SYSTEM account could run c:\test\notepad.exe. The SRP works as expected. Could you let us know more about your environment and detailed steps so that we could try to reproduce it in our test system. Also, the Enforcement properties in SRP has "Apply software restriction policies to the following: 1. All software files except libraries (such DLLs) 2. All software files", which was selected? Thanks.This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hello, "All software files except libraries (such DLLs)" was selected. I repeated the test that you performed and SRP worked as expected with any SRP configuration and scheduled tasks (and I also tried the runas command). SRP only seems to not be affecting services. To reproduce this problem, create a service and configure it to log on as an account that is affected by SRP. The service should be able to start regardless of SRP and in our case, the service process can also start child processes such as cmd.exe. SRP configuration: http://i30.tinypic.com/349fm8l.png Service configuration: http://i28.tinypic.com/x4oi00.png Thank you

Thank you for update. I create a service as below to test and I can reproduce the problem on R2. We will do more research. sc create cmmd binPath= "C:\windows\system32\cmd.exe /k c:\abc\notepad.exe" Regards.This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi Brock, We're still taking a look at this here, but in the meantime, we wanted to ask: Have you tried using an AppLocker policy instead, and if so, what were the results? AppLocker is ultimately the replacement for Software Restriction Policies - for Windows 7 and Windows Server 2008 R2, it's what we would normally recommend using. More info about AppLocker here: http://technet.microsoft.com/en-us/library/dd723678(WS.10).aspx David Beach - Microsoft Online Community Support

Hello David, Thank you for looking into this. I have tried using AppLocker and it had the same results as Software Restriction Policies (affecting everything as it should except for services).

So from taking a closer look at this yesterday evening, and talking with a few folks, it seems that this behavior in Windows Server 2008 R2 is actually by design - neither Software Restriction Policies nor AppLocker Policies will apply to services. This surprised us here in support, so we're following up to try and find out why that change was made, and if there's another, better way for you to accomplish what you're trying to do in Windows Server 2008 R2. I'll post more info when I have it!David Beach - Microsoft Online Community Support

And to close the loop a little here. This functionality was changed in Windows Server 2008 R2 because of application compatibility concerns, and because it didn't really do anything to enhance security of the operating system. If a service has system-level access, it's entirely possible for it to compromise the underlying OS without having to spawn a child process in order to do it. We made some other changes in the architecture of Windows Server 2008 R2 to help increase the security of processes in general. You can read about some of those changes here: http://blogs.technet.com/b/askperf/archive/2009/10/05/windows-7-windows-server-2008-r2-console-host.aspxDavid Beach - Microsoft Online Community Support

Okay, thank you. Do you have any recommendations for securing service processes in a shared hosting environment? Perhaps modifying NTFS permissions for cmd.exe would suffice.

Anyone?

Hi Brock, I'll check around and see if I can find whether we've written any whitepapers or documentation for you. In general we don't recommend modifying NTFS permissions on system executables, however.David Beach - Microsoft Online Community Support

So, is there not a way to keep services from running unwanted processes in 2008 R2? I have a shared hosting environment, and I can't have users running anything except the service that they are allowed to run.

This is also my problem.

Hi folks, I ran your questions by some of our security developers and the overwhelming answer that they came back with was "it depends". For Windows Server 2008 R2, we ship in a relatively hardened state - you don't have a lot of leeway as an administrator to further secure things without potentially impairing functionality. This is a far cry from the Windows 2000 days when the OS was very open and the first thing you would do as an administrator is apply a security template. On the current OS, when you install a role or feature, it's going to install with the most secure settings that we can apply and still insure that it still works properly. The same applies for system executables - they're essentially as protected as you can make them without causing stability problems. Most of our security enhancements since Windows 2003 have come not from modifying things at the file system level, but actually modifying the way the Windows Executive works to make it less vulnerable to attack by a rogue process or application. When you're dealing with third-party applications, such as something you might be hosting for a customer, things are trickier. Very few operations that an application might perform in Windows Server 2008 R2 require system-level access, but older applications may have been built for older operating systems where that access was needed, and use older, less secure methods to accomplish what they're trying to do. Ultimately, installing anything on a server is assuming some measure of risk, and if there are vulnerabilities in the application you installed, there's always a potential that the vulnerability could be exploited to try and compromise the hosting OS. Our best practice in terms of hosting is really just to be very strict with what you allow your customers to install. Establish a set of baseline security requirements that every application must meet, such as running in least-privileged user mode, or not allowing interaction with other services and applications except those explicitly defined. Of course, you'll also want to require that application developers test and support their applications, so that if something does go wrong (either from a security or from a stability perspective) you have a path to resolution. At any rate, the best document that we have is really the Informational Security whitepaper, which discusses in brief how to manage hosting securely. I realize that the document is short on technical specifics, but it's really designed to help you work out the best strategy for your environment and your unique needs, rather than to contain "how to's" or checklists. You can download that document here: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=648AF985-4AFA-419D-8597-ECA7CBA01C8F&displaylang=en David Beach - Microsoft Online Community Support