Install programs in limited user account

1. I have set an account as a limited user in Windows XP. It has to temporarily run as an administrator when he wants to install a program. Most of the time it works but I encountered a few cases where the programs have problems or simply doesn't run in limited user account. What can I do to fix or minimize those problems?

2. Sometimes a program installs but only install on that user, in this case, it would be the administrator, so the limited-user account can't run that program. What can I do to instruct the program to install on all users? Thank you.

3. I have a question about the security of logging in admin account while using limited user account too.
Let's say I'm using a limited user account. In the middle of the day I want to install some programs which requires admin privileges. I switch and log in admin account to install. BUT I just switch back to limited user account without logging out the admin account.

Is it possible for the malware to successfully infect my computer and somehow get admin privileges if the malware drives by when I'm browsing in LUA?

 

Ah, the joys of LUA. There are some nice discussions on this in the 'other security issues and news' forum. Look for Tlu's threads, or Lucy's. A sticky has some good links. In this forum is also a thread by Tlu on SuRun. Mrkvonic also has a good tutorial on SuRun on his website.

Sounds like if you are not using SuRun, you should check into it. It helps a lot.

I will give a technical detail for you. When you RunAs, there are different settings. One setting is to use the 'profile' of the admin account you are elevating to. This means basically, that when you RunAs the admin, the admins' registry hive and profile is loaded, and when you install the app, it is going in as the admin. When program is done, you return to your User profile, and if the program installed is not designed to be installed for everyone, you may not see it. You can open command prompt, and use the runas /? to check some of this and play with the different ways to use runas and credentials.

This is the problem with LUA I encounter, some of my favorite things just don't work properly. I have found creative ways around these in most cases by coding things up myself, but it is a pain sometimes.

I certainly advocate and wish I could run LUA myself without the constant futzing with it. For me, it slows everything down because I do so many things that need admin. But for a typical user, I think LUA is achievable. You just have to play around with stuff. SuRun should greatly help you if you have not tried it yet.

Sul.

 

1) In those cases, your step 1 should always be complaining to the author of the program that their software doesn't work properly on limited user accounts (unless it's a program that should require admin rights, such as a defrag program or any other administrative tool). Then you should take a moment to consider whether there is other software that can do the same job and also works properly in limited user accounts - if possible, switch to better software. After that, you can try to research why the program doesn't work. Most often it is because the program tries, stupidly, to write in Program Files or the registry HKLM where limited users generally have only restricted access (read, not write). In such cases, you can manually edit the permissions and give limited users whatever rights the program requires to work, for example, write access to the program's installation folder in Program Files. Keep in mind, though, that this has downsides and will decrease security. For example, if the program requires you to give limited users full control permission over its executable files to work properly, that means that any limited user can also overwrite the executables and replace them with any malware, which will then execute with full admin priviliges if an admin ever runs that software, thinking it has not been modified. Google helps here: there is a lot of material in various forums and wikis to help you solve LUA problems with various programs. One nice site to read is http://nonadmin.editme.com/
Microsoft Sysinternals has lots of useful tools for solving LUA issues. For example, Filemon and Regmon, and their new replacement Process Monitor. http://technet.microsoft.com/en-us/sysinternals/bb545027.aspx With these, you can log what the program you are having trouble with is doing when it's failing or giving errors, and can then edit permissions accordingly.

2) Pretty much the same as above. Depending on exactly how the program does not install for all users, the problem can be easy or difficult to fix. If the problem is just that it doesn't create Start menu shortcuts and such, create those manually. If the problem is that the program just will not execute or will give lots of errors, then you may need to edit some permissions.

All in all, though - it is always better to switch to programs that work properly in limited user accounts than try to manually hack programs that have been coded by lazy or ignorant people to work. Sometimes, of course, switching isn't possible.

 

OK. I'm searching right now. What're the names of the threads?
SuRun sounds great but I wonder whether the so-called secure desktop is really safe.

You spotted it.

Yes that's the bad part. The program is installed in the admin account, not the user account. So the user account can't run it.

This is the problem with LUA I encounter, some of my favorite things just don't work properly. I have found creative ways around these in most cases by coding things up myself, but it is a pain sometimes.

It's okay if the user has to type password to install programs. He can live with that. But he couldn't when the programs he is using don't work in the limited user account.

