Maximising Windows VISTA security with LUA and SRP (even without ultimate)

[m00nbl00d]

Things are getting creepier! I tell ya!

So, as I reported earlier, I disabled UAC, and then problems were gone. I've been all noon without UAC.

A few minutes ago I was like: What the heck, let me active it again.

Guess what? Now, when right clicking on the Desktop, everything in the context menu appears properly. I guess that, since the beginning, UAC was preventing something from doing its thing. Disabling UAC must have allowed it.

But, at the Administrator account, the warning saying that software restrictions are applied and to contact the Administrator account, still appears.

At least, is not as bad as it was. lol

[Lucy]

Originally Posted by m00nbl00d

But, at the Administrator account, the warning saying that software restrictions are applied and to contact the Administrator account, still appears.

At least, is not as bad as it was. lol

This is a totally expected and normal behaviour of SRP. As Admin runs by default as a limited user, restrictions to LUA apply to admin as well by default. That is why running as admin under Vista is totally pointless.

Please run under LUA. When you need admin credential to perform a task or install a program, simply right-click "run as admin", and voila.

[Trespasser]

I never had any trouble/problems with Vista SP2. Functioned just the same as in SP1 at least on my end. This is with "All software files" and "All users" enabled in SRP>Enforcement and a nice list of extension types in Designated File Types. I'm really puzzled by the problems you are experiencing.

The only problem I had with Vista SRP is if I exclude a folder on a second hard drive or usb thumb drive (containing a portable application...ImgBurn for example) Vista would prohibit it from functioning properly or executing at all. Nothing I tried would help the situation short of turning off SRP. Under Windows 7 I experience no such problem. Guess that's why I like Windows 7 so well though I still can't run my browser as Basic User under Additional Rules but I solved that problem with a Drop My Rights variant written in C# (http://www.mentalis.org/soft/projects/droprights/) only 39Kilobytes in size. I check to see if my browser is running under restricted rights with Process Explorer. Works great.

Later...

[m00nbl00d]

Originally Posted by Lucy

This is a totally expected and normal behaviour of SRP. As Admin runs by default as a limited user, restrictions to LUA apply to admin as well by default. That is why running as admin under Vista is totally pointless.

Please run under LUA. When you need admin credential to perform a task or install a program, simply right-click "run as admin", and voila.

Hello Lucy,

I do use LUA.

But, this behavior is not expected under Administrator account, because, as I mentioned to one other user, I never witnessed such with both Windows Vista and Vista SP1. Only SP2.

Unless, the wrong behavior was happening with Vista and Vista SP1, and SP2 is making it right?

