Maximising Windows XP security with LUA and SRP

It would seem that once you quit using GP to put SRP rules in place, only reloading the registry makes them active. However, I have noted that when you first place rules manually with reg files, then reload the registry, often if you change a rule from a restrict to allow state, it takes place immediately. However, adding any new ones or modifying something allowed to restricted, you need to relaod the registry again.

Killing explorer is by far the easiest method I know of. The only downfall, and you need to watch for it, is sometimes tray programs running from autostart locations will still be running, and in fact can then run 2 instances. This can cause some issues. I wrote my own programs at times to do different startup functions for situations such as this. But once you get SRP setup, I suppose those tools really aren't needed. FYI on this issue.

Sul.

 

I'm not clear, is this mean to be an example of a prog that LU can install?

Tried it anyway, and as expected it won't install as LU on my system, due to the SRP. If you think I'm being unfair, tell me where on C: to put the installer and I'll try again.

I even gave it a second chance. I have a gaping hole in my SRP - a tmp folder on D: where writing and execution is possible. Copied and ran the installer with an open internet connection as LU from there. Nothing happened.

UPDATE: Just checked the error logs and found:
Access to C:\DOCUME~1\<LUA>\LOCALS~1\Temp\GUM1.tmp\GoogleUpdate.exe has been restricted by your Administrator by the default software restriction policy level.

 

Let's simplify it. As a User, aka LUA, you have default restrictions. You may NOT create or modify files in
c:\
c:\windows
c:\program files

and you may not modify or create values in the registry under certain keys.

As a User, you are ALLOWED to read or execute files in
c:\
c:\windows
c:\program files

and most registry keys.

As a User, you are ALLOWED to create/modify/execute/delete files in
c:\documents and settings\< User Name>

there are some areas in your user profile that are restricted, but most of it is open for you to do as you please.

The issue with installing chrome under LUA, is that as a User, you have the right to install things to your user profile.. your My Documents area. If any program were to write it's files there, it is allowed. If it does not place files in c:\, c:\windows or c:\program files it is OK. If it does not try to create/modify registry values in keys that are restricted, it is OK.

So the issue of whether chrome installs as a User or LUA is largely dependent on if it is only writing to your allowed areas. Of course, using SRP or other security settings may change what is the normal default values for a User.

Does this explain it for you?

Sul.

 

@Sul. This is such a long thread. I was really referring back to this https://www.wilderssecurity.com/showpost.php?p=1410003&postcount=128

I wonder now if he means LUA without SRP.

For me, the key issue is whether the default file permissions in a new setup represent a significant security hole. Much has been made of the need to tighten them, but I am using pretty much a default setup and they seem sound.

Think I understand the LUA+SRP approach. Looking for ways to test it.

I came across a ref to a prog which I can't find now (the ref, I mean, never could find the prog) - I think by Mark Russinovich of Sysinternals which claimed to be able to breach SRP.

 

I am not completely sure on what Zopzop is referring to, I think it is a some wierd glitch he found. I know it was said that (I think) he would have that issue even if he created a new user which was not an admin account prior to user.

Either way, it should be, as a User, that you can create/modify to your %userprofile% directories. Vista or 7, can't remember, had some group that was even lower than a User I think, so perhaps this is the issue. I have not played with Vista extensively, so can't say for sure. But if that is true, and there is some distinction between LUA and a User, it could be so.

The breaching of SRP was mentioned on many sites, but it is more of a POC (proof of concept) than an actual breach currently being used. It has been gone over that overall since so many don't use SRP, it would still be deemed as pretty secure.

SRP remember is Software Restrictions. It is not under the context of LUA particuarly used to limit rights. True it can be used to disallow access to running software in a directory, but not to limit access to the directory. To say, SRP should not be causing chrome to not install under normal circumstances. SRP could certainly be used limit the execution of the chrome installer.

Think of it like this, and I don't know your level of knowledge, that SRP can not allow any of the files listed in it's file extension list (.exe, .inf, .txt etc). So you lock a folder down to where those things cannot run. But if you can run chrome installer from somewhere, it is not SRP then that restricts whether chrome can install to your allowed directories, but your group/user permissions.

AFAIK anyway. Someone can surely correct me on that if I am wrong. I have never tried to get SRP to deny container access, only object execution within a container. Sorry, object being file and container being directory.

Sul.

 

Yes in my example with Chrome, I was referring to LUA without SRP. The confusion is that in this post https://www.wilderssecurity.com/showpost.php?p=1449963&postcount=166 there are two quotes of ZopZop that say different things - I was referring to the lower one.

 

Sully, actually there is a Catch-22 at the root of the C:\drive in a LUA. At the root of the C:\drive in a LUA, you CAN create folders and add files inside and modify those files, but you CANNOT create single files by themselves without being inside a folder. Also, individual files CANNOT be moved from somewhere else to the root of the C:\drive, but they CAN be moved if they are placed inside a folder first. Weird.

 

Not so much a catch22, as simply understanding the design of the restriction.

It is that, you have containers and objects. Containers are directories or folders, depending how you call them. Objects are files. The default security template, technically says this:

