Software Restriction Policies in Windows 7 SP1?

[jclarkw]

:I've followed the instructions at "http://www.mechbgon.com/srp/" to set up a SRP in Windows 7 Professional SP1, and I'm confused.

First, I'm not a **complete** newbie. I am currently using an earlier version of these instructions successfully in Windows XP (before that in Win2K for years, I think). But things seem different in Win7:

You can probably skip over this first paragraph, which is here just for completeness. At least it shows that the new SRP is doing something:

1) After following the instructions, restarting (is this necessary for the change to take effect?), and logging onto the same Adminstrator account in which I did the setup, I immediately got a couple of messages (an Application Error that TpKnrres.exe wouldn't start start correctly, and a RunDLL error that BtMmHook.dll -- some ThinkPad software -- was blocked by SRP). OK, fine (except that I'm an Administrator). I went back into the Group Policy editor and changed Enforcement to allow DLLs. A new restart and login revealed no immediate errors. So far so good.

2) Still in the Administrator account, I copied notepad.exe from C:Windows\System32 to the desktop First puzzle -- When I tried to run this copy from the Administrator account by double-clicking, it did nothing at all. Even "Run as Administrator" did nothing after I acknowledged the UAC warning. Note that the original Notepad.exe still runs, and I haven't even tried running as a Standard User yet, nor have I gotten any "blocked by SRP" message!

3) Second Puzzle -- I went back into the GP editor and switched off the SRP by changing the Security Levels from "Disallowed" to "Unrestricted," restarted again, and tried both tests in (2) over with identical results. So was Win7 **already** preventing execution outside prescribed directories by **any** user?

4) Finally an uncertainty about removing the new SRP entirely: After the fact it occurred to me to see if there are any other SRPs set up, but I realized that don't know how. Can you have only one at a time? When I run GP editor again, go to Computer Configuration/Windows Settings/Security Settings/Software Restriction Policies, and right click, the options no longer include "Create New Policies" (I think it said before), but only "Delete Software Restriction Policies." Is it safe to click this? Do I delete only the one policy that I just installed?

Any guidance on what's going wrong and how to fix it would be greatly appreciated! -- jclarkw

 

[mechBgon]

Half of the Catch-22 that makes SRP effective, is that you set aside the Admin powers. The simplest approach here is to

1. max out UAC to the "Always Notify" setting
2. create a new account that has the Administrator role
3. demote your existing daily-driver account down to a Standard User

Now you can use the credentials of that new Admin account when something does need to be elevated from your Standard User baseline.

Blocking DLLs along with the other filetypes is desirable from a security standpoint, so try to stick with that. If the problematic ThinkPad software is running from an unauthorized location, you have some options:

1. is it necessary? If it's just bloatware, uninstall it.
2. If it is necessary, where is it installed to? If they put it in a location like C:\ThinkPad, you could add a Path Rule that allows execution there. To maintain SRP protection, you would want to make sure that it takes Administrator powers to put any *new* files in that location. Otherwise you've created a loophole.
3. Alternately, you could create a Hash Rule that allows those unique files to run, determined by their hash (digital thumbprint, basically).


If SRP is set up and working normally on Win7 Pro, then if you try to execute a copy of Notepad.exe from someone's desktop screen, you will get a notice saying "this program is blocked by group policy etc etc." As long as UAC is enabled, that will be the case even for a user who is a member of the Administrators group, unless they use Run As Administrator at launch, in which case SRP's "apply to all users except local administrators" would come into play and SRP wouldn't apply.

I ran into trouble with SRP setup on a factory-built computer once (a Gateway) where the factory-loaded Win7 image was Seriously Messed Up™. Gateway modified the permissions so that even a Standard User had Admin-level powers on the entire Windows directory which nullifies the Catch-22 situation... any user's software could be exploited to plant malware in a location where SRP would allow it to execute. That came to light when I ran the audit script mentioned on my SRP page. I nuked that one from orbit and installed Win7 Pro fresh from a proper Microsoft DVD.

 

[jclarkw]

Half of the Catch-22 that makes SRP effective, is that you set aside the Admin powers. The simplest approach here is to

1. max out UAC to the "Always Notify" setting
2. create a new account that has the Administrator role
3. demote your existing daily-driver account down to a Standard User

Now you can use the credentials of that new Admin account when something does need to be elevated from your Standard User baseline.

Well, I was hoping we could focus on what seems to be the fundamental problem (see my OP and below) that I can't test the SRP on Notepad.exe because I can never execute a desktop copy of it from **any** account.

Anyhow I'm close to your setup now. I set up the accounts in opposite order, Admin first and the a Standard User from which I will normally run. I verified that I cannot make any changes to the C:\Program Files directory from the Standard User account (presumably because the NTFS permissions won't let me). I then set up the SRP from the Administrator account, as I had previously under XP. Surely you are not saying I have to set it up from the Standard User account using admin privileges. If so, how do I go back? Can I just delete the SRP (as asked in my OP)?

