Virtualization Guru Writes “User-mode is a Good Thing – Deployment to Locked-down Accounts without Security Elevation”
Quick history of user-mode
Windows runs all code in one of two modes, user-mode and kernel-mode (also referred to as Ring3 and Ring0 respectively). The two modes reflect two different security models that are enforced directly by your Intel/AMD processor. Code running in kernel-mode has full machine access with no security controls, for example it can write to raw device ports, intercept and filter system-wide file system activity, read and write machine wide process and kernel memory, and access any kernel or process objects without regards to security descriptors. Kernel-mode code typically comes from device drivers and the windows kernel itself. User-mode is where all applications run and has strict security policies applied at all times, user-mode code cannot do anything to a machine that would directly cause it to crash or violate applied security policies. For example, user-mode code cannot access files owned by other users unless file system permissions allow it. As well user-mode code cannot make network connections unless the group security policy enables them to do so. 80386 (Pentium+) and higher processors enforce a specific security policy on user-mode application by prohibiting them from executing instructions that talk to device ports directly, preventing access to memory in other processes, and by preventing execution of kernel mode without first going through specific controlled entry points.
User-mode/kernel-mode are different from Administrator/Guest
For user-mode code, Windows supports many different sets of security policies based user accounts – for example Administrator and Guest accounts are user-based security policies. Administrators typically have nearly full permission to access any system objects they want, while Guest are fairly restricted and cannot read other user’s files or write to global locations on the computer. Both Administrators and Guest will run applications in user-mode, but switch to kernel-mode when making system calls to access objects. Kernel-mode code will then consult security descriptors to see if the user has access to the objects they request. Because Administrator accounts with full permission are a dangerous thing from a security perspective, in Windows Vista Microsoft reduced the rights of Administrators by default and will prompt users before accessing privileged objects on a computer.
Better security by confining vulnerabilities in user-mode
First, let’s start with the assumption that all sufficiently large and complex software projects have some bugs and with many bugs there is the possibility for security exploit. The most public of these occur in Internet Explorer because it is easy to force every computer on the internet to execute code using Internet Explorer via HTML email or redirecting page views to illegitimate sites. With Windows Vista, Microsoft runs Internet Explorer in a separate user account which has limited security rights. This way, if IE is compromised, the compromised account cannot do anything to the rest of the machine. This solution is possible because IE runs in user-mode. Because Thinstall runs 100% in user-mode, any bug or vulnerability presents no additional risk to the rest of the system because all Thinstall code is running in user-mode in the same security context as the application. Other solutions use device drivers and run significant amounts of kernel-mode code, which, if compromised allows full control over the machine. For a few examples, search for “symantec vulnerability” on google and you’ll see this is a pretty common attack vector for hackers. User-mode code can be “walled-off” using user accounts, where-as kernel-mode code cannot. For this reason Microsoft recommends companies purchase user-mode solutions when possible, and put user-mode as a requirement in purchase RFPs:
Also note MS reports user-mode solutions will help reduce your security risk:
“Running in standard user mode gives customers increased protection against inadvertent system-level damage caused by “shatter attacks” and malware, such as root kits, spyware, and undetectable viruses.”
Better security by reducing attack surface.
Thinstall is implemented 100% in user-mode and is only visible to a single application on the machine. Other solutions use device drivers which will intercept calls from every application on the system, if only to decide whether to filter the call or ignore it and pass on to windows. Because of this, the attack surface for Thinstall for security vulnerabilities is much smaller – vulnerabilities can only be exploited from the virtualized process and there is no possibility that non-virtualized Internet Explorer could represent a security threat because of low-level device drivers.
Thinstall keeps security policies intact
Because Thinstall runs 100% in user mode, it has the same rights and permissions as any other application a specific user would have. Thinstall has no ability to exceed the security rights of the user account it is running in because it has no device drivers or components running in kernel mode. When using Thinstall, Administrators do not need to consider how their system-wide security policies will be affected. For example, other solutions used filter drivers to redirect file system activity, however it is not always clear what will be applied first; virtualization or security rights. Thinstall can be deployed in conjunction with central IT group policies or separately in the case of smaller development groups. In the later case, developer groups have the freedom to use the code components and frameworks of their choice without requiring security policy relaxation by centralized IT.
System stability through user-mode
Ever have your systems blue-screen, and you don’t know why? They usually appear fairly random and can be hard to diagnose without significant time and resources. Microsoft reports that approximately 80% of system crashes and blue screens come from 3rd party device drivers. Every instruction running in kernel-mode represents an opportunity for a system crash or hang, often the hangs are due to thread dead-locks which only occur in rare circumstances and when combined with other products. It is a testing impossibility to ensure that products will never crash or hang, and most do. The difference is that user-mode code can never directly crash a system and it can be easily killed with the task manager if it hangs. There is no other impact on the system. Windows will automatically clean up after crashed or killed user-mode applications by closing open file handles, freeing allocated memory, and discarding created resources. Kernel-mode applications have no protection at all from crashing or leaked resources. A kernel-mode crash results in the dreaded blue-screen, though often times, the problem is a thread dead-lock and the machine appears to be frozen or performs very badly for no apparent reason. Diagnosing kernel-mode bugs is an art left to very expensive consultants and many companies find it cheaper to abandon faulty device drivers that crash systems rather than try to diagnose and resolve the problem.
Deployment to locked-down accounts without security elevation
Perhaps one of the biggest advantages of being a user-mode solution is that you can run applications directly from locked-down accounts without pre-installing a device driver or granting the user elevated security privileges. This has proved tremendously valuable for companies that have change management processes in place that prohibit the installation of device drivers or other system changes without a careful study, pilot program, and roll-back capability. Because Thinstall has no device drivers, it enables deployment of applications with zero footprint on the desktop PCs, complex application can literally run directly from network shares with no preinstall requirements. This enables companies to guarantee change management policies are not violated through group policies, and quickly deploy new applications at the same time. Because there are no device drivers or system files installed, the roll-back process is as simple as deleting an EXE file.
Ok, user-mode is great – why is Thinstall the only one doing it?
Thinstall pioneered the user-mode application virtualization with patents granted and pending. The user-mode virtualization technology is very large undertaking to complete. Thinstall has been in development for nearly 10 years to date, and it is technologically most similar to the open source projects Wine and ReactOS which have also been in development for approximately the same time frames. Thinstall focused on staying user-mode from day one, and this is reflected in the product you see today. Not knowing a user-mode solution was possible, other solutions started out as device driver based solutions and switching to a user-mode model would require complete rewrites. Device driver solutions work by implementing a windows filter driver in kernel mode which intercepts various file-system requests in the kernel mode. At this level, the hard work of loading applications, resolving DLLs, and processing side-by-side manifest is done by the Windows operating system. Virtualization at the filter-driver level is comparatively simple to implement (the Vista OS team has implemented this in the Windows Vista kernel). In user-mode, virtualization is much more complex and requires virtualization of any functionality that touches the file system or registry. More than 400 different windows sub-systems and APIs have been replaced by Thinstall including the windows loader, service control manager, and process manager.