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

Don't know why it doesn't work for you, Sully, in Windows 7 build 7201 (I assume), it works for me.

Later...

 

I still haven't applied modifications in the SRP to log, but, this bug, seems to be more severe in Windows Vista SP2 (I was running SP1 until now.).

If I right click the Desktop, then it will take a few seconds to show the context menu. Also, a few entries, in the context menu, don't display. In their place there's Can't find request string.

That's due to how SRP is implemented, to also expand its protection to DLLs.

Microsoft really needs to work on this bug.

 

I have Vista SP2, and I don't have any such issue.

 

That's odd. Because, if I disable SRP, exclude DLLs or log to the Administrator account, then I got no problems.

Anyway, later on I'll enable logging and see what is going on.

 

Maybe you really need to try this logging.
This is often disapointing, but who knows... An answer or at least an explanation may appear.

 

Sully,

 

Thanks. will check it tonight.

Sul.

 

I have the same problem in Vista. It is still not fixed in SP2. I tried contacting Microsoft support (UK) a couple of years ago but gave up after a few days of getting nowhere.

The logging showed DLL files in system32 being disallowed that should not have been. I still have the log which I sent to Microsoft. Most DLLs in system32 were allowed by path rule but when opening a document from the CD drive some DLLs in system32 were blocked by the default rule.

 

Maybe you should have told them that you're an IT Professional, working at a company, and that the way SRP works in Vista in inadmissible.

Sometimes, it does the trick. I guess that when we say we're home users, they don't care that much, after all most users make use of Home Premium, so why bother just for a few, right?

I might get in touch with them.

But, I'll go straight to the source - U.S Microsoft support. Usually, they're the ones providing the best support. I can't complaint. Now, my own country support sucks big time!

 

Well, I tried to get in touch with U.S Microsoft, but I was forced to use my country's support, because there was no way to send my message to the U.S support.

I once send a support request to them, but I don't seem to find how I did it.

Anyway, I sent the support request to my country's support, and surprise... surprise... Once again, they don't reply, they just send an automated message explaining the ways I have to get in touch with support, which include phoning them, as in paying to help them make their products better.

Really great!

I clearly stated in my message that there's a bug that needs to be solved, and that such is not experienced in Windows XP Pro. (I didn't mention that I was experiencing it on Home editions! )

I don't think that they give it much importance. After all, it's part of their very nature, not to care about a lot, when it comes, at least, to home users.

Unless enterprises IT departments are the ones complaining about the bug, and if they do use SRP, I don't see this will change.

Anyway, I'll reply to the automatic e-mail they sent me. They may get it, or not, but I'll ask them why they are so stupid to the point of not to caring about users reporting bugs.

 

OK.

This is really a very creepy situation. I still haven't checked any logs, but why the heck would SRP be applied to my administrator account if the PolicyScope is set to 1, which means every user except administrators?

Because, that's what is happening with Windows Vista SP2. I can't run any executable, batch file, etc., from within my Administrator account.

The stupid thing?

If I start cmd line with elevated rights, then I can install and run batch files from my administrator account, for example.

I don't know if this is happening because it is a clean Windows Vista SP2 install? I mean, I formatted the system, install Windows Vista, then SP1 and only then SP2. After that, I applied SRP.

I'll be testing this in a virtual machine, because it really is creeping me out.

I don't know if something like what I'm about to ask would be possible or not (maybe a bug), but could Windows think that my Administrator account is actually a standard user account, hence the problems I'm having?

Edit: I disabled software restriction policies, but I still can't run the batch files (they start but complain I have no Administrator rights, within my Administrator account). Starting executable needing Administrator rights will also result in failure.

So, I'm guessing is not SRP policies, but a bug in SP2?

 

Vista's bugs notwithstanding, there's another issue that is by design: Vista admins aren't really quite admins, as you may recall - elevation required, and all that, thanks to UAC. So, by default, SRP is applied to admins as well in Vista, even if you set the SRP to not apply to admins, because Vista attempts to limit the rights even admins have unless they specifically elevate to full admin privileges. In effect, your admin account in Vista is in actuality a standard user account until you elevate. That's why you're seeing this issue.

 

To fully test admin, turn UAC off. That is simplest test for vista/7.

Sul.

 

Yes, Administrator account, if UAC is enabled, will act as a standard user account (Although, still an Administrator account.).

But, I've never dealt with these problems with Windows Vista and Windows Vista SP1.

I've always had SRP applied, ever since Windows Vista came out, as I never used Windows XP. But, I do can tell you that these problems began after installation of Windows Vista SP2.

The behaviors I always witnessed with Vista and Vista SP1 were:

Under standard user account

- Users have no installation rights, because they're in LUA and SRP are applied.

- They would need Administrator rights.

Under Administrator account

- An UAC prompt would appear, asking to press OK or Cancel, as it should be. SRP were never applied. Never I saw an alert saying that software restrictions are applied and to contact the Administrator.

Now, with Windows Vista SP2, things are working different. As far as I know, it is not something that Microsoft implemented, to increase security (If we can call it that way.).

From this system where I am writing, I still have Windows Vista SP1, and I can assure you that the SRP are exactly the same. I'm not prevented from installing anything or running any executable while in the Administrator account. The only thing that happens, as always, is an UAC prompt.

Clearly, something is wrong with SP2.

And, it seems that this is not the only problem. Something odd I've been dealing with is that, after clicking the shortcut I have in the Desktop to start my Internet connection on that system (USB device), only the icon appears in the tray bar, but not the program's window. This behavior didn't occur in Windows Vista and SP1.

 

I did just that, as that system was being used by a family member, and with SRP applied, and UAC disabled, problems are gone.

So, UAC is screwing things up. Now, what exactly, beats me. At least, for now.

