New to LUA + SRP

I have been reading this thread, but ...

Not sure what you mean... Rmus, can you elaborate, please?

I am running XP Pro SP3

Description of the Software Restriction Policies in Windows XP > http://support.microsoft.com/default.aspx?scid=kb;en-us;310791

 

This is a registry value that corresponds to an Internet Zone setting, which can be set from within the Internet Options dialogue. It is no trick or mystical tweak, it is there for all to see. The registry method allows you to quickly set the value with a couple registry files rather than going into the dialogue to do this. A batch file would be even quicker if one wanted to do so.

Kees refers to the sequence. The 1806 value is actually "Miscellaneous: Launching applications and unsafe files". The setting you use, whether from the dialogue or manually setting it via a .reg file, dictates what happens when you attempt to download and/or launch certain files. The setting is supposed to help security by either denying the download of certain files (IE) or by utilizing an Alternate Data Stream (ADS), which flags the file as having originated from the Internet Zone. Depending on the setting then of value 1806, files that originate from the Internet Zone will be disallowed to execute, even from Windows Explorer. So, in the sequence of events, the 1806 value would be active before SRP would be.

SRP uses the CreateProcess or CreateProcessAsUser functions. In the sequence then, it seems that if the 1806 value is found to allow the action (executing), then the CreateProcess function is called, and then as part of the CreateProcess procedure the SAFER registry keys are checked. The SAFER registry locations are hard coded into CreateProcess/CreateProcessAsUser, so that even if you don't have a GP (XP Home/Vista Home), the function will look at that registry location to see if there exists any SAFER (SRP) values, and if they exist, the proper checks are performed and actions taken.

True. If you use SRP as an Admin, you must enable the value that SRP applies to all users INCLUDING Administrators.

Using the default ruleset, paths to ANY file in c:\program files and c:\windows are allowed. If one uses SRP from an Admin account, you must enable SRP for admins as well as users. If you then set the default rule to DENY, the Admin can still run all programs installed or existing in these 2 default directories, but all other executable filetypes would be denied. This would really mean denied, as there would no longer be a RunAs feature to allow the Admin to execute something, all is seriously denied.

Yes, true too. In fact, if you institute default deny using SRP, you MUST have a directory existing in which you can execute from. Using program files or windows might work, but it would be much easier to have one directory elsewhere to execute from. If you were to install a new application it could be placed there to run the installer from. It leaves no room for absolute protection though, for more than one reason. First, although improbable, an exploit could be ran from that directory as there would not be any restrictions to it. But more importantly most likely would be the fact that all aplications would be ran at Admin rights, UNLESS you restricted them by using something like DropMyRights or the Basic User setting of SRP. Even though there would be a default deny, the processes running at admin rights would copy/download to c:\program files or c:\windows, and then have full access using root granted by running as admin.

I am not saying you can't or should not run as admin with SRP, I did it for a long time, and never had an issue. I did not use a default deny as admin though, only selectively reduced the rights of key applications.

The use of LUA is not simply to restrict access to directories, much of the inbuilt OS features rely heavily upon it. It ranges from COM objects to DACL/SACL settings on files and folders, and registry keys/hives. In XP there were some annoyances when Running As an admin because XP was not really geared towards running in "user space". Things got wierd when you used LUA and RunAs, and throwing SRP into the mix, especially when on a network with fileservers and server/client applications only made it worse. On Vista/7, things are much much better.

Sul.

 

Re: Old to LUA

Agree. I did for years with XP and up until three days ago with Win 7. Having had a Standard account for three days, I'm going back with Admin account. Running Win 7 Admin user account with UAC at max asking for credentials and SRP denying all Admins included(except a few hash rules), I see very little benefit with Standard account. I know that a Standard account provides more security but with what I do from day to day as the single user of my pc, I don't need the Standard user account.

Exactly.

I do two things, one is to make a few hash rules for your most needed, my other thing is what I do for installing a trusted/clean app from a denied location. I use two protected bat files to turn SRP off and back on again after the install. It's much quicker that way than entering into Local Security.

 

thanks Sully.
that was very informative.

i think it is easier for a noob like me to run my daily stuff as a Standard User.
with SRP, UAC and SUA on i dont get prompted too often by either UAC or SRP.

login in and out is very quick as well.

many tnx to everyone who chipped in this thread!

 

Hello, Tarnak,

Yes, I'll be happy to elaborate. This is not a recommendation. It's just the way I have set it up.

The "two clicks" refer to setting the Security Level and the Enforcement.

1. I Open to the "Local Security Policy" as described in the article you cited

2. I Right-click on "Software Restriction Policies" and select to create new policies.

3. I d-click on 'Enforcement' in the right pane and check as shown:



My reason for the Users setting is from this recommendation:

http://www.mechbgon.com/srp/index.html

I'm not recommending this for anyone else -- each person needs to consider what's best in each individual setup.

