Problem using SRP in c:\windows\temp

I have a default deny software restriction policy in place, with path rules allowing unrestricted access to the windows and program files folders. I have just set up some additional path rules restricting access to various locations in windows, for example c:\windows\temp.

While testing things from an un-elevated command prompt, I am denied access if I try to execute by typing the full path name. However I can execute from c:\windows\temp if I actually navigate there. Can anyone else using SRP in W7 x64 do this? If not, then what am I doing wrong?

 

Are you logged in as a standard user? Or are you an administrator. I believe SRP won't run in tandem with UAC. I believe the un-elevated command prompt is different, but with applocker I have access to everything...

 

I'm logged in as a standard user and open a standard command prompt (ie. NOT Run As Admin). SRP works as expected and prevents executions from a command prompt in other restricted locations, both when the full path is used and when the folder is navigated to. For some reason, in windows\temp even though I cannot access the files using a DIR Command, I can still execute them.

There must be something going on which is beyond my fairly limited understanding of things, and maybe UAC does have something to do with it? Hopefully one of our resident SRP gurus has the answer.

 

You have an SRP deny rule on C:\windows\temp\* , right? If so, that simply should not happen. Not sure what is going on, but if I were you, I'd try re-creating your rules and seeing if that helps..

EDIT: also, if you are logged on as a standard user, I'm not sure you'd be given read access to C:\windows\temp either.. so it may be that you are running as an Administrator..

 

Hi hpmnick, thanks for your continued interest.

Yes I have the deny rule applied to c:\windows\temp and have tried all combinations of \, *, *.* etc. On your suggestion I removed and then re-created all SRP policies, but still no cigar.

I have several user accounts and a separate admin account so am definitely not logged in as admin. In fact even from an admin account, if you don't choose Run As Admin for a command prompt it will start un-elevated.

If I try to access c:\windows\temp from windows explorer, I am denied access, as expected. From a c:\ command prompt if I type the full path to the executable I get the message "Access is denied". I can navigate to c:\windows\temp using the CD command, but if I type a DIR command I get the message "File not found". All of these messages suggest to me that basic file security permissions are kicking in.

The thing that is puzzling me is that once I have used the CD commands to get to c:\windows\temp I can type the name of the executable and it will run; no file security restrictions - but more importantly no SRP restriction.

Can someone else who uses SRP on a win7 x64 machine please try this and see if they get the same result?

Cheers

 

I have had similar issues with SRP.

1) Are you using SRP or applocker? If the latter make sure the "Apply to administrators" (says something like that ) box is check too.

2) Apply DLL restrictions as well.

3) Does SRP work in your other denied folders? If yes I recommend applying Low Integrity and No Execute permissions to the folder for all users EXCEPT administrator group.

 

Hi x942. To answer your questions:

1) Using SRP. Have Win7 Pro so no applocker available.

2) Yes DLL restrictions are applied.

3) Yes SRP works in other denied folders, using the same executable (notepad.exe by the way). This situation appears to be unique to c:\windows\temp.

I have suspected it may have something to do with folder permissions, but haven't been willing to change them in case I break something. Plus I assume the default settings are set that way by MS for a good reason - or am I being naive?

 

They are fine for the average user. I believe Temp is one of those weird zones in windows. I have the same problem with it. Maybe Sully can come to our rescue and post here. But my work around and theory is this:

Temp file NEEDS to execute files for various reasons (I.E installing software - most software extracts here and executes other scripts), so maybe SRP can't block temp.

My work around is Low Integrity. This way nothing launched in temp can assume Admin privs or access higher integrity processes, BUT installers can still execute scripts from in temp.

I did this using icacls.exe in win 7.

I hope Sully can way in here as he is far more knowledgeable than I with SRP.

 

I agree that the Temp folder needs to be able to execute files when installing software, but one of the major points of having standard user accounts and admin accounts is that standard users are not supposed to be able to install software. Allowing a user to simply copy executables to the windows temp folder and then execute them from a command prompt punches a huge hole in SRP.