Edit: I'm also not experience anymore any problems while right-clicking an empty space in the Desktop and taking time to appear the context menu. Also, everything in the context menu appears properly, even with SRP enforcing DLLs, as well.

 

It could be a change or even a bug (less likely, though) in SP2, or something with you system. Could be a botched installation of SP2. Which is it, I cannot tell. I don't run Vista SP2.

Also - are you configuring SRP with the group policy editor or editing the registry directly?

Edit: If it works with UAC disabled, then that suggests that the problem is the "limited" admin accounts in Vista. SP2 may make the enforcement tighter - I don't know. Maybe this is why I don't like Vista.

 

Guys, maybe this isn't the proper place to ask, but does anyone know which e-mail people can contact with, to get in touch with United States Microsoft support?

I once contacted them and they were very helpful. But, I no longer have the contact. It was like 1 year ago.

Now, the support at my country, well... bloody pigs. And, I won't be phoning them and pay to help them solve a problem, after paying what I paid to get Windows Vista. They wish!

 

I had a problem installing SP2 and went there:
http://social.technet.microsoft.com.../thread/53adeb43-d0b4-486b-b860-857d2575e581/

I created an account, and participated. It could 2-3 weeks and they eventually found the cause of the problem (they contacted me, asked me to perform different tasks and trials until it worked). It seems M$ is experiencing troubles with SP2 install, before and after.

Could I advise you to do the same? I guess they could be of great help for your problem.

 

There are a number of questions for this issue with SRP in Vista SP2. SP1 I have tested on, and found no such bugs. Win 7 RC has a bug that is very similar, where including dll's alone is enough to cause issues, even if there are no rules in place except the default.

I have recentlyl found a copy of 7 v7201 thanks to Trespasser that I will install this coming week. I will also grab vista sp2 and slipstream that as well. I will test both vista and 7 for issues. I did not think to test 7 rc1 without the UAC. It is quite possible that turning UAC off solves the include/exclude dll issue. I wonder has anyone found documentation at MS or other that shows exactly what the differences (rights and privelages) between and admin with UAC and an admin without UAC.

I am wondering if the psuedo-user of UAC is not recieving read/execute into areas of the file system that it used to. This might explain these issues. If this is so, I would presume it is because of the newer layout used on vista/7 for it's directory structures. It would make sense from what I currently know of these OS's. And that is not much really.

Anyway, be interesting to see if it is an SRP bug, which I doubt it is. If you look at SRP and how it works, there is simply a check on some functions like Create Process, where when it occurs, the registry is examined (how GP fits I am unsure) and if an executable matching a name/path exists, it is acted upon (determinded by the type of SRP rule). It would seem to be more of a rights and privelage bug, where they have changed rights of admin or user, but forgot that SRP might be used and also SRP would/could include dll's. No rights, means no program run because of restricting dll's (associations).

All speculation for now.

Sul.

 

After about a two week play with Win7, it seems its UAC is even more restrictive than Vista's. Hopefully someone can confirm because I may have missed the boat on this. At least in Vista it can be switched off and it is really off for all users, including limited. But in Win7, it can only be switched off for admins, but limited users are still at least somewhat restricted by it. Here's a quote on Win7's help notes on its lowest setting for UAC:

So it still has influence on limited users at its lowest setting, which you will note that unlike Vista is not actually off.

 

That somewhat seems to be a "return to normalcy" rather than a more restrictive UAC. Denying "any changes that require the permissions of an administrator" automatically is exactly what Windows XP, which does not have UAC, does when a limited user attempts to do something that requires admin rights. I'm sure everyone remembers all those "Access Denied" messages. The only exception to this are some files with special names like setup.exe or install.exe which will automatically pop up a Run As dialog instead of being denied right away. My guess is that this behaviour continues in Win 7, and it's just other stuff that will be auto-denied.

In any case, I find automatically denying stuff that requires admin rights to be a good thing.

 

I'm not so sure because with Vista it is either on or off, whereas with Win7 there are, if I remember correctly, three levels, maybe four, and the lowest setting does not actually turn UAC off.

Of course, but it is through the restrictive measures of XP's limited account, rather than through UAC. And I agree that even with UAC off or at lowest, the limited user should still not have the right to install programs. I have only pointed out it looks as though UAC in Win7 can not be completely disabled, such as it can be in Vista. It is this tenuous grasp Win7's UAC has on limited accounts that gave me some issues with a program, darn I can't remember which so it was one of the very few things I didn't like about the O/S, but in all I was still very impressed with it.

 

Do we know this? I don't know Win 7 internals at all, and I can only guess, but...

It makes no sense to have UAC block changes that require admin rights when logged on as a limited user. It makes no sense, because normal restrictions that apply to the limited user account (logon rights, privileges, permissions) will also block all such changes. Why would Microsoft make a double block like that, where first the normal restrictions of LUA block something and then also UAC blocks it - even though it was already blocked? That would be very strange/poor coding.

Therefore, it is my guess that "never notify" does completely turn off UAC. The help file just chooses not to use the phrase "turn off", instead describing what will happen (no notifications, everything blocked automatically). Having read the description, it seems UAC's "never notify" mode does exactly the same as Win XP's normal LUA does. So it makes no sense to UAC actually be on at that point. My guess, anyway. I wonder if anyone here knows how UAC really works in Win 7, and could chime in.

The problem you had with a program could have been just some other incompatibility issue with Win 7, rather than something UAC related.

 

Well, Mark Rusinovich explains here very nicely regarding the differences between Vista's UAC and Win7's. I'm quite new to Vista as well, so until reading this article, I did not understand the real intent of UAC:

You are right in your assumption that Win7's lowest UAC setting turns it off -for admins at least.

*note: by "PA user" he means "Protected Administrator".

 

Thank you!