4. I d-click on 'Security Levels' in the right pane and r-click on 'Disallowed' and select as Default as shown:



That is the basic setting I use. I keep things very simple.

You need to experiment to see how else you might configure things to suit your needs.

My needs are to stop any remote code execution exploits from succeeding. The principal attack vectors are:

1) Browser

2) USB

3) Malware embedded in documents that I might encounter.

I have a few more tests here:

http://urs2.net/rsj/computing/tests/srp

Let me know if you have any other questions. If you want much more than what I have configured, you'll probably have to consult the learned experts here at Wilders!

regards,

-rich

 

--snip--

Thanks, Sul, for your explanations, but I'm afraid they are beyond my comprehension. Perhaps it's because I just don't see a need in my situation for all of that tweaking, so I haven't bothered to delve into the innards of this stuff as you and Kees have!

I've shown how basic SRP has taken care of the common remote code execution exploits, which is all I really want it to do.

My only other security product now (besides a firewall) is Deep Freeze. You may know that member SpikeyB also uses SRP + Deep Freeze, and he has done much testing of remote code execution exploits for me in the past and nothing has ever succeeded.

I rather admired his very simple, basic security setup! Now I'm giving it a go!

regards,

-rich

 

This is similar to what Deep Freeze users do: we have to have at least one other partition unfrozen so we can have stuff that is not discarded on reboot!

My second partition has a Utility directory, so a Path Rule in SRP lets stuff execute from that location.

regards,

-rich

 

@ Rmus

The info/links i posted about SRP for XP Home were for two reasons. Firstly to show it can be done, and secondly i thought you knew some people with that OS who might benefit from it.

Re - Lazy

Don't know about being lazy but i'm all for making things easier too

Well that makes things a lot clearer Thanks I already have IE6 locked down Fully & have for years since 98SE days, but i use FF mainly now.

It's interesting to see how people try to achieve the same/similar end result differently.

 

Yes, I'm aware of that. What provoked me a certain confusion was what you said:

For some reason, I thought you were saying to include administrators to SRP restrictions, because UAC/similar would still allow to elevate.

 

Hi Rmus...thanks for your comprehensive reply with images.

However, mine looks nothing like your image... don't know if that means anything.

 

Hello Rich
I believe your screenshot does not show your actual policy. It is excluding Administrators, which you mention as being your default account.
That setting would let your admin account execute any executable, anywhere.
The recommendation on http://www.mechbgon.com/srp/index.html (a great resource!) assumes you're using a LUA for your everyday tasks, and an admin account to.. well, administer the computer. That setting makes sure you have no restrictions when admin, to install programs, update, and so on.

That picture shows that SRP is disabled on your computer, or rather, no policies are being enforced. To enable them, do as Rich says:

 

As Pedro says, you have to tell Windows to create new policies. I couldn't show a screenshot since mine were already enabled!

regards,

-rich

 

Hi Pedro,

I was wondering if anyone would notice this!

I saw it mentioned in a discussion elsewhere, but I had already run tests from my default user account which is an Admin account, and nothing can execute outside of the default permitted directories, as I've shown in my screenshots in previous posts.


regards,

-rich

 

Now my head hurts. I don't get it.

 

I share the feeling.

@Rmus, can you clarify something. You are logging into your "normal" account, which is a member of the Administrators group, correct?

You are applying SRP to all software files INCLUDING dlls?

You are applying SRP to all users EXCEPT local administrators?

You have set the default SRP action to DISALLOW?

At least your screenshots show it that way.

I ask because you stated

which is easy to understand, you are using an Admin account with SRP. But then you state

It leaves me wondering, if you settings are as shown/stated, how can nothing execute outside of the default permitted directories if you are logged in as Administrator, yet Administrators are excluded from SRP actions? Perhaps you have omitted your current settings, which would likely be the same as above stated except for the option to apply SRP to all users INCLUDING administrator accounts?

Curiosity kills the cat you know

EDIT: I have not really used default deny as an admin, only in testing and playing. Have you had to make any exclusions at all when using SRP to default deny as admin?

Sul.

 

Rmus' SRP setup also confuses me as to why his admin account is restricted.

BTW Rmus, you want to run as full admin using SRP, but admins are not meant to be restricted by a default-deny policy. IMO, it is the responsible and right way to run as a limited or standard user. I can't imagine an enterprise environment where all employees are allowed to run as full admin just because UAC is set to maximum, although I do know it works for you and others because of your abilities. With SuRun it is very easy and convenient to run as standard user for those who frequently need to elevate programs and Windows functionality.

I have also experimenting with AppLocker and it can work quite nicely, although, as I've mentioned before, I see no reason to restrict the admin account. Anyone and everyone using Windows should have minimum two accounts (sorry to make this sound mandated): one admin and the other standard, and work primarily from the standard account.