Code:

"c:\program files", 2, "D:P(A;CIOI;GRGX;;;BU)(A;CIOI;GRGWGXSD;;;PU)(A;CIOI;GA;;;BA)(A;CIOI;GA;;;SY)(A;CIOI;GA;;;CO)"

Where:

Code:

(A;OICI;FA;;;BA) full control for BUILTIN\Administrators, inherited by objects and containers 

(A;OICI;FA;;;SY) full control for NT AUTHORITY\SYSTEM, inherited by objects and containers 

(A;;FA;;;LA) Non-inherited, full control for the local Administrator. This ACE provides access only to this folder. The reason this ACE is here is because the local Administrator was the user who created this directory. 

(A;OICIIO;GA;;;CO) Full control for Creator/Owner, inherited only, inherited by both objects and containers. This ACE provides no rights to the recycler directory, but does provide them on any directories created underneath. 

(A;OICI;0x1200a9;;;BU) Read and execute for BUILTIN\Users, inherited by objects and containers. 

(A;CI;LC;;;BU) Create files for BUILTIN\Users, inherited by folders only 

(A;CI;DC;;;BU) Create folders, for BUILTIN\Users, inherited by folders only

CI = Container Inherit .. The ACE will be inherited by directories.
OI = Object Inherit .. The ACE will be inherited by files.
IO = Inherit Only .. The ACE does not apply to the current file/directory.

What does this mean? It is simple. So let us examine what the XP Pro default security template has to say:

Code:

a="c:\program files", 2, "D:P(A;CIOI;GRGX;;;BU)(A;CIOI;GRGWGXSD;;;PU)(A;CIOI;GA;;;BA)(A;CIOI;GA;;;SY)(A;CIOI;GA;;;CO)"


b9="c:\windows", 2, "D:P(A;CIOI;GRGX;;;BU)(A;CIOI;GRGWGXSD;;;PU)(A;CIOI;GA;;;BA)(A;CIOI;GA;;;SY)(A;CIOI;GA;;;CO)"

So let us break it down

(A;OICI;FA;;;BA)
This is for builtin Admins, it says
A = access allowed
OICI = object inheritable, container inheritables (files & directories inherit permissions)
FA = File all access (basically full access)

(A;OICI;FA;;;SY)
This is for the system, which like admin has full access

(A;OICIIO;GA;;;CO)
This is for the creator/owner, it says
A = access allowed
OICIIO = object inherit, container inherit, inherit only
GA = Generic all (this is a generic form of FA, but not as full blown)

(A;OICI;GRGX;;;BU)
And here we have the builtin User, it says
A = access allowed
OICI = object inheritable, container inheritables (files & directories inherit permissions)
GR = Generic Read
GX = Generic Execute

Notice the lack of the needed values:
FA = would give Users full access (read/create/modify/delete/execute)
GW = would give Users write access
GA = would give Users general access similar to FA ( I believe though not to change ownership)

So, is this a catch22? Where the default security explicitly states that windows and program files, the User can only read and execute, as dicated by GRGX.

There ARE restrictions on everything that will be found in c: root normally. Take for example the file autoexec.bat, here is it's security:

Code:

1="c:\autoexec.bat", 2, "D:P(A;;GRGX;;;BU)(A;;GRGWGXSD;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"

You should note here that again, a User only has GRGX (read and execute).

I don't think it is a catch22. The User is allowed to create custom directories. Because c: root is not restricted to creating new containers or objects you may create them. You may not modify anything MS put there at install, as they are protected. As well, you can examine the default security template and see that almost everything MS places in the OS during install is protected so a user can only have GRGX rights.

It is by design. But it does take some understanding of the security polices in place to fully comprehend why these things take place.

Sorry this is so technical, but it is the correct answer to this.

Sul.

 

It is definitely not a by-default catch 22. But it is really easy to obtain this:

- SRP takes care of execution prevention outside of windows and program directories.
- The only thing to do is to make sure users others than admins have only a read and execute right over these 2 folders, that admin is the owner of everything in these two folders and that there is no inheritance possible of user rights inside these two folders whatever happens. Then only configuration remains safe and stable.

 

Catch-22 was probably not the right phrase to use. I was simply trying to point out that your quote above, the way it is written, is not true and could confuse a reader.

 

Ok. Let us clear up any discrepancies then. As I am not sure exactly on what "the way it is written, is not true and could confuse a reader" is referring to, let's then restate the whole issue of what a User/LUA is allowed or not allowed to do. Just for as you say, new readers who may only be first beginning this LUA journey.

Users have rights to create or modify anything in thier 'My Documents' area, for the most part.

Users have rights to create custom directories in the c:\ root. Typically they cannot create files in the c:\ root though.

Users have rights to read and execute nearly anything in program files and windows directories.

Users may not modify any file or directory within any other user profile but thier own.

Users may not modify any file or directory in 'program files' or 'windows' directories.

Therefore, a User account is simplisticly restricted to only modifying custom made directories and contents or items within thier user profile directories.

