Problem using SRP in c:\windows\temp

I never got a UAC prompt when dropping the file in Temp. I only got one when trying to click on Temp to read the contents. My UAC is at the default level (one below max).

 

No, I am still asked for admin permission to view the folder's security properties. Prior to adding List Folder/Read Data to my User Permissions I was unable to even click on the Temp folder to view the contents. Now I can view the contents un-elevated but still don't have total control. But SRP is now able to function properly for me.

 

Okay, sorry for the confusion; I now understand what you did.

I tried the same thing, dropping it simply without elevating to read/write to the folder with UAC, then tried to execute after running non-elevated cmd.exe, CD to the c:\windows\temp location, then typed name of executable (wfc.exe) but it did not execute on me.

Good that you resolved it this way, but I wonder why it was necessary for you when SRP still blocks in mine and Sully's case?

It is still odd to me that UAC grants permanent full permissions after elevating. SuRun only grants temporary permissions - the preferred behaviour, imo anyway.

 

Hmmmm.. if you did all that from within a Standard User Account then that doesn't correspond to what i was seeing. Did you get a SRP message or a denied access message?

Mines at default, if this is the only difference between our set-ups then maybe UAC is having some effect here?

 

I just get: "wfc.exe is not recognized as an internal or external command, operable program, or batch file"

My apologies. That was my real system's UAC level I looked at In the VM it's at Default.

Since that message did not seem SRP-related, I decided to delete the SRP policy and test again, and I get the same message as above, so this means SRP is having no effect on the executable not launching for me. This is rather confusing??

 

Ah-Ha! Just as I suspected When SRP kicks in you get a specific warning message and an entry in your Event Log.

I've just been using notepad.exe to test, as it seemed the simplest thing to use. By the way, thanks for your testing - this is all very interesting

 

You're welcome! This is intriguing to me so I don't mind testing this.

