What is the utility of limited/standard user accounts in Win7?

[shiranai]

Conventional wisdom regarding Windows machines is to do all normal computing from a limited/standard user account, ostensibly to prevent malware from exploiting default administrator privileges. However, under Vista/Win7, even administrator accounts run with limited privileges by default, and will be prevented from performing any tasks that require administrator privileges, including running software located outside of designated locations if a software restriction policy is in place.

Therefore, it seems to me that for single-user machines (where you do not have to worry about errant users making unauthorized changes to the system), maintaining separate limited and administrator accounts serves no actual purpose. In short, I'm not aware of anything that can be done on a Win7 admin account that cannot be done on a limited user account without privilege escalation in both cases.

So, what am I missing?

 

[mechBgon]

This is good reading: http://blogs.zdnet.com/security/?p=175

Russinovich stressed that UAC's fundamental contribution is to make it possible (in most cases) to run as standard user to protect the system and other users on the system.

"Elevations are a convenience and not a security boundary," Russinovich reiterated, hinting that Windows will evolve further to promote the standard user concept with things like per-user installations and secure elevations.

Emphasis mine. The rest is definitely worth reading and following further, here's his full essay on the subject: http://technet.microsoft.com/e...azine/2007.06.uac.aspx Might want to skip down to Elevations and Security Boundaries.

Mark knows what's up... I'm definitely sticking with a non-Admin account (and SRP). The only part I find a bit burdensome about that combo is dealing with .MSI files, since they don't have a Run As Administrator right-click option. I have to launch a command prompt as Admin, then use that to launch the .MSI file, because SRP applies to .MSI files (as it should).

 

[shiranai]

I don't see anything in that article that actually differentiates standard user accounts from admin accounts in a way that matters for single-user machines. The article states that, "user accounts are an example of a security boundary in Windows because one user can?t access the data belonging to another user without having that user?s permission." But this is completely irrelevant if there is only one account on the machine that actually has data. The elevation hijacking that is outlined in the article applies equally to standard and admin accounts; apps with elevated privileges can be compromised regardless of the account you're running from. (Edit: in fact, the text of the ZDnet link specifically discusses a shift to user-mode malware, which would be effective even when running in a standard user account).

It's not even the case that the admin account has greater write privileges than the standard user, because the admin account is not actually part of the administrator group by default. As a result, SRP works identically in an admin account as it does in a standard user account - the admin account can't write to the Program Files/Program Files (x86) directories, and can't execute any programs outside of those directories.

My point is, a standard user account and an admin account are functionally identical in a single-user environment; in a multi-user environment, the standard user wouldn't know the admin password in order to elevate privileges, but that's not the case here.

 

[mechBgon]

At the risk of mangling Mark's message in translation, I think what he's said a couple times is that hey, if you elevate something but then plunk it back onto the same desktop as other apps, then input could conceivably be fed to the elevated process using an unelevated process. And thus UAC and elevation as a whole doesn't constitute a true security boundary. Doing a full-on Fast User Switch to the Admin account, that would constitute a security boundary.

So I guess you're right, to a point: if you're going to do Admin work from the Standard User account anyway, then maybe you won't gain any security benefit from having a Standard User account (as long as UAC is set up the same for the Admin account, meaning maxed-out and demanding credentials on the Secure Desktop, not just Yes/No). I have to admit, taking "the easy path" by using UAC is very convenient, and the cross-application hijack scenario sounds far-fetched today. Then again, five years ago we didn't expect our networks to be menaced by infected digital picture frames either :evil:

Thinking over my own usage, I do tend to use the convenient crutch of UAC when I ought to actually switch over to the Admin account as a matter of best practices

 

[shiranai]

Okay, I can see that, thanks.

FUS gets pretty irritating pretty quickly, especially if your installations are "for all users" - even deleting desktop shortcuts requires administrator privileges unless they're in a particular user folder. And then there are programs like Secunia PSI and Realtemp, which require administrator privileges to function. If I'm reading Mark's article correctly, elevating even once from a standard user account potentially compromises the admin account permanently, since code injected into the elevated application can then modify data on the admin account, which can of course then be used to inject arbitrary code into any application run by the admin account.

 

[mechBgon]

One area where I do bother with the FUS, is when someone's posted a suspicious link and I want to investigate it for possible Moderator removal. Since a compromise of a Moderator account could lead to catastrophe, I switch to a different Standard User account that's a total stranger to the AT Forums and check out the link manually. We've had a compromise in the past, and it's fortunate that the perpetrator chose to do only minor mischief :Q