Maximizing LUA with SRP, as Lucy simplified above, means that SRP can help control execution of programs in custom made directories or the user profile directories. These are the only areas a user has the capability to create/modify/delete, so SRP is targeting these potential weak spots that remain.

Please do say if this is not the condensed definition that would work for most readers who do not already understand the rights policies.

I hope this is what you were meaning ParadigmShift

Sul.

 

Gpdisable

 

@Sul, on the chrome install thing, looks as if you covered it pretty well here (Post 170)

Also, noticed your newish SRP testing thread, and will be visiting soon!

@MrBrian, thanks for that. I finally found the original ref, posts 78, 79 earlier in this thread.

 

On the subject of file permissions, would it be fair to say:
(1) we have various conflicting reports on LUA powers, plus legacy issues, probably from converted admin a/cs, that can be tricky to unpick;
(2) if you follow tlu's guidelines here:

https://www.wilderssecurity.com/showpost.php?p=1201866&postcount=146

you will get a reasonable result in line with this analysis

@Lucy, Sul - What about System rights in those two?

I have now applied the tlu "rules" in full. Plus, for completeness, I temporarily made LU admin, and ran the reg changes from the LUA.

It didn't quite work for me - I found the procedure stripped out all but admin permissions from C:\Prog... (yet not, oddly from C:\Windows...). But once rights are restored for SYSTEM (full) and USERS (read and execute) in C:\Prog... everything appears to work.

 

Don't worry about them. Let them as they are.

Make sure you remove inheritance though.

 

Would an XP Home SP3 user have to do anything other than merging the reg file to make this work?

 

It would seem from what tests I have done and papers I have looked at, that the specific processes that SRP is 'examining' are fundamental to XP and Vista. The registry values are checked for when certain processes are called. Therefore, if you only have registry values you merge, they will be used if in context and settings are correct.

If you were on XP Pro anyway, and you used the local policy to make some SRP rules, they not only reside in the registry, but also in the group policy (or local policy). The group policy is a database of sorts, although I wish I found the documentation to be able to manipulate it. Anyway, if you have a rule made from the group policy side, and you delete the registry value, the policy still lists the rules you made for SRP, but the rules are no longer functioning.

So in all of my tests, all that is needed is the registry values. There will be a tool that helps those without knowledge or nervous with registry work to get SRP working in versions of vista and xp that have no group policy or means to manipulate the SRP.

Sul.

 

SUMMARY OF REG TWEAK METHOD FOR IMPLEMENTING SRP ON XP HOME

XP Home with (preferably for me) one active Admin A/C and one or more LUA(s).

1. As LU made Admin temporarily, install KAFU.EXE. (If you have more than one LUA, repeat for each)
2. AS ADMIN install tlu REG TWEAK. You may want to change the default exception folder.
3. AS ADMIN install FileSecPatch.exe, to get the security tab.
4. Tighten file permissions, see this thread post #189, etc

I'm not sure the order is vital, but if you do all 4, you should get a reasonable result.

 

OK, I merged tlu .reg with no restart. Good news, it worked and to my surprise was very powerful at disallowing. Bad news, restarted PC and it now does not work. Any ideas as to why? I've checked the registry and it matches tlu's reg file.

 

Are you admin? tlu's reg will allow admin, and exclude an additional directory. You can either (1) change to a LUA or (2) change a registry setting to block for everyone. For 2 you also need to log off/log in or restart explorer to 'enable' the changes.

Note that, while it will work in admin, it is not the same thing as LUA + SRP, since you can write where you can execute.

 

Yes I am admin but I have changed the entry in the registry. Good news, I just now restarted the PC and it's back working. One more question, the

Code:

ItemData"="c:\\NewApps

Is this for overiding the security and allowing of the specified path? If yes, then is a restart/logoff needed for that to work?
Thanks

 

Yes, it tells Windows to allow programs in that directory to execute.

In general, i think/guess every time you change an SRP related setting, explorer.exe needs a restart (manually or by log off/in), or some other method i'm not aware of.
The issue i found with the manual method is that, if you have another user logged in, explorer is killed but not restarted (for that user). Beats me, i didn't spend much time on that.

 

I have found something else out about SRP with registry. If you open regedit as admin, and you are in LUA logged in, you can make (or merge) a registry file to create a rule, for example to block IE (deny).

If you then change the value TransparentEnabled to say 0. Now try and see if the block IE is working. It should be. Now, change the IE deny rule to an allow rule. It is still blocked. But again, change the value of TransparentEnabled to 1 or 2, and now the allow rule for IE should be active.

This seems to work with both TransparentEnabled and PolicyScope. Maybe others, have not tried. Perhaps this could reload your values without restarting the shell.

I have also tried it quickly from admin account, but it seems to only work in LUA, as when you modify the HKLM safer values, you are doing so from admin not user. Even though the users shell is not stopped, it must have some effect of reloading the registry. I will snoop around some more and see what the trigger is when time permits.

Sul.

 

I know how to make a new path rule (reg tweak method), but how do I make it block rather than allow execution. A value in "SaferFlags"?

 

You have different values for different levels of restriction:
Basically 262144 for allowed, 131072 for limited and 0 for forbidden: