New to LUA + SRP

Well, if that were the case, you wouldn't think anything would be blocked until I rebooted, but as you can see in the above post, I configured SRP and immediately it blocked w/o rebooting.

EDIT: also, note in my references that others have had this situation.

regards,

-rich

 

I do remember I had to reboot for SRP to apply properly when changing settings, despite the fact it was blocking straightaway. So, I just figured of sharing it. Because one thing is certain, what you're experiencing isn't normal. By excluding admins, they shouldn't be blocked. It would be contradictory.

 

This is not always so, but sometimes it works as you describe. But normally the settings take place once you apply them.

If you work without the group policy by using the registry (remember SRP works even without group policy), a registry refresh is often required - this means logging off/logging on, or just killing the shell (explorer.exe) and restarting it. However, when I was creating my PGS tool I noticed that simply by changing the value for "all software files including dlls" one way or the other would actually refresh the registry somehow so you did not need to logoff/reboot.

Rmus, I just tested on my XP machine I recently setup with LUA and SRP. Doing it the way you describe, my executables on another drive, another partition or a network share are all allowed by the admin, even after logging into the admin account and changing from "apply to all users" to "apply to all users excluding admins", without rebooting/logging off. The changes happen as soon as you "apply" them.

I don't know what you have going on, possibly m00nbl00d is correct that DeepFreeze is somehow tampering with the correct process. But I do know that on every machine I have ever set SRP on, when an admin is excluded, he can run as normal with no blocking, unless there exists some ACL or (in the case of vista/7) an Integrity Level.

Sul.

 

Of course not easily, at least in Win7 with UAC at max, unless it's permitted by the user running as admin. in my post #42 I state:

In XP running as admin the user can easily write it to these directories with no warning put up by the O/S. By inadvertently, I mean the user could do this, though not likely someone who knows what they're doing. As for an exploit doing this in the admin account, maybe not so easy at all, though I'm no expert in this area.

This happened in my case as well when testing in Win7.

Yes, on max. Is UAC supposed to affect how SRP functions?

EDIT: Well, i've answered my own question. It does affect SRP, because when I slide the UAC level to "Never notify", then reboot, SRP works as expected for the admin; I can launch the wfc.exe file from the admin desktop. When I put it back to max or default, then reboot, SRP blocks the file from launching.

Then why am I, as I mentioned in post #42, getting the same behavior, albeit with Win7? Screenshot shows I've selected All users except local administrators.

 

Thanks for the info Sully.

btw, Sully, I have a question regarding PGS and Windows 7 I've asked here.

 

OK, that was the problem.

The reason I never rebooted during these tests is that Deep Freeze would wipe the slate clean as if nothing were configured.

So, I disabled Deep Freeze, set the configurations, the programs were blocked, as you describe; then I rebooted and now the programs run.

Thanks to everyone for helping with the detective work! This has been an educational experience.

Now, can someone show me how to revert my Local Security Settings Window to look like it did before creating new policies:



(With Deep Freeze off, the Window retains the last set configuration)

thanks,

-rich

 

wat0144: https://www.wilderssecurity.com/showpost.php?p=1825485&postcount=5

 

I assume you mean why do you change the policy setting to exclude admins but it does not engage directly? Don't know exactly TBH. I have set SRP many many times, both from the secpol.msc interface as well as from registry, and seen times when it applied directly and others when it had to be forced by some method (gpudate/logoff/reboot). One thing you could try is to do it exactly as you are doing it - log into LUA, do things, log out, log into admin, change the setting to exclude admins, apply ---- then set value to apply to all files excluding dlls, apply, then toggle that back to all files including dlls, apply (this assumes you started with all files including dlls) -- this is what has worked for me in the past, but I cannot explain why it does so. I have found that it is more often I don't have to logoff than I do for SRP to engage.

I think you are saying you want to get the SRP policies in the default state, where they don't exist? I believe if memory serves correctly, that you only have to delete the SAFER registry key (and all subkeys) for this to happen.
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer]
although I cannot remember if that worked with GPO, but I believe so. It definately works when using registry only for SRP control.

Sul.

 

Okay, thank you for that reminder I guess that makes sense then that because UAC places the standard user token on the application, SRP see this app run that way, so it applies the restrictions to it even though it's run from the admin account?

@Sully, what do you think about this? I guess this must explain it, that UAC directly influences how SRP behaves. BTW, AppLocker, what I normally use in Win7, is not influenced by UAC this way. It also obviously does not explain Rmus' situation because he's using XP pro. never mind, I just saw what it was in his case .

 

Don't know if this helps...(since I have never set up a Software Restriction Policy)

but I found this > Re: Deleting software restriction policies from XP - http://www.tech-archive.net/Archive...ic.windows.group_policy/2006-12/msg00026.html

Also, see - Re: Reset GP back to "out of box" ?? - http://www.tech-archive.net/Archive...ic.windows.group_policy/2006-12/msg00033.html

 

Yes, it is.

 

?? I have UAC set to max, use AppLocker but it (AppLocker) does not block unlisted executables launched from user space in the admin account. Maybe I'm missing some point here, but I see it as behaving differently in this case than SRP does.

 

Maybe you have a publisher rule in place? Try running a program without digital signature from desktop.

 

Then, your AppLocker is misbehaving... Just in case, I did test it (There's been a long time since I last actually made direct use of the administrator account!!!), and AppLocker blocked my attemptive to run an installer.

I have UAC settings set to maximum.

-edit-

Do what user Sadeghi85 suggested. That might be it. Also, don't forget that AppLocker allows Microsoft installers to run. That means that, if an application installs to user space, then AppLocker won't stop it. It also means that if will install to system level, UAC will ask for credentials... or silently allow it... whatever the user tweaks are.

 

I use mostly Publisher and hash rules, an only a few path rules. Actually, what it could be is that I don't use the "Built-in administrator" for rules. Rather, I use the administrator account that I created when set up Windows. Maybe later I'll test some scenarios in the vm. All I can tell you guys is that my AppLocker setup behaves exactly as I expect it to.

 

That's the reason. You can create rules for standard users too, when you create rules for a specific user you throw UAC out of equation, it will intervene only when a program needs Admin rights.

When UAC is enabled, the admin user gets a standard user token, so things that are allowed for Administrators group are disallowed for admin and standard users unless specifically allowed(or another group that the standard user is a member of e.g. Users is allowed).

Did that make sense?

 

Yes, I think that makes sense. I have everything allowed for: BUILTIN\Administrators as well as MadisonB\Admin (the administrator account I created for myself at Windows set up). Without this latter rule, AppLocker was blocking file execution in my admin account. The scenario is similar in my vm setup. I remember having to do this to achieve the expected behavior from AppLocker, but I didn't know what the reason was. So UAC token does affect both SRP and AppLocker. Thank you Sadeghi for clarifying this

 

Thanks, but those don't seem to apply to my situation.

I tried that but it didn't work.

regards,

-rich

 

You're welcome

I trained myself to right click and run as admin, it might seem an extra step but then I'm expecting the UAC prompt so it's not annoying plus some installers don't prompt for elevation if double clicked so right clicking and running as admin sometimes saves a bit of time too, therefore I'm fine with the default rules.

Although atm I'm using standard account mainly because I like SuRun.

 

SuRun is excellent. I use it on the real system