The only real difference seems to be that UAC is set to "Default - Notify me only when programs try to make changes..." But I understood that this setting effectively became "Always notify" when running in a Standard User account. Anyhow this half of the "catch 22" should also work because of NTFS permissions (mentioned above, as it used to in XP) if nothing else. What do I have wrong here?

Blocking DLLs along with the other filetypes is desirable from a security standpoint, so try to stick with that. If the problematic ThinkPad software is running from an unauthorized location, you have some options:

1. is it necessary? If it's just bloatware, uninstall it.
2. If it is necessary, where is it installed to? If they put it in a location like C:\ThinkPad, you could add a Path Rule that allows execution there. To maintain SRP protection, you would want to make sure that it takes Administrator powers to put any *new* files in that location. Otherwise you've created a loophole.
3. Alternately, you could create a Hash Rule that allows those unique files to run, determined by their hash (digital thumbprint, basically).

OK, understood, but that will have to wait until the fundamental problem is fixed.

If SRP is set up and working normally on Win7 Pro, then if you try to execute a copy of Notepad.exe from someone's desktop screen, you will get a notice saying "this program is blocked by group policy etc etc." As long as UAC is enabled, that will be the case even for a user who is a member of the Administrators group, unless they use Run As Administrator at launch, in which case SRP's "apply to all users except local administrators" would come into play and SRP wouldn't apply.

Can you please help me understand what I see as the fundamental question? As said in my OP, I cannot execute Notepad.exe on the desktop even from the Administrator account and even with the SRP turned off. (I also cannot execute it on the desktop from the Standard User account, of course, but there not even with "Run as Administrator.") How can this be? It seems as though a super SRP is already implemented on the machine (by Lenovo?), but how can I tell. Your SRP doesn't seem to be needed (except perhaps for DLLs). Again, what am I missing here? -- jclarkw

 

[mechBgon]

I don't know exactly why your Notepad.exe result is doing that, but it shouldn't be taken as a sign that you're safe from exploits. Maybe using a non-Windows .EXE file would be a better test... here's an Adobe Reader installer:

ftp://ftp.adobe.com/pub/adobe/reader/win/11.x/11.0.06/en_US/

You might want to just delete the whole SRP and start over. To delete SRP, open up Group Policy Editor, drill down to the SRP section, and right-click Software Restriction Policy in the left-hand pane, then delete it and reboot for good measure.

You can create the SRP from either the Admin or Standard User account. It will work as intended with UAC at either the default or maximum settings, including for the Admin account unless the local security policy has been messed up by Lenovo.

If SRP does take action, it'll be recorded in the Windows logs. You can check by right-clicking Computer and choosing Manage, then go into Event Viewer > Windows Logs > Application. Yellow warning triangles with Software Restriction Policy in the title would be what you're looking for.

If SRP doesn't seem to be having any effect and you're sure you did all the steps, then in Group Policy Editor, right-click the root of the Local Group Policy tree itself, choose Properties, and make sure neither of the checkboxes is checked (that would disable parts of the policy).

 

[jclarkw]

Thanks, mechBgon, that's very helpful information. I'll try again along those lines when I get a chance... -- jclarkw

 

[jolancer]

i don't know about win7 specifically but i would assume its stopping you from exacuting notepad out of its default directory for basic protection from rootkits and such that would try and copy microsoft exacutable names. most likely not stopping other exacutables. can just save a txt files as .bat ,with the work "pause" saved. and double click it if you want to see if a its directory is exacutable. it will just open a paused cmd prompt if exacutables arn't blocked

i realize this isn't for win7 specificaly either but it does specifically answer your dll and start up apps that arn't from system root question.
http://technet.microsoft.com/en-us/library/bb457006.aspx#EGAA
http://technet.microsoft.com/en-us/library/bb457006.aspx#EKAA

as the link also shows you can use wildcards. i specifically use them for temp directory or one that has a tone of DLL's that i won't want to create a hash rule for every one.

one of my actual unrestricted path rules(truncated) so photoshop is usable from a limited user
C:\PATH\Temp\Photoshop Temp?????
i used ?s instead of a single * because its temp seems to always randomly be the same name length.

thats the same way i allow exacution of batch files from my limited user, example only /path/example????.bat can be exacuted. that way i have a variable amount of batch files for a single rule

 

[jclarkw]

The SRP is definitely working. My problem is that it's working **too** well. I'm hoping you can help me track down where this behavior is coming from and whether it's as undesirable as it appears:

... Maybe using a non-Windows .EXE file would be a better test... here's an Adobe Reader installer:

ftp://ftp.adobe.com/pub/adobe/reader/win/11.x/11.0.06/en_US/

I tried this plus another self-contained EXE file (md5sum.exe) and the simple BAT file suggested by jolancer. I tried them in several different locations including the desktop, the standard user's My Documents folder, C:\Program Files\ -- both regular and (86) since my Windows 7 is 64 bit -- and the paths of both the EXE and the DLL files mentioned in my OP as producing logon errors.

The puzzling result is that all three test files behave essentially the same way whether executed from a local administrator account or from a standard user account. (The only minor difference is that, when the Adobe installer is executed, UAC kicks in requiring a different response from the two different account types, presumably because Adobe will tamper with protected settings.) With SRP ON **neither** user can execute any of the files unless they are in one of the C:\Program Files directory trees. If SRP is OFF, both users can execute them anywhere. I double-checked that the SRP Enforcement is set for "All users except local administrators."

1) So the most important question seems to be, "Why is the SRP restricting the local administrator?" The behavior seems as though I had selected "All users" in Enforcement.

2) A related question is, "Why is there any logon issue as mentioned in the OP?" The related Lenovo software appears to be in unrestricted directories.

... You can create the SRP from either the Admin or Standard User account. It will work as intended with UAC at either the default or maximum settings, including for the Admin account unless the local security policy has been messed up by Lenovo.

If Lenovo **had** messed with the local security policy to cause the above result, where should I look for proof and possibly to correct the situation?

... If SRP does take action, it'll be recorded in the Windows logs.

...in Group Policy Editor, right-click the root of the Local Group Policy tree itself, choose Properties, and make sure neither of the checkboxes is checked (that would disable parts of the policy).

I did check these, and everything is as expected. -- jclarkw

 

[mechBgon]

With UAC enabled, even the Admin account doesn't wield Admin powers until you elevate something using a right-click > Run As Administrator. So SRP applies to all your Admin accounts just like to Standard User accounts, which actually is great since it provides a safety net when you're in your Admin account.

There are a few corner cases where this is a hangup. If you want to elevate something that doesn't have Run As Administrator on its right-click menu, like a .MSI software installer file, then the easiest method is to copy and paste it to an SRP-approved location like C:\Program Files, so SRP won't stop you from launching it (but you can still expect a UAC elevation prompt during software installation, as usual).

If you wanted to make the local Admin account exempt from SRP then you could instead apply SRP to just specific Standard User accounts on a per-account basis.

If Lenovo **had** messed with the local security policy to cause the above result, where should I look for proof and possibly to correct the situation?

Run the accesschk auditing script mentioned on my SRP page and it'll show you any loopholes that require custom Disallowed Path Rules to close. If the Lenovo software is tripping on SRP, then look in your Event Viewer logs to see what specific files are the problem and try creating custom Unrestricted rules for them. If they're files located in user space, like a user's AppData folder, and don't get updated, then Hash rules are good because they'll apply regardless of which user it is, and will protect against tampered versions of those files.

 

[jclarkw]

OK, I misunderstood about explicit elevation still being required for Administrators under UAC. Now I see that everything **except jolancer's BAT file** responds correctly to "Run as administrator" (in other words, does not require a password from an Administrator account).

The BAT file for some reason remains "blocked by group policy" even when "Run as administrator." The only ways I can find to get around this are (1) to create a "run as administrator" shortcut to it or (2) to run it from an elevated command prompt. If that's as you expect, then I can live with it.

This **should** be all I need. Thanks very much for your security advice and excellent tech support! -- jclarkw

 

[jclarkw]

YIKES!!! -- Sorry I didn't notice this before and report: Not only are those two particular startup files blocked by the "All software files" Enforcement setting in the SRP, but