Again, allow me to say that, I have two machines, at home, where I work side by side with them, and in one there's Vista SP1, still, and in the other one Vista SP2. In the one with SP1, I don't get "error" messages saying that I need to contact the Admistrator, due to software restrictions. (I'm talking, of course, about Administrator accounts.)

[Lucy]

Unless, the wrong behavior was happening with Vista and Vista SP1, and SP2 is making it right?

That would be my guess:
If we talk about any program outside the two program and windows folders, if UAC in on and not in quiet mode (TweakUAC), and even if you are under admin account, it is the normal behaviour that UAC deprieves the admin account of its admin rights.Therefore, SRP applies as it would from LUA.

[Sully]

I have installed win 7 v7201 onto my machine. Here is the scoop. PGS does work now, but there are still some issues with SRP in this version. For starters, to even see what is really happening I had to create a standard user account, and turn off uac to see what regular admin does. So far as I can tell, registry values all work as expected, even PGS puts these in correctly, but with an additional step. I will fix that eventually.

So I can import a .reg file, or use PGS to put deny and allow rules in place. There is still some issue though. No matter if you do a .reg file, a PGS entry or use secpol, any rule that is supposed to use Basic User does not work correctly. So still a bug in this version.

I have not had any luck yet with applocker either. I will spend some more time on that to see if I can even get it to perform.

I believe though, providing MS fixes all these issues, PGS will certainly work with windows 7. I have not attempted what Trespasser mentioned about making a Home version. I will work on getting PGS to work as it should with 7, then release a non time-contrained version, probably out of beta as it seems no one has any issues with it at all bug-wise. The other things I am working on are moving slow because summertime activities. I will focus on getting this win 7 stuff sorted.

Any further input is great. For those trying PGS with win7 now, steps from a fresh install are:
Automatic TAB: option setup for admin or setup for LUA and apply. (ignore messages)
Preset TAB: import a rule, preferably the Allow path rule for *pgs*.exe
That should do it. All registry values should now be in place and you can create/import your rules.

As noted, only deny and allow rules work currently due to the bug in SRP and Basic User. If you wish to create or modify a rule, you can restart explorer for changes to take effect. I have also found that in the SRP Manager TAB, you can click exclude dll and apply then include dll and apply, and now the rules seem to take effect without a shell restart. Actually changing that option to any of the 3 in that option group seems to cause the effect. I don't see why exactly, but it is consistently working.

Sul.

[Trespasser]

Originally Posted by Sully

So I can import a .reg file, or use PGS to put deny and allow rules in place. There is still some issue though. No matter if you do a .reg file, a PGS entry or use secpol, any rule that is supposed to use Basic User does not work correctly. So still a bug in this version.

Just to clarify...when you speak of Basic User are you referring to Security Level or Additional Rules in SRP? If Additional Rules then I've got some bad news...I'm running Windows 7 build 7600.16385 and running an application as Basic User in Additional Rules is still not working as it did in Vista. I personally believe it's gone for good by design and not a bug.

The closest I've come to running my browser, Firefox, or word processer, Open Office, to Vista's Basic User mode is using this little gem...http://www.mentalis.org/soft/projects/droprights/

but like the original DropMyRights execution is tied to one link instead of being applied system wide...but I can live with that (unless you can come up with a solution, Sully).

But of course I could switch to Opera where UAC Virtualization is enabled by default. That would at least solve my browser problem but I prefer Firefox.

Later...

[m00nbl00d]

Originally Posted by Trespasser

Just to clarify...when you speak of Basic User are you referring to Security Level or Additional Rules in SRP? If Additional Rules then I've got some bad news...I'm running Windows 7 build 7600.16385 and running an application as Basic User in Additional Rules is still not working as it did in Vista. I personally believe it's gone for good by design and not a bug.

The closest I've come to running my browser, Firefox, or word processer, Open Office, to Vista's Basic User mode is using this little gem...http://www.mentalis.org/soft/projects/droprights/

but like the original DropMyRights execution is tied to one link instead of being applied system wide...but I can live with that (unless you can come up with a solution, Sully).

But of course I could switch to Opera where UAC Virtualization is enabled by default. That would at least solve my browser problem but I prefer Firefox.

Later...

I've created an SRP exclusions folder, which will make everything run as Basic User. By doing that, the simple action of editing a *.reg file with Notepad, by right clicking the *.reg file, won't work.
If I set that exclusions folder as unrestricted, then I could edit the *.reg files. I hope I'm not making some confusion with something else, but I also believe that I could apply *.reg files from that exclusions folder.

At the beginning, I actually had my exclusions path set to unrestricted, and after witnessing that behavior, I set it to Basic User.

I talked about *.reg files, but the same would apply to *.exe files. The only difference is that UAC would step in, if the *.exe file required privileges elevation.

All this in LUA.

Maybe it's just a bug, which affects certain actions?

P.S: This was happening in Vista. I haven't tested it in Windows 7.

Could you test this as well, with 7? Create an exclusion path, and first set it to Unrestricted. Then add some *.reg file over there and see if it allows you to add the *.reg file to the registry. Then, change the path's permissions to Basic User and do the same.

I'm guessing it's just a bug that came from Vista, and that Microsoft still didn't work it out, as it didn't with more bugs regarding SRP.

It just came to attention, yesterday, that with DLL enforcing, in no way I can open *.zip files that I have in my pen.

None of this (zip, doc, txt files problems) ever happened with Windows XP, and I've installed it, recently, to a family member where I've applied SRP, and tested it before handing it over.

[Sully]

Originally Posted by Trespasser

I'm running Windows 7 build 7600.16385 and running an application as Basic User in Additional Rules is still not working as it did in Vista. I personally believe it's gone for good by design and not a bug.

I refer to creating a path rule that is in this path 131072. This is the Restricted aka Basic User registry key. Anything in that path is supposed to be stripped of the token privelages, pretty much like DropMyRights, so the process created becomes as a User. If I create a path rule in that key, from .reg file, from PGS or from GroupPolicy (secpol.msc), it refuses to operate at all. For example, allow notepad.exe, it is allowed. Deny notepad.exe, it is denied. Restrict notepad.exe, it is denied, no matter how the rule is made or what settings you put in place.

this little gem...http://www.mentalis.org/soft/projects/droprights/

but like the original DropMyRights execution is tied to one link instead of being applied system wide...but I can live with that (unless you can come up with a solution, Sully).

If I remember right, I think I made a tool for DMR that you can just drag and drop an icon/file into, and it starts it with DMR. I think I also had a context menu for DMR as well. If you would like I will revist the archives and see what I was working on.

Sul.

[Sully]

@m00nbl00d

I will look at testing that stuff on 7 hopefully this weekend. I might have to put vista ultimate on a vmbox again to see how it works on that too.

Sul.

[Windchild]

Originally Posted by m00nbl00d

I've created an SRP exclusions folder, which will make everything run as Basic User. By doing that, the simple action of editing a *.reg file with Notepad, by right clicking the *.reg file, won't work.
If I set that exclusions folder as unrestricted, then I could edit the *.reg files. I hope I'm not making some confusion with something else, but I also believe that I could apply *.reg files from that exclusions folder.

At the beginning, I actually had my exclusions path set to unrestricted, and after witnessing that behavior, I set it to Basic User.

I talked about *.reg files, but the same would apply to *.exe files. The only difference is that UAC would step in, if the *.exe file required privileges elevation.

All this in LUA.

Maybe it's just a bug, which affects certain actions?

So, basically, you have the following problems:

1. SRP partially or entirely prevents opening - not only executing - any file from any partition or drive except the system drive (as an example, the issue you had earlier, with normal text files being difficult to open and slow to browse if they were located on an USB stick)
2. SRP prevents .reg file merging or editing from any folder that has any restrictions at all placed on it

Number 1 is a big issue. That has got to be a bug, and I think we ought to make some noise towards Microsoft about that to get it solved. Or something. Bug report for Microsoft, ahoy! Interestingly enough, that issue does not seem to happen on all systems where SRP is applied. Quite mysterious, but then, life is. (I hate to say it, but I wouldn't be too surprised if at the bottom of this whole thing was a conflict with some kernel-hooking security software...)

Number 2, though... well, by default, .reg files are in the SRP designated file types list. In other words, SRP blocks .reg files by default (and for good reason, since you can do all sorts of stuff with .reg files). If you want, you can try removing .reg files from the file type list and that should solve this issue. Number 1 looks like a bug, but number 2 looks like "functions as designed."

[m00nbl00d]

Originally Posted by Windchild

[...]

Number 2, though... well, by default, .reg files are in the SRP designated file types list. In other words, SRP blocks .reg files by default (and for good reason, since you can do all sorts of stuff with .reg files). If you want, you can try removing .reg files from the file type list and that should solve this issue. Number 1 looks like a bug, but number 2 looks like "functions as designed."

I got no problems with "Number 2".

Let me try to explain myself better. Sorry if I didn't before.

So, quite sometime ago I created path C:\Exclusions (the name is different, but you get the picture). I created an additional rule in SRP to set that path as unrestricted.

So far so good. That's what I wanted.

Now, what I believe it must be a bug (At least, is how I see it.) is the following:

If I placed a *.reg file over that folder, I could edit it with notepad, just by right-clicking. (I don't really see much of a problem editing a *.reg file.)
But, I also could add the entries of that *.reg file to the registry. This in a LUA.
Now, this is a problem/bug. Unless it is meant to be like that, which I find it to be plain stupid. Why is it a problem? Without any SRP, no one without administrative rights, as in LUA, would be able to add entries to registry by applying some *.reg file.
Setting that folder C:\Exclusions to unrestricted would elevate rights in that folder, and make it possible to add entries to the registry, by clicking a *.reg file, in that folder.

For what I understand, an exclusion path should only be that - an exclusion path where users may place files, etc they can use, but with the limitations of a LUA.

Setting a path as unrestricted with SRP shouldn't mess with that. Or is it by design?

When I noticed that, I set that path to Basic User right away. This means that anything in that folder may be run by any user, but considering the already known limitations of a LUA. In fact, in that folder is happening what would happen if there were no SRP applied.

Now, this is the behavior I would expect when setting an exclusion path, while in a LUA. The user being able to do what has been able to do so far, which means not adding any entries to the registry.

When I saw this happening, I actually triple checked it just to be sure I wasn't imagining things. lol

[Trespasser]

Originally Posted by Sully

If I remember right, I think I made a tool for DMR that you can just drag and drop an icon/file into, and it starts it with DMR. I think I also had a context menu for DMR as well. If you would like I will revist the archives and see what I was working on.

Sul.

Yes, that would be great. If you could tell me the name of this tool I could look it up myself (I assume Wilders).

Thanks, Sully.

[Sully]

Well, the name of the tool is.. I don't know, what do you think it should be? I thought I had one I made, but it was to use RunAs from LUA, sort of like SuRun. Turns out I did not create one that used DMR for dropped files, but for explorer itself (the shell).

However, I took a peek and I think it should not be much of a problem to change a few things around in a couple different projects and just use DMR syntax instead of RunAs. I will email you a beta maybe tommorrow. What name would you think to be good?

Sul.

[Windchild]

Originally Posted by m00nbl00d

Now, what I believe it must be a bug (At least, is how I see it.) is the following:

If I placed a *.reg file over that folder, I could edit it with notepad, just by right-clicking. (I don't really see much of a problem editing a *.reg file.)
But, I also could add the entries of that *.reg file to the registry. This in a LUA.
Now, this is a problem/bug. Unless it is meant to be like that, which I find it to be plain stupid. Why is it a problem? Without any SRP, no one without administrative rights, as in LUA, would be able to add entries to registry by applying some *.reg file.
Setting that folder C:\Exclusions to unrestricted would elevate rights in that folder, and make it possible to add entries to the registry, by clicking a *.reg file, in that folder.

For what I understand, an exclusion path should only be that - an exclusion path where users may place files, etc they can use, but with the limitations of a LUA.

Setting a path as unrestricted with SRP shouldn't mess with that. Or is it by design?

When I noticed that, I set that path to Basic User right away. This means that anything in that folder may be run by any user, but considering the already known limitations of a LUA. In fact, in that folder is happening what would happen if there were no SRP applied.

Now, this is the behavior I would expect when setting an exclusion path, while in a LUA. The user being able to do what has been able to do so far, which means not adding any entries to the registry.

When I saw this happening, I actually triple checked it just to be sure I wasn't imagining things. lol

Now I understand it even less than before!

Is your problem then, this:

If you make an Unrestricted folder in SRP, you can then, in LUA, create .reg files in that folder and merge them into the registry bypassing registry permissions? That is to say, can you, from that Exclusions folder of yours, modify registry keys and values that limited users do not have write access to, such as HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run? If yes, that is obviously a serious problem. If no, then what's the problem?

[m00nbl00d]

Originally Posted by Windchild

Now I understand it even less than before!

Is your problem then, this:

If you make an Unrestricted folder in SRP, you can then, in LUA, create .reg files in that folder and merge them into the registry bypassing registry permissions? That is to say, can you, from that Exclusions folder of yours, modify registry keys and values that limited users do not have write access to, such as HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run? If yes, that is obviously a serious problem. If no, then what's the problem?

To be honest, I haven't tried to do that. But, what I did was to edit my SRP registry file (I hate to waste time with gpedit) and then add it to the registry, from within that excluded path, first set to Unrestricted. I know it allowed me to add the changes I made, because I remember something went wrong and totally screwed my SRP. I had to delete everything and redo it again. (I didn't want to always go back to the Administrator account or having to start cmd line with elevated rights every time I need to edit my SRP.)

But, a few moments ago, I tried to achieve the same, from within a LUA, with a path also set to Unrestricted, but I couldn't. I tested this in a virtual machine running Windows Vista SP2.

Back then, I was running Windows Vista SP1. So, maybe it was a bug, but that got fixed.

I still see the successful message when applying *.reg files from the exclusions path (in the virtual machine), but it won't actually do anything.

Even better, I guess. I guess such successful message would frustrate users trying to make unauthorized changes to the system. lol

[Windchild]

Originally Posted by m00nbl00d

To be honest, I haven't tried to do that. But, what I did was to edit my SRP registry file (I hate to waste time with gpedit) and then add it to the registry, from within that excluded path, first set to Unrestricted. I know it allowed me to add the changes I made, because I remember something went wrong and totally screwed my SRP. I had to delete everything and redo it again. (I didn't want to always go back to the Administrator account or having to start cmd line with elevated rights every time I need to edit my SRP.)

But, a few moments ago, I tried to achieve the same, from within a LUA, with a path also set to Unrestricted, but I couldn't. I tested this in a virtual machine running Windows Vista SP2.

Back then, I was running Windows Vista SP1. So, maybe it was a bug, but that got fixed.

I still see the successful message when applying *.reg files from the exclusions path (in the virtual machine), but it won't actually do anything.

Even better, I guess. I guess such successful message would frustrate users trying to make unauthorized changes to the system. lol

It's a little impossible to know what's going on if one doesn't test both writing (=merging those .reg files) where limited users should have access and where they should not have access. For example, HKCU versus HKLM.

Most likely, though, your .reg file is editing stuff in HKCU, where limited users can do whatever they want. (HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\?)

This doesn't really sound like a bug to me. If you're running virtual machines, all bets are off. Virtual machines are nice for many things, but one really shouldn't assume that everything works as it should or as it would in a real environment when running a virtual machine. Actually, I haven't ever seen any virtual machine, anywhere, that didn't act strangely, have all kinds of little hickups and odd behavior that would not happen in a real environment - some things act up and fail to work as they should, or fail to work at all. Virtual machines aren't a good environment for hunting bugs in an OS - it's quite likely that any bug-like behavior you see is a quirk or outright bug of the virtual machine software instead of whatever it is that you're testing.

[Sully]

Originally Posted by Trespasser

Yes, that would be great. If you could tell me the name of this tool I could look it up myself (I assume Wilders).

Thanks, Sully.

Check it out here
http://www.wilderssecurity.com/showthread.php?t=248424

Sul.

[pbw3]

Not sure if this has already been mentioned at all, but I found this interesting using SRP..

I am using Vista 32 Business SP1, and using the standard Mechbgon implementation - ie, if running as a limited user, programs can only run from the Windows and Programs folders / and users can only write to their own user account (and say to data on another drive etc)..

As an LUA, if I save a program to user\download, and then try to run it.

1) Logged in as LUA --- Run it normally ---- Blocked
2) Logged in as admin - Run it "as admin" -- Allowed
3) Logged in as LUA --- Run it "as admin" -- Blocked - {See correction in post below}

