Whelp, here I again find myself having to apologize for the lack of updates on the site recently. Unfortunately, last week I actually broke my ankle and really broke it good. Generally, one should try and stay out of the path of deer jumping onto the road when riding a motorcycle, but I unfortunately decided to occupy the same space in time and place as Bambi and am now hobbling around on crutches. Anyway, I am fine now and ready to start knocking some updates out for everyone!
With Windows Vista, Windows Server 2008, and now Windows 7 we have seen the introduction of User Access Control (UAC). While this may be the source of a lot of disdain, causing some people to even go so far as outright shutting it off, its importance in the new Windows security regime and architecture cannot be understated. Frankly, shutting it off is silly and will greatly reduce the ability off the OS to fend off malware, spyware, viruses and worms.
The whole concept, however, has been muddled by misinformation and is widely misunderstood leaving users completely bewildered when programs mysteriously refuse to work and produce cryptic error messages. For administrators of the `New`OSes (hereinafter referred to collectively as Server 2008,) a thorough understanding of this system is absolutely crucial to keep everything up and running.
In legacy versions of windows, all security functions were encompassed by the user groups themselves and access levels were determined by membership in these groups. Should a person want to slightly reduce administrative authority, the Power Users group was often chosen for this purpose. In Server 2008, the use of this group is completely unnecessary and it is only kept around for maintaining legacy application compatibility.
Server 2008 is a very different animal. Now, at least in Server 2008 compliant applications, the application manifest itself will define the applications access privileges as RunAsInvoker, RunAsHighest, and RunAsAdmin.
RunAsInvoker: This level results in the application running with the same privileges as the user. In fact, any user can run the application, but no matter what group they belong to, even if they are in the Administrators group, the program will only run with a standard access token. This concept becomes really important when you get into the windows integrity levels as this fact can cause a program not to function as intended even if run by an administrator. In fact, the only way to get programs that are of the RunAsInvoker type to run as an administrator is to get the parent process running the program to have and administrator access token. This generally means opening up a right clicking on and opening a command prompt window as an administrator. I have heard many people proclaim, when they are told this little fact, that they are “already an administrator” and have watched them click and run a program endlessly without success until they actually run it in an elevated command prompt at which point it magically works.
RunAsHighest: As the name suggests, this runs the application with the highest privileges of the user. Boith standard users and administrators alike, may run the program, but certain program features may not be available based on access privileges. For example, members of the Backup Operators group will be granted fewer rights that an Administrator. Obviously, those who are part of the administrators group will run the program with a full access token.
RunAsAdmin: Only administrators can run programs that have been defined in their manifest as RunAsAdmin type. However, if users can provide Administrator credentials to allow the program to be elevated, or if the program is started from a previously elevated process such as the command prompt it will still run. This type of program will always run with and Administrator access token.
As well as these run levels, Windows Server 2008 also protects application processes by using integrity levels. All processes in the OS are assigned an integrity level and process with a lower integrity are not allowed to modify those of higher integrity. Internet Explorer, for example, is assigned a fairly low integrity level making it a lot more difficult for it to compromise the OS. As well, the OS will identify the publisher of any program that tried to RunAsAdmin and the OS will flag the potential risk using Red and Yellow colour codes. Red indicates that the program is from a blocked publisher and there is very likely danger associated with the install. Yellow signifies “unknown” and Blue/Green are for administrative elevation for server maintenance.
A lot of people ask me how UAC stops malware from entering a system. They seem to feel that malware can easily circumvent this feature. While it is entirely possible that there are ways around it, all of the newer OSes that have UAC are much more difficult to penetrate. The elevation prompt itself cannot be spoofed and Windows has some very sophisticated algorithms in place to detect any kind of software install in process, which would then trip the UAC elevation prompt. Only Windows Core services is able to bring the elevation prompt up -which, as I have stated, makes it extremely difficult to get around. UAC is a good thing and I hope that after reading this you will agree.
For all of you developers out there, here is a good little power point on UAC from Microsoft and it outlines some of the design considerations in making a nice UAC compliant app. Give it a whirl, it is obviously in much greater detail than what I have here and an interesting read.
User Account Control- How to Make a Good UAC Application
Next post, I will go over some easy ways of controlling the run levels for all of you server admins out there, and little tricks that can make your life easier. I hope that all of you are now migrating back into your OS and re-enabling UAC now……
Cheers……
QuickRun.net is free! Try it now.
No comments:
Post a Comment