I guess you can restrict access to cmd.exe for users via SRP, but would that also be able to stop a script or malicious program from performing the same actions? I am starting to get out of my depth when it comes to understanding such things.

On my old XP machine I used Sully's PGS to implement SRP and as far as I can remember was able to block executions in c:\windows\temp. Something has either changed with SRP implementation in W7 or I'm doing something wrong (which is probably still very likely ).

All opinions gratefully accepted!

 

Agreed! I am going to look over my settings and see if I missed something. A user error is probably the issue here Could you post a screen shot of your gpedit settings (SRP)? I would like to compare it to mine.

 

Woo-hoo I get to post some screenshots! Here they are (I hope!!)

 

Thanks,

That is exactly how I have mine set up. I tried enabling the "All Users" box but still no go. (Even though I as LUA). I am going to re-install windows 7 Ultimate and post back in a bit with any updates/solutions.

 

While I'm not happy that you are having issues with SRP; I am glad that I'm not the only one

Even if I set a path rule to block the actual executable in the Windows\Temp folder it still runs. As specific path rules take precedence over less specific ones, this should definitely override the unrestricted status of the Windows folder.

Unless we are still missing something, this has to be either a bug in SRP or behaviour by design.

 

I just did a quick test in win7 ult 64bit, in VMware, everything at defaults.

I made an account who is a member of USERS only.

I put standard SRP rules in place
.. deny users but allow admins
.. deny is default action
.. remove .lnk from file types
.. 2 default rules
.. one custom rule - c:\windows\temp -- disallow

Open explorer, navigate to temp, prompted for credentials. Input my LUA account credentials, and still denied from executing, and that account even owns the executable.

Can still execute from other windows directories. Denied other directories -- this using explorer, so all seems good there.

Start CMD as user only. Can perform DIR on temp and can CD to temp. Can see the binary, but cannot execute it. Cannot execute if
.. c:\windows>temp\file.exe
.. c:\windows\temp>file.exe
.. c:\>c:\windows\temp\file.exe

So in no case does my file execute using SRP, even when navigating to it from explorer and having to input credentials.

Things to think about....

Possible that in your case, cmd.exe is living within an allowed directory, and hierarchy is for some reason not applying. Copy cmd.exe to other places and execute that to see if this is the case.

Possible that TrustedInstaller owns cmd.exe, and might be influencing somehow. Take ownership of cmd.exe and give to Admin group or your user and see what might happen.

I don't know why you are seeing what you see. All I did was create a standard user, create the default SRP rules, set to make sure admins can execute, set to make disallow the default action, remove .lnk filetype and set a custom path to temp to disallow. There are only 2 rules otherwise for SRP, those being the default registry keys that point to windows and program files. No wildcards, nothing.

Sorry, probably not what you wanted to hear, but I did it twice to verify, and both times the results are the same.

AFAIK the only thing different in win7 SRP is the create process call that no longer will work with the Basic User setting. Why they provided the option in win7 when it does not work makes perfect sense considering it works in XP but was never shown

NOTE: I did not see the behaviour you mentioned of not being able to DIR the temp dir. Every time I tried, it showed me the contents without issue.

Sul.

 

Thanks heaps for your input Sully. My results seem totally bizarre then. You CAN see the binary but NOT execute it - I CAN'T see the binary but CAN execute it!!

I don't know if this helps narrow things down or not, but if I drag notepad.exe to windows\temp in my regular admin account (not windows hidden admin) and then start non-elevated command prompt from admin, then I do see the same behaviour you outlined. However if I log off and start command prompt from a user account, then I CAN execute the binary. More disturbing is that I can drag the file to windows\temp within the user account and still also execute it (by CD commanding to the location).

My head is starting to hurt trying to understand all this

 

Ok, I think I've figured it out

Standard Users (on the 2 PCs in my house) have special permissions to c:\windows\temp: consisting of Traverse/Execute File; Create Files/Write Data and Create Folders/Append Data. If I add the permission to List Folder/Read Data then SRP works in all situations and blocks file execution.

My theory is that if the User doesn't have permission to read data in the folder, then the OS can't "see" the executable, in which case a path rule cannot work.

