OSNews

Sudo commits a specific action as the root user. It's just a way to do temporary login to do some action. I think sudo also has the feature that it leaves the door open for a configurable amount of time so that subsequent requests for privilege go through without requiring password authentication.

UAC has a component that works very similarly to sudo, in that it takes authentication to elevate the user to admin rights. The authentication does not always take the form of a password request... if you are already an admin user, you just click "Continue" to acknowledge that the administrative action is really being done on your behalf.

Let me back up here a bit. An important part of UAC is that even "administrative" users launch processes with a "Restricted Token." The security token is a thing granted to users which has a series of bits which specify which "privileges" you get in the OS. It's kind of like a capabilities system (see wikipedia), but doesn't have the sophisticated revocation system of experimental capabilities OSes. The security token also includes a list of what groups you are part of (one of which is Administrators). A process inherits the token from whoever launches it, and when the OS wants to do an access check, it applies the most permissive access mask in the token to the ACLs on whatever object you wish to access (files, kernel objects, window stations, etc) to see what rights are allowed.

Under UAC, even admin shells (like Explorer) naturally get tokens with special privileges removed: the applications launched from this shell only have the rights of a standard user. You go through the elevation dialog box to get true root-level access (which involves restarting the process that requests the elevation... a thing you might notice if you look carefully).

To avoid breaking apps that write to Program Files or other non-kosher locations, a piece of UAC virtualizes writes to those folders for standard-user processes and redirects them to a per-user folder.

Last, but most important, UAC takes some steps to avoid having its own dialog boxes spoofed or manipulated by other applications (any app on a desktop can send a message to any other app in the same user session regardless of the different tokens each process might bear). It achieves this by starting its own Window session that is inaccessible.

The problem is that once UAC has done its business and started a new process with an administrative token, that process is still running on the user's desktop. You have two apps that are effectively running as two different users on the same desktop, so you can get "shatter" style attacks from a lower privileged app against a high-priv one. It's fairly trivial to elevate a piece of malware by just squatting and waiting for an insecure high-priv application to need an elevation. This is why someone said, accurately, that UAC "keeps honest people honest." I'm not sure if X Windows takes any steps to prevent this same kind of attack either, so I'd say your paranoia is well-founded on linux as well.

Word for the paranoid: if you really care, log off or use Fast User Switching for elevating securely (different user sessions get different desktops across which shatter won't work). Also, don't leave elevated applications running while doing potentially insecure things because some lower-priv app might bite them.