eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Theres no question that the user-oriented permission model has problems. Its an attempt at a simple facade on top of a complex set of issues.
If mainstream operating systems are still “stuck” with it, its because the alternatives are, to put it kindly, underdeveloped at this point.
A fascinating analysis of “trusted” operating systems by eWEEK Labs Senior Analyst Jason Brooks touches on many of these issues.
As his example of Red Hats Fedora Core 2 shows, once you enable fine-grained security policies and then lock down the system, the way that security experts advocate the system becomes impracticably complex.
Too many things were broken on real-world configurations. Subsequent releases offered a less fascist approach and have been improving the tools for admins to turn the security screws slowly so that applications (the whole point of the computers) will work in as secure an environment as can be managed.
The vision of a world where advanced security controls work requires that application developers scrupulously document the specific privileges that their applications require, and attempt to use the minimum necessary.
Unfortunately, in the real world, developers too often show disdain for such concerns. This is why so many corporate users are running as administrator users (or, basically as bad, Power Users) on their local desktops.
Windows Vista will at least slow this problem down and allow users to elevate their user privileges on an ad-hoc basis. It will also allow users to run as standard, unprivileged users except for when running applications which the administrator has designated as needing a more-privileged user context.
All of this is too complicated for most people, but theres something better thats much more complicated. The trusted operating systems of which Brooks wrote qualify, and even Windows has the capacity for greater control. Its just that Windows doesnt expose the built-in functionality that allows that control.
Every running application has a security “token” to which Windows attaches specific privileges. Click here for a complete list of the privileges and heres a few samples:
- SeCreatePermanentPrivilege—User Right: Create permanent shared objects.
- SeLoadDriverPrivilege—User Right: Load and unload device drivers.
- SeShutdownPrivilege—User Right: Shut down the system.
- SeSystemEnvironment—User Right: Modify firmware environment values.
- SeSystemtimePrivilege—User Right: Change the system time.
- SeTcbPrivilege—User Right: Act as part of the operating system.
The free Sysinternals Process Explorer tool will show you all the operative tokens for applications running in the system.
Too bad Windows doesnt provide any actual tools, not even bad ones, to manage these privileges. (Actually, there is one tool in the Windows resource kits since Windows 2000 that touches on these capabilities: NTRights.)
There are several systems which attempt to bring a management approach to this level of security: Winternals Softwares Protection Manager, DesktopStandards PolicyMaker Application Security.
Its good that powerful security management tools are finally becoming available to administrators who have the inclination and the gumption to use them, but this is advanced stuff.
One day, mainstream operating systems have to find a way to make true least-privileged access accessible, but were years from that.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
More from Larry Seltzer