Sometimes Microsoft is the one who blames. Who knows you must have admin privileges to just change some basic non-harmful system settings like date and time? That's a bit annoying too.

 

Well, if you think about it, it's actually very logical that admin privs are required to change date and time. Why? Because changing time allows you to make a complete mess of system logs, file and folder creation dates and just generally make it impossible for the admin to find out what happened and when. You really don't want limited users to have the ability to set the date to 16.4.2007, 1.6.1786 or 17.4.2097 when today's date is 18.7.2009. The ability to set time and date is not non-harmful at all.

Obviously, in other operating systems such as Linux, changing the system date and time also requires admin/root privileges, for the previously mentioned security reasons.

 

You have a point. Unfortunately it doesn't apply to home setups where the family members share the computer. They would not do the malicious actions stated above.

Even if we are talking about a public computer, then I would say Microsoft isn't strict enough. Why? As a limited user, I can browse the program files and delete any files I want. There are many places I can mess around which are not in the restricted zone too.

Interesting read: Drive-By Download Attacks NOT Deterred by Limited User Account (LUA)

Too many things a malicious user can do to compromise the computer. Limited user account doesn't help at all if the user is malicious and wants to spoil your computer. Don't let the person use your computer if he is malicious, or make a much tighter setup so they are only limited to doing very little things on your computer. For example a public computer which only allows you to browse and you can't change any settings of the browser.

 

Yes I do it when I find. I would like to setup for home users who are the average Joe. The average Joe doesn't expect to complain to make their favourite software work.

I can't control what they want to use.

And sometimes there are alternatives there are learning curves involved. You need re-learn how to use the new programs. And the alternative program doesn't offer exactly the same set of features and mini-features that the original program offer. Well, it could be something as simple as a middle click to run an entry. But the new program doesn't have "the middle click" function. It does take time to adopt to using alternative programs.

Users who don't bother may give up and run admin accounts again.

Yes that's what I suspect too.
Sometimes a program stupidly installs on the current account only (we run as an admin account so it installs on the admin account only!)

Yep you are right. I think this is more of a threat of a virus than trojan/keylogger. It's because the trojan/keylogger doesn't know what programs we install. The programs which should be able to run in LUA but don't work properly are usually those which are less famous. The troajn/keylogger shouldn't hijack or target that exe which doesn't exist on many other computers.

That site you give looks very informative. It's just what I want. Thanks a lot.

Is it hard to utilize them in practice? I'm probably unable to decipher the error code and diagnose the problems without a real technician to help me either.

Not the missing shortcut, I have fixed a few already myself.
The program simply doesn't install on all users but the current user (which is the admin).

 

I have a question about the security of logging in admin account while using limited user account too.
Let's say I'm using a limited user account. In the middle of the day I want to install some programs which requires admin privileges. I switch and log in admin account to install. BUT I just switch back to limited user account without logging out the admin account.

Is it possible for the malware to successfully infect my computer and somehow get admin privileges if the malware drives by when I'm browsing in LUA?

 

Hi Masterton, Have a look at step 3 in this link as see if it helps with difficult programs. I haven't tried it as I've always had difficulty run a LUA in XP.

 

Some of them would. I know families where parents have trouble controlling their kids' use of computers, and those kids will attempt to do anything they can to hide what they're doing. But that doesn't really matter - Windows NT wasn't made for the home user in the first place, and network admins do need functionality to prevent limited users from messing with the system time. That is the same in all other meaningful operating systems.

If your limited users can modify and delete files in the Program Files folder, something is seriously wrong with your system. By default, limited users cannot write to Program Files: they cannot create files, modify files or delete files, or create folders there, in short, they can only read and nothing more. Actually, it even says so in that article you linked: "With LUA in Windows, nothing may be added to or modified within “Program Files” and “Windows”, for example."

If your limited users can write to Program Files, then there are two possible explanations that I can think of immediately: 1) Your filesystem is FAT32 which means you have no security at all as far as the filesystem is concerned - anyone can do anything. 2) Someone has changed the default file permissions. That someone is often the manufacturer of your PC.

As for public computers, I agree that further restrictions are needed in places where users are expected to be really hostile. But then, that's what group policy, SRP, guest accounts, Windows SteadyState and others are for.