The question I have now is how many other folders have the same special permissions as windows\temp? Is there a way to list all permissions without manually checking the properties of every folder?

Thanks again Sully, your attempts to re-create the problem helped "the penny drop" for me.

 

I can't test that for win 7, but I know that isn't the case for XP... even if you can't read the file, you still can't run it with SRP on. I know this for a fact, because that is how it would work with those user writable folders in C:\windows. Normally (without SRP), you wouldn't have read access, but you'd be able to execute them.. Adding exceptions for those directories in SRP would then prevent this execution..

I'd like to try this in Windows 7, but then I'dhave to remove my applocker rules..

 

Thanks Sully

Very useful information there

Awesome! it works for me now! Seems strange that it didn't work before, I didn't think ACL could effect SRP as the service runs at system permissions.

Maybe it's a weird bug or something...

Anyways thanks for the update

 

I have never investigated it, but it would be interesting to know:

When a right of some kind is given/denied for a group, members of that group have blanket coverage.

If an object/container gives a USER specific rights (or denies), and some of those rights are of the kind normally reserved for a member of the admins group, how do rules then apply?

Are rules processed strictly along who is a member of what group? Or are the DACL flags the actual determining factor?

It sounds like, from what you describe, that SRP is not purely restricting by group membership, but by rights, at least in some instances. Maybe. Don't know exactly, but it will be a good project for a rainy day to find out

Sul.

EDIT: It would also be nice to recreate what you mentioned here, and see how ownership becomes involved, how this can circumvent an SRP rule. TrustedInstaller has caused some issues with certain things, maybe there is something in ownership plus DACL rights. Who knows.

 

I did the same test as Sully, also in VMWare 7, Win7x64 O/S, same SRP settings and additional C:\windows\temp rule and I can't execute the file I dropped in their as admin, when I CD from a non-elevated cmd. The directory also has the same 3 special permissions that Zorak has.

*EDIT*

I even went so far as to duplicate exactly the rules Zorak has, but the executable still won't launch.

 

Cool - glad I could help

Yes, my admittedly feeble understanding of these things suggests that is quite plausible.

It will have to be one of your rainy days, as you are more up to that task than I am


Until now I haven't (knowingly) changed any of the default permissions/rights on either of the PCs at my end. This situation may be a "heads up" to others using SRP in W7 Pro to deny execution to users in windows\temp. Your path rule may not be providing the protection you expected

Thanks everyone for your input

 

I initially couldn't execute either if the file was dropped as an admin. However if I dropped it as a user, then that same user could execute.

Just to summarise my initial findings:

Drop file as Admin > execute from cmd as Admin > SRP prevents

Drop file as Admin > execute as User from cmd > Permissions prevent (Access Denied)

Drop file as User > execute as User > file executes as long as cmd prompt is c:\windows\temp

 

Can you re-check the permissions again under the "Security" tab after you drop the file there as a user? You will probably see that the user account from which you dropped the file now has full permissions for that directory.

This happens to me when I do this, elevating the write access through UAC, of course. I don't understand why full permissions would then be granted to the standard account just because of a UAC "Write" elevation

Just some observations:

- I see that the full permissions are granted only after I drop the file in the Temp folder.

- If I use Surun's right-click context selection "SuRun Explorer here" to allow dropping of the file, the account is not granted full permissions to the directory.

- Well, take a look at the screenshot of the UAC prompt...

 

If I try to check the properties of windows\temp as a User after copying the executable as a User I am still denied access. Doesn't this suggest that the User Account has not been given full permission?

Also check my post above, I edited it to try and clarify things a bit, but it occurred after your reply (you were too quick!)

 

Yes, I saw your clarifications. Take a look at my last post where I've attached a screenshot.

You can't "right-click ->Properties -> Security" the directory to check the permissions? see edited comments below.

*EDIT*

This is exactly how it's behaving with my testing, too. UAC, at least in my case, is applying permanent full permissions for the Standard account i'm dropping the file from once i elevate with the password. SuRun, OTH, only applies it temporarily.

I would say yes, you are correct. What level are you using UAC at? Mine's at maximum.