ie, under 3), if logged in as an LUA, and try to run the program as an admin, the SRP restriction seems to kick in before I am allowed to elevate (using UAC).

Whilst this might be irritating if say I want to run a utility (directly from the download folder) whilst still logged in as an LUA - what is interesting to me about this is that it appears to be more secure in the context of potential malware.

Peter

[Lucy]

I never experimented this under Vista.

On another hand, I know for a fact that M$ has corrected a few irritating behaviours of UAC in SP2. The best would be you set it up first and check wether the problem is persistent.
NB: 3) should be:
Logged in as LUA --- Run it "as admin" -- Allowed

[pbw3]

Originally Posted by Lucy

I never experimented this under Vista.

On another hand, I know for a fact that M$ has corrected a few irritating behaviours of UAC in SP2. The best would be you set it up first and check wether the problem is persistent.
NB: 3) should be:
Logged in as LUA --- Run it "as admin" -- Allowed

Thanks for that.. You are absolutely right - I have tested it some more and realised I made a mistake..

When trying to run an exe from \Admin-user\download\, logged in as LUA but running it as an admin, it fails..

However, if I run the exe from \LUA-user\download\, logged in as the same LUA, but running it as an admin, it will allow it, provided I elevate.

[Edit: This is even more bizarre.. I have three different download folders in \Users\Admin-user> and "run as" from Explorer behaves differently for one of the new folders (allow if elevate), compared to how it behaves for the original folder plus the other new one (group policy blocks)!?.. and they all appear to have the same owners, permissions, access rights etc; I will investigate when I have more time..]

