Microsoft: Vista feature designed to 'annoy users'

TalkBack 18 of 89:

Next »

« Previous

• Thread View
• Flat View

True, it's better for XP stability too

Applications that have been modified to avoid UAC prompts are certainly better written now, because they install themselves so that no user settings will be stored in global security realms like system directories or in system registry : HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT. Also these applications will not suffer from slow "File virtualization" in Vista, and upgradability will be simplified.
The benefit is that a user running Windows no longer modifies the shared system entries, and if they crash something, all that can be damaged is in the settings of their own user account, but not the settings used by another user account. This way, it's simpler to revert from a bogous or malicious software action: just logon with another user, and you get a fresh clean and undamaged environment, without the bogous browser helper apps, broken file links/shortcuts, and so on.
UAC enforces the recommandatations that were present since very long in Windows (for ever in NT and 2000, or since XP, and even in Windows 95/98), that highly recommanded applications to split the user settings from application and system settings.
Settings that will be shared acros all users in a host or domain will be regulated by system policies, and a system administrator will still be needed to overwrite these areas.

Those applications now modified to avoid prompts will also be cleaner in XP (and 95 or 98 if they don't absolutely need more features found only in Vista). They are also simpler to uninstall, and it's very simple to limit the number of garbage remaining on the system, because most changes made by the applications will be done only on the user's settings. All applications will have their reasonnable defaults thaty only the system administrator can modify (or break), or those application will have to create a separate system service to provide the isolation between the user-level settings and the system, and protect that interface if it must be made accessible to users. Most of the time, such service (that can only be installed and run by a user with the administrator security token) willnot be needed. It will be then possible to run those apps directly from the user account without modifying anything in the shared local system policy or shared group policy.

With UAC enforcing those things, all applications modified to comply with it get stronger security, and the system is much more resistant to malicious software such as worms and troyans in a browser.

I'd like to see the UAC enforced even more: there should also exist a "user security token" that will be needed to protect the settings and private data of a user, against abuse by foreign sites. When browsing the web or reading emails for example, the local user would not be directly visible, but it would just be a "web identity" without the user privilege. Microsoft did not really create it, but it introduced something else that may be more powerful: remote identities, that are isolated by domains; this means that even when you download files in your home directory, the file is marked as originating from another site and not directly part of your own local user realm; the file belongs to your identity on that remote site, and when running it, it should not automatically get the user token without asking for user permission (no permission will be needed to run that file to perform actions with the original web sites). This is the same concept as the isolation mechanism found in web cookies that are protected by domain, and have lower privileges than the local user (who acts as an administrator for the remote identities whose usage is not fully within his own direct control)

So I think that UAC is just the start of a more serious reform of the security model in Windows, towards *MORE* isolation levels, in a multilevel hierarchy.

What is misleading for users in UAC is the fact that the "Administrator" logon is not the highest administrator of the system: when you logon, you effectively get the seciroty token to the Administrator, but the Explorer shell starts by first creating a secondary identity with a lower privilege, from which all applications will be run. If an application requires some privilege, it will not doirectly perform the action but will call a service owned by the user with the admin privilege through a proxy; it is that proxy that displays the authorization dialog; if the action is accepted then the proxy will provide the privilege security token and the application will restart the action with this token, granted by the invisible user with higher privilege.

The same could be added on top of XP (the necessary APIs, that can impersonate a current user acoount to another one with lower privileges) are present in Windows since ever.

Unix/Linux currently still lacks a similar mechanism to provide layered user privileges (it just has user ID, group ID, and system wide levels, and no clean way to manage multiple levels except by multiplying the number of users, one for each privilege level); in Windows, visible users are in fact groups, containing several users with distinct privileges, and groups can also be part of other groups. To solve this issue, Unix should treat everyting by using the pair (user, group) to manage the distinct privileges in groups, where each group defines its own privileges; at one time an applciation should be running in one user account, but one or several groups, something still not implemented, and in fact inappropriate to manage unlimited numbers of security tokens (such as one identity per remote site): this can only be implemented in browsers for things like cookies, but there's still no central repository of tokens that a user can manage.

Windows is still not perfect: all files that belong to a remote site realm are part of the same "remote" area (the "Internet domain"). This should go further: remote Internet realms should become separable and identified by Internet domains (Windows manage it partly only for domains managed by a Windows domain server). Every installed file on the system should track its origin (at least its domain) using secure protocols (and if the identity of the remote site is not fully verified, there should exist a recorded status that the identified remote site is not necessarily the correct one).

So we need more in Windows, and notably a easier way to manage certificates for remote sites (i.e. accept them, and reject them later at any time so that it will also remove the granted privileges associated to the files that these sites have installed). So the user control panel should contain not ony a portfolio of certificates accepted from a remote site, but also the list of privileges we have granted to each of them. We would then manage several completely separated identities with much less risk than today. Those relams would also be used for EACH installed software in Windows, so that no one will be able to corrupt permanently the settings for another app coming from somewhere else: as long as the privilege is granted to one realm, then only this can override settings from another user realm; when the privilege is removed, this should revert immediately to the default settings inherited from the higher privilege local account.

The caveat of such multilevel isolation mechanism is that the multiple accounts owned by a user will need space for storing sometimes the same files or data for several applications. But this is already the case with the SxS settings in Windows (side-by-side installations of multiple versions of the "same" component, oine for each other independant component that need it in a precise version from a known source). However today, storage space is no longer a problem withr the exploding size of harddisks and decreasing cost. The default used everytime should always be to avoid sharing data between independant applications or sites. The act of sharing anything should always require user level elevation and explicit permission by a user account with this higher privilege (this is what UAC requests when it asks for permission)

Posted by: PhilippeV   Posted on: 04/14/08 You are currently: a Guest | Members login | Terms of Use

Alert moderator to an offensive message

Subscribe to this discussion via Email or RSS

SponsoredWhite Papers, Webcasts, and Downloads

• Virtualization: Architectural Considerations And Other Evaluation Criteria VMware Of the many approaches to x86 systems virtualization available in the ... Download Now
• Why Isn't Server Virtualization Saving Us More? A Few Small Changes May Dramatically Increase Your Efficiency VMware Companies have rapidly adopted server virtualization over the past few ... Download Now
• Building the Virtualized Enterprise with VMware Iinfrastructure VMware VMware virtualization software has been adopted by over 120,000 enterprise ... Download Now