Looks like a commercial for some whitelisting product, with pretty much the same functionality as the built-in software restriction policy in Windows XP and higher.

Of course, they are correct that malware could still infect the limited user account and do its thing there. But, it cannot make a system wide infection (without privilege escalation exploits or a stupid admin), and removal and detection will be easy. Of further benefit is the fact that most malware of this day just isn't made to work with LUA, and will completely fail. Some malware does work with LUA, but most of it does not. This will likely change in the future, but that's life.

I somewhat disagree here. A limited user account helps a LOT if the user is malicious and wants to spoil your computer. Unless you mean that the user has physical access and wants to physically harm the computer, in which case you're right. Limited users cannot make system wide changes. They cannot install programs globally, cannot change critical Windows files, cannot load drivers... This means that any changes the malicious limited user makes are easy to wipe out: just delete the user profile, and that's it. Use your head, though: don't give your own limited account to someone you don't fully trust. Instead, make a new limited user account and let them use that, and when they're done, you can delete the account if you want. That way, they won't be able to change your own account's per-user browser settings or anything like that. All of this, of course, is only valid if someone hasn't screwed up the permissions and privileges limited users have by default, as set by Microsoft. Usually this screwing up happens when the OS is installed. I've seen many a PC where the manufacturer has used FAT32 for the system drive or otherwise jacked up permissions. A sad case of affairs, really, but not Microsoft's fault. But yes, don't let malicious people use your computer at all. That is always wisest.

Using those Sysinternals tools takes some practice and knowledge, but it's not too difficult, and the help files are fairly good. It is much easier to do than it may sound. The programs have searching/filtering/highlighting functions which will help a lot. For example, if you have a program called DoesNotWork.exe that fails to start when you're a limited user, and just says Access Denied or some other error message that doesn't really tell you anything useful, you can start Process Monitor up, enable logging (Capture Events), execute DoesNotWork.exe and when it fails, disable Process Monitor logging and then search the log file for any references to DoesNotWork.exe. You will find a bunch of access denied lines in the log. That's what you're after. Those lines will tell you what DoesNotWork.exe attempted to access but failed. For example, if you see:
DoesNotWork.exe WRITE C:\Program Files\DoesNotWork\ ACCESS DENIED
In English that means that DoesNotWork.exe tried to open its Program Files folder for write access, but was denied access. To correct this, you would give limited users write permission to Program Files\DoesNotWork\, but that would have the previously mentioned security implications.
If you have problems identifying issues, you could always show the log file to someone with more experience with them. However, log files from these programs can contain stuff that you wouldn't necessarily want others to see, like signs of what programs you have installed on the system and even personal information (for example, if your user name happens to be your real name, the log will show entries like \Documents and Settings\yournamegoeshere\).

So it complains it's not installed when you try to execute it as a limited user? In those cases, you can often solve it simply by running the installer again, but in the limited user account. If that doesn't do it, sometimes more radical measures work - such as temporarily making your limited user an admin, running the installer, and then making the user a limited user again. This, again, would have the same security implications as changing permissions to allow limited users write access. Sometimes, you find that you can change the permissions back to admin - full control and limited users - read after you have installed the program for limited users as well (and do change the owner of the files and folders to admin, as well). Those programs don't so much suffer from a real LUA bug than just being impossible to install for all users at once.


All of this is a lot of trouble to go through for a few programs, though. Personally, I always switch to better software that already works as LUA without my help. Others may be reluctant or unable to do so, and those are the difficult cases, really.

I guess you're referring to Fast User Switching. In a situation where you're currently using your limited user account but also have the admin account still logged in in the background via Fast User Switching, any malware that you encounter in your limited user account is limited to that account. It cannot get admin privileges without using some privilege escalation exploit (which no malware in the wild today that I know of attempts to actually do) or using weak, non-default permissions to modify files that an admin will then later execute. For example, if your limited user account can really write in Program Files, the malware could just overwrite some program - say, like Adobe Reader - and next time an admin starts that program, the malware runs with admin privileges. But generally, the answer is no, the malware could not get admin privs.

 

(1) The drive is formatted as NTFS (2) No one has changed the setting. That isn't a manufacturer PC. Currently I'm testing the LUA setup in my test PC. I will implement them into use as long as I can solve the problems that I'm facing.