**all** MS-Office 2013 applications are similarly blocked [e.g., "WINWORD.EXE - Application error: The application was unable to start correctly (0xC0000361). Click OK to close the application"], even from an Administrator account! (There appears to be a way around this, but it isn't pretty since it would require entering an administrator password anytime and MS-Office program is run by a Standard User: I can select "Run as administrator" in the right-click menu when running the application.)

I don't understand any of this, but I certainly can't live with it. Unless I can find a straightforward way to make the needed directories (at present unknown) unrestricted, I guess I'll have to live without blocking libraries in Enforcement... -- JCW2

 

[jolancer]

sorry about the BAT, im not familiar with win7, didn't know it would do that.

but SRP basically works like this.. its goal is..

If u #Execute from a dir(ex. %PROGRAMFILES% ) you cannot #Write to the dir
If u #Write to the dir(ex. %APPDATA% ) you cannot #Execute from the dir

The exceptions you make to the above rules should ideally be as specific as possible, otherwise u maybe defeating the purpose of SRP. For rule type hierarchy and variables id suggest referencing the previous link i posted.

U need to create a rule if an app needs execution rights from anywere other than /WINDOWS or /Program Files, I dunno win7 but if its like xp the most likely exceptions you'l need would come from %TEMP% or %APPDATA% both located in the user profile, which is under /Documents and settings/"name"/ in xp, i assume 7 would be similar/same

I dunno the easyst way to locate where the dir each program is trying to get execute or write privlidges, but in my case watching the %TEMP% folder during exacution solved any issue for me so didn't need to. I dunno win7 or Office13, but if there installed in the default program files dir i would assume the location Office is trying to access is somewere in your profile under /Doc and Settings/

 

[jclarkw]

...I dunno win7 but if its like xp the most likely exceptions you'l need would come from %TEMP% or %APPDATA% both located in the user profile, which is under /Documents and settings/"name"/ in xp, i assume 7 would be similar/same

I dunno the easyst way to locate where the dir each program is trying to get execute or write privlidges, but in my case watching the %TEMP% folder during exacution solved any issue for me so didn't need to.../

Thanks again for responding, jolancer. Now I've hit another wall: The help function ("?") just does nothing an any of the Office 2013 applications even when libraries are allowed in the SRP. I guess I'll really have to start learning your tricks...

One annoyance: It appears that Group Policy doesn't give you an on-screen error message, nor even always an entry in Event Viewer > Windows Logs > Application, when another program (e.g., MS Word, as opposed to a direct console command) tries to execute something out of place. Right? That would explain a lot of no-responses!

BTW, I have loved XP, but what are you planning to do after the demise its extended support next month? Windows 7 is my alternative and appears to be a lot more secure and capable; but as you can see, I'm suffering the growing pains right now...

Best Regards. -- jclarkw

 

[mechBgon]

As a fact-finding step, make an extra Path Rule for MS Office's directory and set that to Unrestricted. While it's technically redundant (since the entire parent directory is Unrestricted), that may clear it up. I'm assuming you did create an Unrestricted Path Rule for the Program Files (x86) directory, assuming you have one?

It's normal to be unable to use Run As Administrator to launch a .BAT file from userland. If you have a .BAT file, or another affected filetype, that you need to RAA, then move it to an Unrestricted directory first.

 

[jolancer]

IF its not simply a mistake like mechBgon mentioned, and he doesn't know a simpler way than bellow...

yeah i noticed that to even in xp, if its not the main exacutable trying to run during application launch it may just fail after launch due to other libraries its trying to access and not throw an SRP Event into the log.

depending on which app, it maybe easyest to start by checking designated directorys for it if any are used outside of /windows or /program files. For example, IF you didn't install the MSOcache into the default /program files directory perhaps checking were you put it and creating a temp exemption for testing may fix it. MSOcache may have nothing to do with it im just using it as example.

you could also create a Path rule hierarchy for testing, remember undefined is recursive so. for ex..

unrestricted =
Path= C:\Documents and Settings
Path= C:\Documents and Settings\"name"
Path= C:\Documents and Settings\"name"\Application Data
Path= C:\Documents and Settings\"name"\Local Settings
Path= C:\Documents and Settings\"name"\Local Settings\Application Data
Path= C:\Documents and Settings\"name"\Local Settings\Temp
Path= C:\Documents and Settings\"name"\My Documents

change those according to your profile name and win7, im not using win7. then test your app. IF it works then you can go back and delete the rules one at a time to see which path is causing you issues. Start from the top of the list tho because they are recursive by default. IF theres no obvious dir designated for your app under the problematic dir tree, you could make more paths and continue the process further into the directory tree.

IF it works don't leave the directory tree unrestricted, instead try and find the files/folders its creating or needs and specify rules as specific as possible so SRP can still remain relevant. Use wildcard names if neccessary if the folders/files are variable, but keep similarities as specific as possible so not an open ended wildcard..

example: name = file or folder
name-01
name-02
name-01.dll
name-undefinedlength.a3
Path= C:\path\name-??
Path= C:\path\name-??.dll
Path= C:\path\name-*.??

re: your xp end of support question:
In short it doesn't apply to me. The way mines setup, backed up, what i use it for, and dual/quad booted with linux. IF need be i could simply boot to linux for online and switch back. However that doesn't even seem relevant for my purposes at this point. But if you have a more specific question then it maybe easyer to answer, i feel thats a too open ended question.

 

[jclarkw]

mechBgon, jolancer -- Good thoughts both that I will try out as I can find time. Meanwhile I have feelers out in the Microsoft Office world that **might** simplify the task. (Right now I have no e-mail, so that gets priority. This kind of detective work can take a lot of time...) -- jclarkw

 

[Chiefcrowe]

For windows 8.1, what are the paths to set if I want to block my user account from running files in my Application Data and Local Settings Folders?

thanks!