BTW, only a few years ago I was one of those who would scoff at those who recommended running limited/standard, thinking it was overkill, almost sissy-like, but these days I'm a huge proponent of this practice.

 

I've done some testing of SRP in my Win7x64 vm, using the same security levels and enforcement as Rmus, and my results seem to mirror his results - that is, nothing is allowed to execute outside the specified paths, even from the admin account as the screenshot shows. Of note, it was necessary for me to create an additional path rule for the ProgramFiles(x86) directory, otherwise I could not launch programs residing there.

One problem, however, is that with path rules, anything malicious getting inadvertently written to the allowed directories can launch, although UAC should alert to anything attempting to write there in the first place. Although I'm against running as full-time admin, it can certainly be done in a safe manner by even a reasonably competent individual.

 

UAC was on I suppose? I believe Rmus is using XP Pro.

 

Well, I'm sure you are not a cat, so I'll venture to clarify by starting over.

Now, I'm 'kinda nervous' because I feel on the spot, and I'm not so knowledgeable about this stuff, so you learned experts be nice if you see something I'm doing wrong.

My Lap is a Toshiba Satellite Pro with Win XP PRO SP3.

First I open secpol.msc, create new policies, and configure as shown for "All USers."



Next, I switch to my LUA:



Then I attempt to run a batch file from Start|Run and it is blocked because my batch files reside in my Utility Directory on my D Partition:



Then I switch to my default account which is Administrator, and change the Enforcement to "all users except local administrators"
and attempt to run the same batch file:






From comments made in this thread, this is evidently not correct action for this configuration. Others seem to agree, as you can see in the references below.

regards,

-rich

__________________________
REFERENCES

SRP (Software Restriction Policies) blocking local Administrator
http://www.sevenforums.com/system-s...on-policies-blocking-local-administrator.html

Software Restriction Policy blocks local admins
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Windows/Windows_7/Q_26937889.html

SRP all users except local administrators is not working
http://social.technet.microsoft.com.../thread/d81d5b44-1809-4aad-954e-722c99d6bf26/

 

Hi wat0114,

I've seen this statement in other places, and I'm curious as to how this could happen; more specifically, what type of exploit could do this.

thanks,

rich

 

You have always been impartial and courteous.. something I am quite sure you will be shown in return.. at least from me

Besides, what can one really say to something that is out of the ordinary? I for one can only watch and listen, maybe take an angle or two from it, hopefully.

Typically, you would enable the option (apply to all users excluding admins) when using LUA. In this manner, when logged into LUA, you would have no rights to execute that .bat file. However, to make life a bit easier for users, admins would be allowed. By using the RunAs feature (in XP), you could log in as LUA, right click the .bat, and RunAs an admin (after giving credentials). This could allow the .bat file to be ran then conveniently from the LUA account without having to log off/log back on. One would not "typically" want to enable the (apply to all users INCLUDING admins) because you would then have no convenient way RunAs something, or as you elude to, you would have to login as an admin, then change the policy setting back to (all users excluding admins).

I wonder though why you see an admin account being denied execution of that .bat file when you have SRP set to (apply to all users EXCLUDING admins). The way it should work is that when you log into the admin account, and try to execute that .bat file, you are allowed because that setting is supposed to do just that.

Maybe this is due to the Group Policy not updating/refreshing after you change that value. So you log in as LUA, get denied execution of the .bat file (as expected), then log into Admin, change that policy setting to "exclude admins", but it has not yet taken effect, and you are therefore still denied execution of that .bat file.

Maybe you will see different behaviour if you were to log into admin, change that setting like you stated, then logged out and back in again, or rebooted. Then try to execute that .bat file, and it should allow you as an admin to do so. At least, that is the way I see it work on my XP systems. Maybe you have something different going on.

Sul.

 

My head is starting to spin!... I think I will retreat into my foxhole.

 

Rmus,

Every time you change SRP rules you need to log off and log in again for the change to take effect.

 

OK, good point. Thanks for your analysis!

I rebooted and Deep Freeze clears everything so I can start over.

This time, after configuring to include "ALL users except Local Administrators" I stay logged in my default account and programs on my D partition are still blocked.

So, there is something else going on!

rich

 

Could Deep Freeze, somehow, have a part in this somewhat "awkward" situation?

I remember that when I played with SRP sometime ago, I actually rebooted my system so that SRP would be properly applied.

Deep Freeze seems to be one of those tools that make the system go back to a clean state, am I correct? At least, from what you mention above.

Maybe my guess is wrong, but if the settings are not being properly implemented, when you switch from one account to the other, then I'd say a reboot would be required, in order for SRP settings to apply. But, Deep Freeze is restoring everything back, right?

You could try doing it in a virtual machine, if you could... or some other machine without Deep Freeze or similar.

Again, just a very wild guess. I'm intrigued by it!!!