The more I investigate I see I can change some folders of program files, some not. That's pretty strange. I didn't micro-configure the program files. Here is what I did:

1. the default account is created. It's admin by default
2. install some basic programs
3. use "control userpasswords2" to change the privileges into "limited user account"
4. every time I install new programs, I have to use "Run as..." (admin) or the installation usually doesn't work

I have no clues why I'm allowed to write in some folders some not when I changed nothing about the permissions myself.

Yes it's because most Windows users are still using admin account so they don't bother making LUA malware. Based on this reason, LUA has nothing to do to stop a malicious user to install something to bypass your restrictions. I read articles in the past about how users can bypass the LUA restrictions to install programs etc.

It's useful if the user has good intentions, not if the user has bad intentions. I realise there are constantly ways people share to bypass limitations posed in public and LUA computers. I don't know how well MS Windows manage to fix it though. Of course LUA helps to reduce the damages a user can do on the computer but damages have been done.

How can I change ownership?

Yes you are right.

That's good news because people sometimes are lazy to log in and log out repeatedly.

The privilege escalation exploits, when found, shouldn't matter whether your admin account is logged in or not.

 

1. 
   
   That is the problem. Your account was first an admin. You used that admin account to install some basic programs. This made your account the Creator/Owner of the installation folders of those programs, all files, all folders the installer created. Creator/Owner, by default, has all kinds of access, including write, to anything he's created. When you later changed this account into a limited user account, it was still the Creator/Owner of the programs you installed on that account when it was an admin - and it still has write access because of that. You can check this by opening the file/folder properties on any file or folder you seem to have write access to even though limited users should not - in the Security tab there's an Advanced button, and under there there is an Owner tab that shows you who owns that object. That's where you can also change owners, if you are an admin.
   
   To correct the situation, change ownership on those troublesome folders/files - make the administrators group the owner of those files, or any admin account other than your current admin-turned-limited-user account. Then check again. You should no longer be Creator/Owner, so you should no longer have write access. If you do, check permissions to see if there are permissions set for that particular account that allow write (sometimes this happens). If so, remove them.
   
   
   It's pointless to argue about this, really. The fact is, that limited user accounts prevent system-wide software installations. They obviously don't prevent any account from installing software only for that account. That only makes sense. But running LUA protects other accounts and the system from tampering, and cannot bypass restrictions without weak permissions or privilege escalation exploits.
   
   
   It's useful no matter what the intentions of the user are, with the one exception of the user having physical access and intending to physically destroy the computer, or use physical methods to bypass protections (like booting from a DVD/USB, or ripping out the harddrive). Some "limitations" can be bypassed, but those seldom have anything to do with LUA. Most are just group policy based limitations like "don't show my users this button here", that mostly are for looks and to fool the simple-minded. The real limitations, user privileges and permissions cannot easily be bypassed.

 

Hmm... That would be difficult to maintain. It's because I want to setup a LUA for the average Joe. It's "too techie" for them. It's going to fail eventually. I wonder if there are some programs which can somewhat force the ownership of all files and folders in the program files to always admin.

I agree. But let's exclude the possibilities of the physically damage the hardware or opening the computer case. People won't do it even when they are using public computer. To put it simple, it's still easier for a malicious user (who gains access to the computer physically) to compromise our security than a hacker who has to attack a LUA computer remotely (which probably have to rely on the genuine user to make mistakes). You should further restrict your Windows and give even less rights if you expect a malicious user would want to use your computer. Disable USB ports and DVD reading device. Alternatively just don't lend your computer to someone you don't trust.

 

The easy solution, if one is unwilling to change permissions later, is to avoid ever changing admin accounts that have been used to install software into limited user accounts, due to the creator/owner permission issue. Instead of demoting an admin account into a limited user, create entirely new limited user accounts and never make them admins even temporarily. Then you use the admin account only for installing software and other admin work, and use the limited user accounts for daily use. This way, the admin is the creator/owner for anything installed for all users, in Program Files, and limited users will not get any write access there (unless the software is simply poorly made and automatically gives limited users access they should not have). There's a lot of discussion on that topic all over the net, including in this forum unless my memory fails me. My limited user accounts, for example, were all created as limited - they were never admin, so there aren't any permission issues.

 

LUA is a usability nightmare and total failure after many days of testing. Too many software are broken, from minor to major. Problems include missing new Windows Explorer functions (eg right-click menu integration, file format not registered correctly) to installing in the wrong profile (ie. the admin account).

Some programs like to store their settings or write some new files in Program Files and/or Windows. The developer makes mistakes but that's common and that's another problem.

You can't change basic system settings which don't have security risks. Date/Time settings and power management settings. For the power management the setting is user-specific so you can't change the power setting of the LUA even if you bother to log in to the admin account to do the small change. You just want to punch your computer if you are in LUA.

You have to search everywhere to find solution to fix the problems here and there, and you may end up asking on the forum to get help. Every time the program doesn't seem to run smoothly you will suspect whether it has to do with LUA.

What a mess! Too much trouble. Never recommend LUA to the average Joe unless you want to drive them crazy.

Next week I'm going to test another security setup and see if it's both secure AND usable for the average Joe.

 

All of these are issues that exist not in limited user accounts, but in the software you have been using. So, it's not Microsoft's fault, or a problem with LUA. Simply, the software you tested has a bunch of severe LUA bugs, ie, the software is buggy as hell. One should blame the coders who made the software that does not comply with the NT security model, even though that model is over 15 years old and has been public for all that time. You're using software coded by people who are still living in the DOS era. Be careful!

Sigh. We went through the Date/Time settings already, and no matter how hard we complain, nothing will change the fact that being able to change time and date has security risks, and only privileged users should be able to do that.

As for power management, that is an actual problem. Which was fixed in Windows Vista. Do remember, that XP came out a long, long time ago. The power management issue in XP, too, can be corrected by editing registry permissions (http://blogs.msdn.com/aaron_margosis/archive/2005/02/09/370263.aspx), or by temporarily changing the limited user account into an admin and changing power management settings then, before changing it back into a limited user account. But that is truly a bit tricky, and many don't bother with power management anyway.

Nah, most of the average Joes I've recommended LUA to have found it just fine, and none have gone crazy. But then, I also advise them to ditch poorly made software, when possible.

 

Agree, a lot of admin management console aps depend on the logs for incident management and intrusion detection. So for a sole PC it might seem 'over the top' to need admin rights to change date/time, for a management network environment with lots of clients/PC's in the network it is a deal breaker when limited users were allowed to do so. Also wrong dates make error back tracking very hard, cause the sequence of events can't be trusted.

Mind you that the business users paved the path for economy of scale, so the home users could afford PC's/software (my first laptop had the size of a suite case had a price tag of a big network server nowadays)

 

Yes we shouldn't blame MS for that. Well it's a history problem. MS Windows 95/98 is not multi-user so all developers write Windows-based software in the environment where the software can access to any admin privileges they want, even if unnecessarily.

Most software that I tried requires admin to install their programs but they are not admin-relared tools or software.

LUA, nevertheless, has some flaws. For example when I use Run As, the registry entries should be stored in the LUA user not the admin. AndI read that there are a few bugs which cause software to install improperly by Run As too. There are some third-party programs which try to fix that.

I don't see how the software must be some poorly coded mess or some DOS-era software if it doesn't work perfectly in LUA. Most install fine but you have to examine carefully and you may find there are a few areas that are broekn or missing.

I remember Sandboxie saves its configuration in Windows directory by default but his program isn't bad (you can workaround it but that's not the point. He shouldn't save it here in the first place).

I realise security-conscious users in Wilders gerenally don't want to use LUA either.

Your points is taken but as I already said the scenario is the user is not malicious and it's only a home / small business setup (where people know each others). I don't see how your arguments are valid in our cases.

You said a user can't change the time because it would mess up the time of the logs etc., it's not really a big deal if he changed it for good sake (eg. change because we are in different time zones). He is really naughty if he intentionally keep randomly changing. But I don't see how high a risk that someone would be so bored to do this silly thing.

After all he can also do other similarly nasty or annoying things even if he is in LUA, don't you agree? LUA is still unable to deal with a user just like a little devil who want to mess up your computer by any means he can imagine (excluding physically damaging the hardware).

Yes I know there is a workaround. But please bear in mind I would like to promote this for someone who don't have good computing knowledge to use it. How can I recommend it to a non-techie when there are so many problems here and there to fix? Sorry but he would just give up.

Well I would imagine they don't try software or use many software, or just don't realise something is missing/broken (eg. missing context menu shortcuts).

And even good ones make such kinds of mistakes. I remember Sandboxie saves its setting in Windows directory by default and that is a problem. A personal management program will crash if you log in to more than 1 account at once. It's because it attempts to run on all accounts but one instance is allowed. A simple fix is to suppress the autorun but again it requires manual fix and will annoy the non-techie. They just want to install and run.

I don't know people around you but I don't see how it's a feasible solution - tell them simply dump a program just because it can't be run nicely in LUA. It's annoyed enough to let them dump "LUA", not the other way round.

 

No, they should not. That is not a Run As bug. Run As works as designed. It's not designed to elevate the privileges of the logged in account (that is, to change a limited user to an admin temporarily). Instead, it's designed to let you run something in a different account that may have higher privileges that you can use for system-wide installations. One can argue that the design of Run As is cumbersome, or in other words that it would have been better to elevate the privileges of the logged in account instead of loading a different account. But one can't say that it's a programming flaw.

Yeah, and those aren't bugs in Run As. They're bugs in the third party software that expects that it was not executed with Run As, because the coders were too stupid or lazy to consider that possibility.

If it doesn't work properly in LUA, then it is with absolute certainty one of two things: 1) A program that has a valid reason to require admin privileges, because it does something that LUA simply can never do - like load device drivers. 2) A program that does not work correctly in LUA because it was coded by someone who didn't know how to achieve that, didn't care to make it work or just forgot about it accidentally - in any case, it can be considered a flaw in the software. Bottom line is: if it doesn't work in LUA, it's either not possible to make it work, or the coders screwed up. Most often, it's the latter. One just has to deal with it. Denying facts helps nothing.

There's no point in saving your settings in the Windows folder. That is just stupid.

That really depends on one's definition of security-conscious. But sure, if we define it as someone who knows a lot about random security apps and detection rate tests, but doesn't know much at all about the internals of the OS. There are a lot of people who don't run as LUA. And everyone who does run LUA is more secure thanks to those people (as long as a lot of people run as admin, there's less incentive for malware writers to code fully LUA compatible malware). And of course, if you already have a ton of security software on your system, for which you have paid good money for, then you need LUA a lot less than some Joe User who only has a free AV or pre-installed Norton that has long since ran out of the subscription.

The arguments are valid, because Microsoft did not code Windows NT for the family Masterton or for family Windchild. It's an operating system that was intended to be used equally by serious business users in large networks as well as some homeusers. That means that they have to build it so that it will work right, and can be secured, in the business environment. That means, they can't let limited users change the time and date, even if homeusers would really love that - business users would hate that, because admins would lose trust in their logs. If one doesn't understand it, then there's no hope for further discussion.

No, I don't agree, and you still haven't shown us what system-wide effects a limited user account can achieve to "mess up your computer." No matter how large his imagination is, unless he does physical damage to the hardware or physically circumvents LUA (loading a different OS from a DVD, for example) or finds a privilege escalation vulnerability, all that he can do is destroy files that he has write access to and change the settings of his own account. In other words, he can do nothing to mess up the system, but can do a lot to mess up his own account. But who cares about that? If some fool wants to mess up his own account, he's the only one who will suffer from that. And for the admin, it's easy to rebuild the account. Just delete the messed up account and create a new one, and that's it.

If he has good computing knowledge enough to change power management settings, then he can also follow simple instructions in plain English to do it as LUA. Or, if you want to help, you can do it for them. That's what I do. On the other hand, if they run Vista, you don't have to, because the issue is fixed in Vista, like many other issues. XP is an old operating system.

Indeed they don't. In my experience, the average user doesn't spend his day installing all kinds of new gizmos and programs for the pleasure of it. He's just trying to get daily tasks done: read and send email, write documents, do graphics or audio work, browse the web, sometimes run a few games. None of that requires admin privs, unless using poorly made software. I have repeatedly stated, and will continue to do so, that those people who do things with their computer have little trouble with LUA, but those who do things to their computer will have trouble with LUA. If you're always installing and uninstalling new software and changing system-wide settings every hour, then you would have an easier time being admin. But then, I can't see any reason why any user would do that kind of stuff on all their systems, all of the time.

It's a personal choice. Most average users aren't emotionally involved with pieces of software. So, if I tell them that "This thing is made by someone who doesn't know about Windows NT, and is still living in DOSland, you might want to replace it with something better, like this program here" they'll generally just shrug, and say thanks.

 

What is more secure, adding user rights from a user account (for ie, with SuRun) or restricting user rights from an admin account (for ie, with DropMyRights) ?

I guess the first, but I'm not sure... Let me know more, thanks

 

The first. Restricting user rights from an admin account - for example by running some software like a browser with lowered privileges via DropMyRights - is better than nothing, but it's still very weak and insecure compared to running as a real limited user. It is much safer to use a real limited user account, and perform tasks that require admin rights via secure methods like Fast User Switching. One shouldn't think of it as adding user rights, though. It's more switching, temporarily, to a different user account that has greater rights. Stuff like MakeMeAdmin and SuRun do temporarily elevate a limited user to an admin instead of really switching to a different account, but then, those are somewhat special cases.

 

Windchild, I don't really understand how switching temporaly with FAS is the more secure. Tell me more details, thanks.

 

I meant that FAS is a "secure" method for switching from limited user to admin and doing something that requires admin rights. As compared to, for example, just using MakeMeAdmin to elevate the privileges of the actual limited user account to admin, temporarily. With FAS, you are actually switching accounts, not giving a limited account temporary admin privileges from within the limited user account's desktop.

The FAS method - and other similar methods, like just good old-fashioned logging out of the limited account and logging into the admin account, or any Run As type utilities that operate in a secure desktop instead of working in the limited user account's desktop (apparently SuRun is one of these) - avoids many problems. One such problem that it avoids is that the limited account is not made creator/owner of anything you might install or create with your limited account that has been temporarily made admin, and therefore the limited account doesn't get full control permissions over what you've created. On the other hand, if you use MakeMeAdmin to temporarily make your limited account an admin, then that limited account becomes creator/owner and will get full control permissions on whatever you create while that account has temporary admin privileges - like some software's Program Files subfolder and files created when you install it with your temporarily-admin account. Another issue is that if you happen to have a keylogger running in the limited account, that might log your admin password if you use traditional Run As or something like MakeMeAdmin that doesn't use a secure desktop for entering the admin password. With FAS, for example, you're switching out of the limited account and into a secure desktop for the login screen, so a keylogger running in the limited account could not capture your admin password.

Ok, that sounded complicated and rather unclear, but my head isn't working quite right today. Yesterday was a long day.

 

Windchild,

It's so hard to understand for my limited english, I read your post 3-4 times, and I'm not sure I've all understood.

You state that FAS is more secure than adding or limiting user rights through MakemeAdmin, DRM or SuRun, because when swtiching we pass trough the secure Windows Dekstop.

So, if I understand, for example, I need to install programs I'll switch into my admin account and if I need to surf, I should keep my user account. But, how to run programs from a user account that I need admin rights from your point of view, if you exclude such progs like SuRun, DRM, MakeMeAdmin ?

Could you explain again the benefits of FAS with others words, please ?


Keep a repaired rest !

 

Yeah, sorry, my post was pretty hard to read. Brain freeze day.

FAS isn't very special. But it is pretty quick (quicker than logging out), and safe (safer than using Run As), and doesn't require any additional software to be installed. That's why I mention it. It's useful for home environments.

Yes, when you want to do something that doesn't require admin rights like browsing the web or email, it's best to use a limited user account.

For those times when you are in a limited user account and want to run something as admin, and really don't want to log out or use FAS, then you can use
- normal Run As if you're sure you don't have any keyloggers active (or you could use something like MakeMeAdmin, but that has the ownership issue to be mindful of)
- or if you want to play safe/paranoid, or suspect there might be a keylogger infection, you can use something that takes you out of the limited user's desktop and into a secure desktop for the password dialog. For example, UAC in Vista and Windows 7. I don't personally use SuRun, so I can't say for sure, but according to the SuRun website SuRun does use a secure desktop, and it should be perfectly safe in that sense. So, you can use SuRun, if you want.