Right, so I started suspecting something was wrong (I haven't used SRP in ages, as I prefer AppLocker instead).

Well you know what? I tried notepad.exe this time and now I can execute - just as you can - from cmd after Cd to the temp directory. Very interesting!

 

Excellent! That's now three of us who can replicate this.

Now that the heavy hitters like you and Sully are involved things should get even more interesting

 

Sully's the heavy hitter. I'm just the water boy

 

I'd like you all to rename notepad this time... call it notepad2 . I have a feeling that you will not be able to run this file then..

Let me know.

 

Correct, I get "notepad2.exe is not recognized..." non-srp generated message.

 

Maybe I see what's happening, although I don't understand why; This time I renamed wfc.exe to notepad.exe, then copied it to the c:\windows\temp directory, then tried to launch from cmd at same location, and the real notepad.exe under the c:\windows\system32 (Process Explorer proves this) directory opened, and not the renamed wfc.exe dropped in c:\windows\temp directory.

*EDIT*

Maybe it makes sense now. notepad.exe resides in a directory path, c:\windows\system32, that is allowed by the SRP policy, and launching it from cmd.exe works, regardless of where one CD's to as long as one CD's to an allowed directory path . I can CD to c:\program files, for example, and I can still launch notepad.exe. If I copy notepad.exe to the desktop (standard user account still), and I CD from the cmd line to "c:\users\vmware7-test\desktop", then try to launch notepad.exe, I am disallowed with an SRP-generated message.

 

Whoa, my head is spinning

Yes, at first I thought it might have something to do with the "original" notepad.exe still being in an executable path, but very early on in proceedings I tried launching copies of notepad.exe from various folders which were disallowed by default in SRP, and every time SRP denied execution. If the "original" notepad.exe was being called from an allowed location, then surely SRP wouldn't be denying it?

A common factor in all these folders was the permission for a User to be able to READ the contents of the folder. Windows\Temp at default settings did not have this permission. Once I gave Users permission to READ (no other extra permissions than default), SRP suddenly began to work on Windows\Temp.

The other common factor with the folders where SRP worked was that they were disallowed by default. I still however think the ability to READ the contents of a folder has something to do with the way SRP processes path rules - at least when the folder is nested within an allowed location.

I don't have a virtual machine to test on - and my family would be in uproar if I broke our real machine - so I am a bit hesitant to do too much tinkering. But if I get the chance I will create some new folders with and without read permissions, located within and without c:\windows and see how SRP behaves. (Unless someone beats me to it - hint hint

 

Yes, but this is not testing SRP, it is showing other processes at work. One of the fundamental points of using default deny SRP is to deny Users the ability to execute anything, renamed or not, legitimate or not, from any location which has WRITE permission.

 

THIS IS REALLY LONG, SO UNLESS YOU REALLY REALLY REALLY WANT TO KNOW ALL THE SORDID DETAILS, YOU MIGHT WANT TO JUST GO TO BED NOW


First off, I have noted in the past that applications such as notepad and cmd sometimes exhibit strange behaviour if copied. It seems no matter where you put notepad, it still spawns from windir, at least many times in win7 I have seen this happen when I was testing. I stopped using applications in windir and started creating my own little "message box" applications so I know nothing within the OS is going to influence anything.

So here is some testing for you, and the results.

It is important to fully understand what SHOULD be happening. Maybe you know, maybe you don't, but I will refresh you I guess just in case

In Vista/7, a LUA is a user who is a member of the USERS group and ALSO of the ADMINISTRATORS group. We all know this, and we know that this user has 2 security tokens, one is of a user level, one is of an admin level. If you are using UAC, then you normally are using the user level token, and UAC can "easily" help you elevate by switching to the admin level token when needed. If you do not use UAC then you always use the admin level token.

SUA is exactly like prior versions (XP,2k,NT) where a user is a member of the USERS group only, and thus never gets elevated. However, you do get some nice prompts that ask for the username and password of an admin account.

When the OS is installed, every file and folder is assigned rights. Files are called OBJECTS and folders or directories are called CONTAINERS. In XP there was a .inf file that defined every object, container and registry key that was important to the OS, and when they were created during install, they each got a set of rights (DACL or SACL) assigned to them. It is the same (but different) in win7. The point is, every file created during install has a set of rights applied to it. It is universal (within reason). You should not have "willy nilly" rights all over the place that are different and allow certain users to have or not have certain rights. It just doesn't work that way, or at least in all the messing with that stuff I have done, I have never seen it happen, and that is actually quite a bit.

Anyway, as each of these objects/containers is created and rights assigned, there are also some other flags that are used. They are inheritance flags (and a few others that are not worth trying to explain). Some items are set to give inheritance, some to recieve, at differing levels. It is the same in the registry too. Sometimes you might expect something created to be such and such, but because of how the inheritance is set on a top level directory (somewhere up the chain), things might not be what you expect. But this is standard stuff, starting at root all the way down to sys32. There should not be anything different on my install or your install really.

Next you have ownership (which can be included in .inf syntax, although I have never found the documentation that fully describes the flags ). In win7 we have TrustedInstaller on a lot of things, to keep things all safe and cozy. Normally in windows when you create a file, whoever creates it is the owner. The owner of a file has full rights to it, even if it exists in a place they normally do not have rights to. In XP I used to set an option so that the group Administrators was always the owner of newly created files. I have seen in win7 that sometimes that is the default, but sometimes it is not the default (just tonight I drag/drop some files I just made into win7 and the owner was the VM user, not the admins group).

That is a lot of stuff going on, and not understanding any of it can confuse you as to why things happen.

What should happen is pretty simple though.

If you are a user, you are off-limits to MODIFY things in places like windows and program files. Your rights as a user are limited to user profile areas (thus the LIMITED user account). If you create a new directory like c:\myDir, there are no rules to apply to it from the OS. It was not known about during install, thus got no rights applied. By default c: does not apply inheritance to such things. Creating it in other directories is a different story sometimes.

Anyway, now that LUA is actually Admin/User in win7, things get a bit wierd. But at its heart, LUA still works. If you are denying users something, then a LUA account will also be denied, BUT you can have UAC get you past this because that is its job.

As a SUA, you are restricted the way you should be, meaning there is no way short of entering credentials that you can elevate something.

Now, lets look at what is going on with the topics in this thread.

I have created 4 applications. Each simply spawns a message box, like this:
app 1 - "owned by user"
app 2 - "owned by admins" - actually owned by admins group
app 3 - "copied by user" - actually owned by admins group
app 4 - "copied by admin" - actually owned by admins group

I have a default win7 ultimate x64 install in VMware.
I create a user account named USER.
From admin account (logged in as LUA) I create the SRP rules. I apply disallow as default action, I leave the 2 default rules alone, I create a custom path rule to deny c:\windows\temp, and finally I apply SRP to all users EXCEPT admins. Standard stuff.

I have a copy of the 4 apps on LUA and SUA desktop. I have a shortcut to cmd.exe and a shortcut to the temp directory on the desktops as well.

From SUA:
cannot open temp.lnk - asks for username password to continue (I cancel)
cannot browse to temp via explorer - asks for username password again (I cancel)
*here we see the rights coming into play, or so one would think-- but
* users have rights to traverse/execute and create/write/append
* my account "user" is not even listed
* my LUA account IS listed (with full rights)
* USERS are listed (with rights stated above)

* A USER should be able to traverse/execute anywhere within windows, but ONLY modify in special instances like the temp directory
* yet a user cannot even browse to this directory -- SRP is the culprit? It would seem so.
* But if you were to remove .exe from the list of filetypes SRP applies to, what then? (read further)

As SUA, using CMD non-elevated
allowed to CD to temp folder
cannot DIR temp folder at all (even though group USERS have traverse/read/write etc rights)
but, a SUA is allowed to COPY files to the temp dir (so rights work in that respect)
however, SUA cannot execute files when sitting in temp, in fact the .exe is not even found
so when you do this c:\windows\temp>filename.exe -- it says it is not a recognized command
if you do this c:\>c:\windows\temp\filename.exe -- then it says "access denied"
if you remove .exe from filetypes of SRP, this does not change, you still cannot execute files, at all

As LUA:
can browse to temp directory using temp.lnk
can browse to temp using explorer
you cannot execute files from either way, nor can you if you remove .exe from the SRP filetype list

As LUA, using CMD non-elevated:
you can CD to temp
you can DIR temp
when you do this c:\windows\temp>filename.exe - you get a denied by group policy prompt, BUT, you at least get a prompt, unlike SUA where it would not even recoagnize it as a valid command
when you do this c:\>c:\windows\temp\filename.exe - you get the same denied by group policy prompt

_________________________

Now, all of this was denied no matter who owned the binaries and no matter who put the binaries in the temp folder. Ownership in this test did not matter at all. Neither did removing .exe, which I was suprised at. I rebooted twice to verify, but that is what happened.

Next I copied notepad.exe to temp from SUA, and could not execute it from SUA (got the unknown command, had to do full path to get an access denied prompt, same as above). From LUA, it was the same, except as already noted, as long as my prompt as already residing at c:\windows\temp, I did not have to put a full path to get a denied prompt, just typing notepad.exe was enough.

If from either SUA or LUA via CMD prompt I typed in notepad.exe (as long as I wasn't already in c:\windows\temp), then the real notepad.exe would spawn.



My conclusion --- lol, I don't really have one. I don't use UAC all that much, and I know it allows you to circumvent this type of thing in LUA, and as the others have said, evidentily remembers the answer. I don't see a point in testing what happens when you do something from an elevated prompt, as it introduces work-arounds from how a standard user/admin situation normally works. It may be that when you elevate using UAC things get changed or something.

One area to inspect would be what rights exactly does the temp directory have prior to SRP and after. Another would be to examine with ProcessExplorer what the security details might be on some things prior to and after engaging SRP.

The end result, for me at least, is almost exactly what I should expect to see -- LUA and SUA both should get denied because both have a restricted user security token. LUA should be treated the same as SUA with the exception that UAC will help you get around the restrictions. The only thing that I thought was out of the ordinary was that removing .exe from the SRP filetypes list "should" have allowed any .exe to execute. But, maybe something changed in win7 in that area.

Another good test would be to create a directory, apply an SRP path rule to disallow, and see if the behaviour is different. It could be a parent directory is influencing things (although I did not see that in the rights anywhere) or just simply that win7 puts some other restrictions on certain things. It could also be the "lack" of rules for the "user" account that did it. Lack of any rights is usually pure denial. If the account is a member of a group, it should not matter, but the complete lack of anything on the account itself might come into play here.

So, there you have it, a whole lot of reading about a lot of the same-same for the most part. I dig this sort of thing, and now it is forever archived in the anals of Wilders, for all to see and maybe for someone to learn a little bit -- or maybe they get bored to death and marry a stranger in Vegas

Sul.

 

Sort of. It doesn't matter if you have write permission or not, or at least it should not.

As a standard user, you should be allowed to traverse and execute almost anywhere, yet SRP is designed to allow you to traverse, just not execute. For some reason though, as this thread notices, there is now a difference between SUA and LUA. In XP, SRP would not deny you from going into a directory at all, only deny executing without an exclusion.

Sul.

 

Holy Moly, I knew I would end up falling behind in all this at some point. I will probably be able to provide an adequate response in, oh maybe about... a year!!

Just for starters can I clarify the LUA, SUA thing. In Win7 the "regular" admin account (ie. not the hidden admin account, but the one created when installing Windows) is the LUA?. User accounts are the SUA's?

I will try and devote some more time to getting my head around your post tommorrow. I'm just about to head down to my local club to watch some stand-up and consume some adult beverages; hopefully this activity is more suited to my talents

I really appreciate the time you've spent trying to help this mere mortal work things out

 

I have spent a lot of time messing with stuff like rights and how they get applied and why. It takes a bit of time to learn, but once it sinks in how the rights are put in place at install time, and what the defualt rights are, it really helps to understand strange quirks like what you have found. Aside from that, it helps me understand where my in-securities are and has generated a bit of $$$ over the years by working on others machines.

I should probably study more on UAC and just how it might effect things from what was normal. So, maybe in a year I will understand that

Sul.

 

Actually, I've been trying to figure out why Sully keeps making such an interesting distinction.

LUA - Limited User Account/Least-privilege User Account - used in Windows XP.
SUA - Standard User Account - same as LUA, but it's how Vista/7 calls such accounts.

In what concerns that administrator account with UAC? It simply happens that there are two tokens in place - Administrator token and User (limited user/standard user) token.

I still haven't found any official information by Microsoft calling LUA to an Administrator account with UAC.

I don't know if anything has changed (regarding how it's called), but such Administrator account with UAC is called Protected Administrator.

Source: http://msdn.microsoft.com/en-us/library/aa480194.aspx#leastprivlh_topic6

As you may see, they even treat the standard user account as least-privilege user account/limited user account (LUA). Why not? They're the same. lol... Maybe they still hadn't thought of SUA back then... Anyway, you get the point. I hope!

It's a documentation from the Longhorn (Vista), but I believe that, unless something changed (Please, anyone is free to direct me to proper info!), that's how it should be treated, both accounts.

-edit-

By the way, very interesting thread. Windows does have some oddities. I've experienced them with AppLocker, such as DLLs not allowed to be executed (in user space), allowed execution.

 

I don't know for sure, but I do believe there is a difference between the account which is admin/user aka LUA and the account which is only user aka SUA.

There must be some difference. Consider the following.

With SRP creating a default deny in a standard situation, and UAC enabled, and a custom path rule as in this thread to disallow executions in c:\windows\temp...

The normal LUA account can browse to temp directory with no warnings. The SUA account is not allowed without elevating via name/password.

The normal LUA can DIR the temp directory from command prompt. The SUA cannot use DIR at all from command prompt. (for the temp directory, DIR is available elsewise)

The normal LUA can, when residing at the path c:\windows\temp, pass in an executable (ie. somefile.exe) that lives in temp, and the error "group policy denied" is given. The SUA, when residing at the path c:\windows\temp cannot pass an executable name that exists in temp. If he does so, then you get an error "unrecognized command" even though the file actually lives there. Further, to get any feeling of what LUA gets, you must type in the full path to the executable (ie. c:\windows\temp\filename.exe), and then you get a different prompt, which is simply "access denied" rather than the one the LUA gets about group policies.

I don't know why they would be different, they are both members of the users group, and the LUA simply is also a member of the admins group. Something about having both tokens though maybe is what causes different things to happen. One thing is for sure, they are not identical in how they work. Well, maybe they are, but I can't find any reasons why this type of thing is happening yet.

Sul.

 

That's not the distinction I was talking about.

I mean, I couldn't figure out (by now) why you call the Protected Administrator LUA. I could never find any documentation by Microsoft giving that name to it. I've only seen Protected Administrator.

Have you read some documentation calling LUA to the Protected Administrator account?

 

This was exactly my thoughts. Its simply the original notepad.exe running. The way Windows operates is that it first looks for the program in your current directory. If it finds it, it executes it there. In your cases, by hiding the real notepad in your current working directory (by denying list/read access), then Windows searches for notepad withing the PATH listing. It will find it in Windows\system32 and run the real notepad.

I would say this is not a bug unless you are able to do it with another name for your executable. Rename notepad.exe testme.exe, or something else, and you will get an access denied or file not found..

 

Wow! some nice follow-up posts since last night, and I'll jump in later when time permits (at work now ) to read some of them, especially Sully's "epic" post

 

I didn't actually coin those terms, just seen them around. LUA used to be user account, now with UAC having references to LUA, there must have been some confusion as to what non UAC LUA was, and thus SUA came to mean a standard old user account.

It is easier IMO to use these terms so there is a distinction between the hybrid admin/user account used with UAC and the vanilla user account.

Sul.

 

The confusion was/is probably due to this

Source: http://www.windowsecurity.com/articles/Exposing-Microsoft-Windows-7-User-Account-Control-UAC.html

I understand that. I don't see it as being much confusing, though. I see it this way:

* UAC protects the administrator account, hence the administrator account being the Protected Administrator account;

* UAC smoothens the use of a user account, which Vista/7 treats it as standard user accounts.

If we think about it, there are two types of users/user accounts: administrative user accounts and normal user accounts. Somehow, calling limited user accounts to the normal user accounts would maybe scare people the move to such type of account, due to bad experiences with Windows XP. I guess it just seemed appropriate to call them differently in Vista/7.

I personally know what you mean with LUA and SUA. I know that when you talk about about LUA, you're thinking of Admin. + UAC. But, if I didn't know you any better, I'd be confused.

It's a matter of perspective, I guess.