[Spiral123]

Late to the discussion, and don't know if already mentioned, but in reference to the vulnerability of the environment variables being changed with the cmd prompt, MS recommends using the registry paths rules to define rules in SRP. For example, when you first enable the default deny policy in gpedit, there are rules automatically generated so you don't lock your self out of windows. These auto generated rules are the registry path rules. If you look toward the end of the sting you will notice they are referencing file paths. Supposedly MS says that these cannot be messed with by users using a command prompt to change environment variables. I read this somewhere on the MS technet website explaining SRP.

[tcarrbrion]

Originally Posted by m00nbl00d

So, I opened a *.txt file I had in my USB drive, and the Notepad window was similar to the classic windows theme. Also, browsing through the file was really slow. I copied the file to a folder in C:\Somefolder\Someotherfolder\*, and it opened as it should.

I also can't open *.doc files from within USB drives. Not even by first opening Office Word and then access the file. I need to copy it to the system.

This is due to the fact that my SRP are enforced for all files, including DLLs.

This appears to be fixed in Windows 7. I can now set up a SRP including DLLs and I can open .DOC and .PDF files straight off a CD without any problems.

[korben]

Do we need a similar thread for win 7?

[Lucy]

I don't think so as it is perfectly identical in Win7. Maybe the mod can change the name of this thread to :
"Maximising Windows VISTA or 7 security with LUA and SRP (even without ultimate)"

On another hand, one will have to create a dedicated thread to AppLocker which appears to be much more efficient. Unfortunately this time, there will be not secret hack to activate it... Only ultimate users (or corporate) will enjoy it.

I still didn't get the new version. Time will tell.