That's just negligence, especially these days with real-time cloud synching and versioning. If I got hacked right before my house got hit by a meteorite the likes of Tunguska, I lose no data. Assuming I wasn't in the house at that time, I'd be able to access it immediately. True but PII getting compromised is almost a guarantee anymore due to entities beyond one's control (US gov't, credit bureaus, healthcare, etc. getting successfully hacked not to mention availability of public records).
Absolutely, I agree - but then again I think it's negligent to get infected at all I did find a 2011 paper from a researcher at Secunia in the context of end-point security in an organisation, which follows a similar line of reasoning as my arguments and expands on them. It's a bit out-dated in terms of the privilege escalation stuff for Windows XP, but otherwise still a relevant read. The author's conclusion is that LUA is recommended as a complement to end-point security (so in line with MisterB's): https://secunia.com/?action=fetch&f...riminals_do_not_need_administrative_users.pdf Still haven't been able to find more recent stats I'd seen in security blogs which suggested that LUA happy malware had become the predominant type, but the point stands that the most common aims of malware can be achieved in LUA, and that malware that works in LUA is more likely to succeed in a large scale. Unfortunately very true.
One question regarding LUA vs. Admin+UAC on max. I have read many times how LUA would prevent a lot of infections and exploits. Would all those infections fail with admin account and UAC on max (user would not confirm elevation)? Any info or reference would be greatly appreciated.
@Minimalist Windows has a complex set of rights assignment based on user rights (admin or LUA), system integrity levels (system, admin, normal=simular to LUA, low and untrusted/appcontainer) and Access Control Lists (on folders, files and registry). http://www.windowsecurity.com/artic...y/ways-grant-elevated-privileges-windows.html
That is for an unhardened system. In a properly hardened system with execution privilege limited, it would be a reset like I said in the first place. The exploit would never get anywhere near the kernel. In such a system, the code that would damage user data and encrypt it would never execute in the first place. A LUA is essential in a hardened system. Running Windows in admin mode is always risky behavior. Just because the default LUA in Windows is weak enough to allow some malware to run doesn't mean a LUA isn't the correct approach. In a hardened LUA, that possibility is eliminated.
Thanks. I just can't find any reference that would show how is admin and UAC (denying elevation) different to LUA when it comes to malware infections and exploits. MS usually says something like: "90% of exploits would fail under LUA" and never "80% of exploits would fail under admin+UAC" [numbers are made up].
UAC won't prompt you if a program wanted to scramble/delete user data files and with admin access, user space = everything. If you can run LUA without hassle, do it. The problem is, a lot of software requires an admin account to even run or run properly, so, for me, it isn't feasible. It also doesn't help that some software circumvents what meager controls Windows has by installing in the user profile areas rather than in Program Files.
UAC is a warning system, LUA is a wall. If you know how to set ACLs and group policy, it is not so easily bypassed while UAC just requires a dash of social engineering to get around. With a LUA, you are operating at a low privilege level that requires a log on to an administrator account to elevate. With UAC in an admin account, you are operating at a high privilege level already and UAC is just warning you that some piece of software is about to use that privilege. I use ACL to lock down the user profile areas so any software that wants to install itself there is out of luck. I'll find an alternative that doesn't. A lot of the issues with LUA incompatibility are fixed by ACL tweaks as well. It's usually changing permissions from read and execute to read/write in a data folder in the program's folder in Program Files. I could allow binaries to execute in the user folder using the opposite tweak on a per app basis but I don't find that a good security habit and I'd rather find software that doesn't try to install itself there.
Thank you for explaining the difference. I'm still interested in "real life" security difference using one or another. I didn't find any article about it so I guess nobody bothered to test it.
Sometimes you just have to take the time to try an experiment yourself. I've been using LUAs and ACLs since the days of Windows NT4, long before UAC existed, and I have had to do a lot of trial and error work in learning how to use them effectively. I can't think of anything specific to this question but one of my favorite sources for information on Windows internals and security is Mark Russinovich's blog. He hasn't put anything in it recently but it is a wealth of information on Windows Security issues. http://blogs.technet.com/b/markrussinovich/
OK, thanks. I've been configuring ACLs and also used LUA in past. Now I'm happy with admin account, UAC, SRP and other OS hardening. I'm more interested in statistics as I explained in post #56. It looks like their is no such statistics and research so it really doesn't matter.