Install programs in limited user account

Yes, indeed... Yesterday, I was in front of my computer until 3.30 AM reading here in this forum...

I've understood this time From your point of view, the goal is to make quickly what we have to do using limited account with admin rights (when needing) or with normal admin account, to switch quickly to a safer normal user account.

I'm very interestied in understanding what you said so interesting about FAS advantages, could you reexplain it, please ?

 

Well, yes, the idea is that you only have admin privileges when you absolutely need them, and when you don't need them, you go back to the limited user account.

Like I tried to say earlier, the benefit of FAS is really that it's faster than logging out (since you're just switching accounts, not really logging out, so none of your programs are closed and you can switch right back to them after you're done as admin) and it's safer than Run As or MakeMeAdmin (since it uses the secure desktop for the password dialog).

And then there's that ownership issue that I very poorly tried to explain earlier. Every object and container (file and folder) has a creator/owner. Creator/owner by default has full control permission, meaning, it can do anything to anything it owns. Creator/owner is either an account or group. For example, it could be a limited user called Mike, or a group called Administrators that contains all accounts that have administrator privileges. Creator/owner is usually the account that created the object or container. So, if a limited user creates a folder, they become the creator/owner and can do anything to the folder. When this becomes a potential issue is when someone elevates a limited user into temporary admin status, and creates some files and folders. After that, when the limited user is made really limited again, that account still remains the creator/owner, and continues to have full control. That means that the account could then change or delete stuff that it shouldn't have permission to delete. MakeMeAdmin causes that issue, FAS does not.

You can read more about that subject from here, for example: http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/193721.aspx Look for the part where it says: "Objects created while running with elevated privilege"

My brain is too messed up today for me to be able to explain it in any way that makes sense. I really shouldn't be posting when "tired".

 

According to Aaron:"Those access rights will remain even when I am no longer running with administrator privileges." So even, if we reboot the computer, these extended privileges from user account elevated to admin, remains. That's why the idea to temporaly elevate the user account rights is very important. But how to do it ? Which programs ? SuRun ? PGS ? Norton UAC ?


Thanks Windchild for your effort !!

 

How to do it? Windows UAC is safe. FAS is safe. Logging out the traditional way is safe. If you want to stay logged in to the limited user account and then elevate something to admin, you can safely use Run As if you're sure your account is not infected with any keyloggers. Otherwise, UAC is a good choice. Many people here also recommend SuRun for that, so I think you should be safely able to use SuRun, after learning how it works. The only reason I don't recommend SuRun is because I've never used it, so I know very little about it. Oh, and Norton UAC is okay, too. But really, I think SuRun will do what you want. Unfortunately I can't be much help with SuRun, as I don't use it. But there are folks here that do use it that will probably be able to help you if you ever run into trouble with SuRun that you can't solve by checking out the instructions/manual/help file of SuRun.

All right, I'm heading to bed, before I stop making any sense at all. Cheers.

 

Regarding what I wrote yesterday night, my questions were not detailed, I was a little confused in my head too.

If we reboot the computer, these extended privileges from user account (elevated to admin) remains, even after reboot, so that the owner has an admin privilege. How to come back with the previous privileges from a normal user account (after beeing installed a program for example) ? That's my question. I hope this time I'll be fully understood

 

Well, we have a misunderstanding there. No extended privileges will remain. The limited user account will not have admin privileges after you've used something like MakeMeAdmin and closed the command prompt. That's not the problem.

There's two things to consider here. One is privileges - they are like special powers that allow those who have them to do various things. For example, there's a TakeOwnership privilege that is assigned only to admins that allows the admins to take ownership and therefore full control of any file, no matter who created it. Admins have a whole load of privileges that limited users don't have, and that's part of what makes admin accounts so all-powerful. In this case, privileges aren't the problem. The problem is with file permissions. File permissions are simply lists of what kind of access different accounts have to some file (or folder). When you create some file, you usually become its owner, and owners get full control permissions to do anything to the file. This is the problem here. Because, when your limited user account is temporarily made admin, then used to install some program (create the files and folders for that program) and then returned again to a real limited user account, the limited user account becomes and remains the owner of those files and has full control permission on them, even though the account no longer has any admin privileges at all. So, the limited account doesn't have extended privileges - it just has some write permissions it should not have that can provide a privilege escalation route for a malicious user or software that is clever enough to try to replace those files and then wait for an admin to execute them.

What you want to do is make sure that the limited user isn't the owner of any important executables (like those in Program Files) and doesn't have full control or any write permissions over them. You can check file permissions in Windows Explorer in the file/folder properties by using the Security tab. If the Security tab is not there, then you're running something like XP Home, which doesn't have it unless you boot to Safe mode. Or, you can avoid the entire problem by never elevating a limited user account into an admin, and just using a normal admin account for installing software. FAS, Run As, etc all work there. I'm not sure, but I seem to remember hearing that SuRun also has settings that allow you to make sure that the limited user does not become the owner of any files you create while using SuRun to elevate privileges (probably some setting like Make admin group the owner of objects, instead of the creator of the object).

 

Windchild,

You are a excellent teacher, you can believe me !!

You understand all my request, even with my bad english !

Yes, it was a little bit confous on my mind about ownership and privileges and user account, now all it's clear.

Yes, what I wanted is to make sure is that after installing a program (with adding admin rights to a user account) it doesn't have full control or any write permissions as you said.

I'm under Vista 32 bits, and it's trough the security tab to access to the permissions, but it's a little bit hard to do it. I hope that SunRun can do it these changes. I'm wondering if Malware Defender can do it also. I'd like to find a easy prog to change these settings in the Security Tab.

Thanks again for your patience Windchild !

 

Luckily, there are easy methods to make sure the permissions are the way they're supposed to be with Program Files.

There's a program called AccessEnum that can show you a simplified view of permissions. You can get it here: http://technet.microsoft.com/en-us/sysinternals/bb897332.aspx When you run that, choose the Directory to be Program Files and then hit scan. It will produce a list that should say that pretty much everyone has read access to all the Program Files subfolders and files, but only admins, system and power users have write access. If anywhere in the list it shows write access for Users, Authenticated Users or the name of an account that you know is a limited user account, that may be a problem. If it only shows write access to admin, system or power users, it's all good - no problems. But this tool can be used to easily detect permissions that aren't quite right.

Then, if you find problematic permissions with AccessEnum (or otherwise), you can just change them in Windows Explorer, Properties / Security tab. It may look a little complicated at first, but if you're careful and take time to think about it, it's not very difficult at all. In the Security tab there is an Advanced button, and that will show you a new window that has an Owner tab. The Owner tab contains information about who owns that file or folder, and also allows you to change the owner. The Advanced security settings also allow you to apply the same permissions and owner to all the subfolders and files inside a folder. That way, you can quickly apply the same permissions and owner to a large number of files and folders.

But, you really shouldn't have to change this stuff often. Problems shouldn't occur unless you use something like MakeMeAdmin to elevate the limited user temporarily to admin rights. If you switch via FAS, or use Run As, no problems. And again, I think that if you check the settings of SuRun, somewhere in there is a setting that allows you to decide who is made owner of files created when you use SuRun - the owner should be administrators, not the creator.

Well, my explanations still are a bit cumbersome, and I'm still in need of more sleep, but perhaps this is mostly understandable.

 

Windchild,

Why there is no problem with "Run As..." ?

In the past, I changed the permissions, but it was still hard. I know there is program to do it easily, but I couldn't remember the name.

Anyway, AccessEnum is excellent to view permissions

 

Because when you use Run As, you're not giving the limited user account elevated privileges, you're logging in to a different account, and that account is then used to run what you were executing with Run As. That means that the limited user account does not become the owner of any files created, because it's not the limited user account that actually creates those files.

For example, let's assume you have a limited user account called Mike and an administrator account called ADMIN. If you use something like MakeMeAdmin when you're logged in as the limited user Mike so that you can install some software, then the Mike account is temporarily given administrator privileges, and the Mike account becomes the owner of any files that are created when you're installing that software with those temporary admin privileges MakeMeAdmin gives. This causes the problem with permissions that we talked about earlier. On the other hand, if you use Run As when you're logged in as Mike, to run something as the user ADMIN, then the Mike account is never given any extra privileges, and instead Windows uses the account ADMIN to run the file you wanted to Run As - and now ADMIN, and not Mike, becomes the owner of any files created, because it's ADMIN and not Mike who creates those files.

 

Yes, but since this file was created by ADMIN (and running with Run As in the limited user account), rootkits and malwares could infect this file.

So, with Run As, it doesn't change the owner of the file.


I have another little question under Vista 32bits, when executing Run As, it doesn't ask me for my admin password. It's bizarre !

 

Ok, I didn't understand any of what you just said. Sorry.

If you used Run As to run something as ADMIN, instead of elevating the limited user Mike in our example to administrative privileges, the ADMIN would become the owner. That means that Mike, the limited user, would not have any write access to the files created by ADMIN, and therefore any malicious program executed in the limited user account would not be able to infect the files. No write access, no infection.

 

Yes, I'm agree with you ! I had already understood that.

I was talking regarding the file, I wasn't considerate the limited account or admin privileges. If the owner of the file A is ADMIN, whatever the active account (normal account or an admin account), the owner is the ADMIN, and as you said, the ADMIN has total control of this file. So, if your received a pc's attack, this file could be aimed because the owner is ADMIN, and thus, take fully control of this file.

My little question was, why Vista don't ask me for the admin password when running a file in a limited user account ?

 

I still don't understand. When ADMIN is the owner, and limited users have no write access, then only the ADMIN can write to the file and modify it. That means that if you are logged in as a limited user, and get some malware or even a malicious user that tries to attack and modify that file, the attack will fail completely and can't do anything to that file (except read it, of course). So, the attack could not get any control over that file. On the other hand, if you're logged in as an admin and then get some malware, then obviously the malware can do anything to anything since it has full administrator privileges. That is exactly why one should use a limited user account for anything that does not require admin, and why one should make sure that no limited user has write permission or full control permission on any important executable files or system files.

That I cannot say. If you use Run As Administrator, it should definitely ask you for the admin password.

 

You said: "That means that if you are logged in as a limited user, and get some malware or even a malicious user that tries to attack and modify that file, the attack will fail completely and can't do anything to that file (except read it, of course). So, the attack could not get any control over that file. "

I'm OK with this, but from your point of view, it's the same with a Run As.

I was thinking about an exe file 'A' Run As ADMIN, and while running this exe, someone from the net, was taking the control of this file, he can do it anything with the file (because, this file was Run As ADMIN), while all others files are blocked with no write permissions and not full control. So, the malicious user can't take control of my computer but only, can take control of the file 'A' Run As ADMIN. I'm sorry, but not easy for me, to explain in english

 

Ok, now I think I understand. You're talking about a situation where you use Run As to run some exe as administrator. In those cases you must remember that anything that runs as administrator effectively is administrator. For example, if you use Run As to execute your browser as admin, then the browser can do anything an admin can do - and if you happened to browse the wrong site, you could get infected with malware that would also run with administrator privileges and could do any kind of damage to the entire system from installing rootkits to destroying all files. It could certainly do anything it wants to file A as well as all other files in the system no matter who owns them. When you run something as admin, ownership doesn't really matter - admins can do anything to anything. Ownership is an issue when you are running as a limited user.

So, remember that when you Run As something as admin, you are giving that program full admin privileges to do anything it wants to your system, just like if you had been logged in as admin and executed some file from that account. And using that program you yourself can obviously do things that only admins can do. This is no problem if the program you gave admin privileges is a good, benign one like say the Firefox installer. But if the program is malicious, or can be exploited by something malicious like a web browser or email client could be, then you would be in trouble. Obviously though, "someone from the net" can't take control of whatever you're running as admin just like that - they need some way to do that, like for you to browse a website that is serving malware. In this sense, Run As is just as "dangerous" as being logged in as admin. The "safe" part to Run As is that it does not make a mess of file ownership and create weaknesses in the file permissions that could be used to maliciously escalate privileges from a limited user account to admin.

To clarify... you said: "So, the malicious user can't take control of my computer but only, can take control of the file 'A' Run As ADMIN." As my explanation above shows, this is not correct. In this case, the malicious user can take control of the entire computer, including file 'A'. This is because the file A runs as admin, and anything that is executed or done by file A also runs as admin. Hopefully, that makes sense.

 

It doesn't matter what we call it. Some want to call it 'feature by design' or any nice terms. Some people do call it bugs:
http://technet.microsoft.com/en-us/magazine/cc160944.aspx
http://www.symantec.com/connect/articles/lua-bugs-basics-and-mitigation-techniques

The name doesn't change the fact. Simply put they are 'things' which make you harder and more painful to work with if you want to run LUA.

Yes but some good programs do like sandboxie. A good program can make such a 'mistake' too.

I also found many programs refuse to install if we don't run as an admin. I think most of them don't really need admin privileges but they just refuse to install.

Telling people to find alternatives don't work effectively (at least in my cases). Reasons:
(1) There are costs involved to switch LUA. Finding alternatives is not as easy as pressing a button: time costs, efforts of adapting new programs etc. These costs are big enough to annoy them and abandon LUA.
(2) Alternatives are unable to fully replace what they use. Sometimes some minor differences do count. For example Program A offers one-button backup function or explorer integration but Program B not. It's enough to make them stop.
(3) They don't want to dump it if they have paid the software

Well it doesn't matter how we put it or describe the situation. Whether we should put the blame on Microsoft or third-party programs or both or even users, it doesn't really matter. After all the problem exists. That's what we face, no matter who is the one to blame.

Home users can benefit from running LUA too but Microsoft is unable to offer a product which can satisfy their needs.

Windows XP Pro targets for small business too by the way and they complain about the inconvenience and cumbersomeness of using LUA too.

First of all, I don't know if you agree on that. There is a difference in preventing a normal user from doing mistakes and infecting the computer and a malicious user from doing bad things and infecting your computer.

It's much easier for a hacker to compromise your security setup if he has access to your computer and can issue commands directly.

A default LUA setup doesn't prevent a user from executing programs from DVD or USB devices.

There are some AutoRun registry entries where a LUA user can write or access too which are exploitable.

You can put LUA malware in user folder and run here.

You can plant a LUA keylogger or trojan and when the next person uses that computer you can steal his credit card numbers, login accounts, passwords, financial data when he is online shopping or do online banking.

You can restart the computer and bypass the restrictions easily.

A BIOS password doesn't help either. There are ways to bypass that protection too without the need of opening the case and removing the battery.

I'm not going to post the step-by-step instructions on how to achieve these. I believe it's forbidden. Search the undergrounds for information if you are interested. The hackers are happily discussing how to bypass LUA restrictions. It's pretty easy once you know the tricks.

After all LUA is not fool-proof and there are always privilege escalation vulnerabilities which may not be fixed yet.

Yes in some cases, but that could be a problem if the LUA account is meant to be used by multiple users. Well we don't expect our users are evil or malicious anyway.

Unfortunately it's not true in my case. I know quite a few have their favourite programs and they are not going to just dump them if they can't run perfectly in LUA. They would rather dump LUA.

Some people have purchased their software so they will not throw them at anytime soon.

For some people who just use computers to do very simple tasks like browsing webpage and checking email etc., I have a even better solution than LUA. I simply tell them to use Ubuntu.

I tried LUA because I want to recommend my friends and acquaintances who are not computer literate. But I also found LUA too much of an annoyance when I tried it. Most problems are not serious. You may not realise if you didn't use it previously. For example windows explorer integration is missing. Extension association doesn't apply properly. The new icon doesn't show up. Desktop shortcuts or start menu entries are missing. A missing shortcut or entry can be serious annoyances for the non-techie because it would mislead them that the program fails to install and waste their time and efforts.

I found many programs refuse to install if we don't run as an admin. I think most of them don't really need admin privileges but they just refuse to install. I don't believe they are all DOS-era programs.

It also makes me harder to troubleshoot and fix problems. Since LUA often cause something to be broken I often suspect LUA is the culprit when the program doesn't seem to work what I expect. You have to test all the way to verify if LUA is really the cause. You get distressed when a problem occurs and you don't exactly know how to fix it. You may have to search all ways on the Internet to see what's wrong. You really get fed up with that kind of things which keep happening.

Let me describe it with a real case so you could feel the pain. Microsoft Office have some minor problems with LUA too. Some parts of files are set to be installed only when you use those features. You run Excel and you want to use one of those features in one day. It will prompt you to install. However it just fails. Hmm... What's wrong? After a few thoughts you remember this is a LUA account. Probably you have to switch to install those features. *Annoying* OK you switch to admin account to install it. You think it's all over and you are back on working. Well no. The feature isn't there. It still prompts you to install. I have installed it already in ADMIN account. What's up? Really your brain feels very heavy. You don't feel like solving this mysterious puzzle but you are forced to do. Your work has to be put off again. Try to fire up Firefox and search on the Internet for solution. You search a hour but couldn't find any solution. Hmm... *Headache* *Headache*. Let's call it a day. Too tired now. Need a good rest. You shut down the computer and sleep. Next day you restart your computer and open Excel. The feature is mysteriously installed successfully. Installing such a feature shouldn't need to restart. Is it really the cause? *Shrug* Well, anyway, you can't bother to waste time to find out the truth. You have to work now.

 

Of course it is the former

The former: Limited rights by default but some programs with admin rights
The latter: Admin by default but some programs with restricted rights

Running with SuRun is better than running LUA alone. LUA is really painful to use. The user experience would be better with less annoyance and inconvenience if you use with SuRun.

I haven't tested it thoroughly but I recommend SuRun currently.

 

Some answers to a resurrected thread

Yes. And those things are about 95 % the fault of third party software developers. The 5 % are Microsoft's fault, and most of those issues have been fixed since XP...

In that case the program is, in that aspect, either poorly designed or has a valid reason to expect it will only ever be executed with admin privileges (reason such as it can't possibly work without them due to what it does).

It is not surprising. You cannot install software "globally", for all users, in a limited account. And many installers assume you want to install for all users, instead of just the current account. Solution? Find a software that does install for limited users, or install the software as admin for all users.

It has worked effectively for me and many other people that I know. For some other people, it may not work - for example people who are emotionally attached to software - but what can we possibly do to change this? Nothing much, so we simply have to live with it.

That's a pretty huge generalization. Most users don't know of LUA at all, so they can hardly be dissatisfied in it. Many who have tried LUA (most far less than seriously) are displeased with it. Many who have tried LUA are pleased with it. I know many home users who are satisfied with LUA. LUA is cumbersome if you run poorly designed software. If you run software that was designed to work properly on Windows NT, then LUA is not cumbersome - any more than running as a normal user is cumbersome in Linux.

Yes. This is extremely obvious. It is always wiser to not give physical access to untrusted users. Sometimes it is not possible to entirely avoid this.

No, it does not. And it should not. People who use LUA may want to run software from portable media, as well. I certainly do. This is not a vulnerability. And it poses no threat to other user accounts or the system.

So? Are you trying to say limited users shouldn't be allowed to set programs to start automatically when they log in to their own account? I agree with MS on that subject - they should be allowed to do that. It is not a vulnerability. And it poses no threat to other user accounts or the system.

Yes, and that's not a problem. Limited users should be allowed to run software, too, do you not think? If you want to prevent limited users from running unauthorized programs, that is not the job of the user account system. Use an executable whitelist type software for that, like SRP or Anti-Executable or something.

You can plant a keylogger only into the currently logged in account that the attacker has access/passwords to. But you cannot affect the other accounts, or the entire system. So: give everyone their own personal accounts, don't give untrusted people the password to your limited user account, and this is not an issue. The attacker can only infect his own account, and no-one else will suffer, assuming everyone will only use their own personal accounts.

How is this something that the operating system needs to, or even could, handle? For physical security you need to use physical solutions, not software, to prevent such attacks.

No, it's not forbidden. But since you started this "bypass LUA" topic, you could at least show even one real example of how it can be currently done on a patched system. And do note that
a) Attacks that require you to shut down the operating system to bypass operating system security don't count, because the operating system can't protect anything when it's not running, and such attacks need to be countered by other means, and a reasonable admin will do that.
And
b) attacks that allow you to run code in only the currently logged in limited user account do not count, because that's "working as designed." Limited users are and should be allowed to execute programs and set programs up to start automatically. This is not a problem. It cannot be used to attack the entire system or other user accounts, without exploiting an unpatched privilege escalation vulnerability.

So, you need to find a case where LUA was bypassed so that a limited user was able to affect the entire system and all user accounts, and not just his own account, without attacking the system physically, for example by shutting down the OS and loading another. In other words, a privilege escalation attack is required, and that requires finding an unpatched vulnerability. It isn't exactly easy, assuming the system hasn't been loaded with poorly designed software, like some old versions of security software that provide easy opportunities for privilege escalation.

Sure, nothing is fool-proof. But that said, how many unpatched privilege escalation vulnerabilities in Windows do you know of? Any examples?

Don't give multiple users the same LUA account, unless you are prepared to accept this issue. There's no problem in making each user their own LUA account. And really, you should perform backups. If you have to nuke an account, just restore it from a good backup. Problem solved.

Sure, you can do that. But that does require people that aren't emotionally attached to some software, since many Windows programs will not work in Linux. And if you have a user like that, they could already use Windows LUA. As far as Linux is concerned, you do need to use your head there as well. If you allow your users root access, they can mess up the entire system just as well as a Windows admin account could. So, you do have to use LUA in Linux, as well, it's just not Windows LUA.

As I said, it depends on what software you run. Run poorly designed software, get poor experience as LUA. Run properly made software for NT, get a good experience as LUA. No harder than that. If you can't run properly designed software, then LUA is going to be annoying for you. But in that case, I submit that you already have bigger problems than just that, because you're running software that wasn't really designed for NT Windows.

As for troubleshooting... If something doesn't work in LUA, you can test if it works in admin accounts. If it does, then it's an issue either caused by an inherent LUA limitation, or a LUA bug in the software that you're troubleshooting. It isn't that hard. But obviously, troubleshooting anything is difficult for Joe User - which is why you should give Joe User the kind of software they won't need to troubleshoot all the time.

And this is why you should make a complete install of Office in the first place, and you wouldn't need to run into this issue - install all the parts that you might possibly require first, so you don't have to install them later, when it's less convenient. It is, after all, only logical that limited users cannot install software for all users.

 

Not sure if somebody else has mentioned it yet, but beyondtrust.com has the perfect application for managing these issues. This app has been around for years, and mainly used in larger deployments, but the local policy configuration is free, and is exactly what you need in non-group policy environments. Take a look at it, it has solved all my issues with running LUA and been a major time saver...

 

Yes, he said a reboot solved it. I should think a simple logging out of the limited user account and logging back in would have fixed it without reboot, unless the extra components were rather "critical" ones and installing required a reboot. I'm guessing he either used RunAs or fast user switching to install the Office components as admin, all the while with the limited user account still being logged in. Of course, if a complete install of Office had been done when Office was first installed on the system, this issue would never have occurred.

 

Don't know if this should go in this thread, but didn't want to start a whole new one cause my questions involve the LUA.

If I'm running in a LUA the whole time, when my anti-virus,Prevx,Malwarebytes,etc...automatically update their definitions, will these updates carry over to the admin. account? Or would I have to log in to the admin account and let them update again?

2. If I install a program in the admin. account, will it be available in the limited user account or will I need to install it again?

3. In reading this thread I found out that I think one thing I did is probably not a good thing. When I started this "project" of using a LUA, I was trying to copy my admin. settings to a LUA account.

I could never get that to work, so what I did was created a new admin. account and changed my original(the one I had used from the beginning of getting my computer) to a LUA.

Now, considering what Wildchild has said, all the programs I installed in the now LUA when it was an admin. account will still be subject to any changes even though it's a LUA now, right? So, it defeats the purpose of a LUA in those instances?

All this is just confusing for me. lol If I had only known more about the LUA when I first got the computer, I could have avoided all this.

Anyway, just to be comprehensive. I'm running a Vista 64 bit, with Outpost Pro,Avira Prem.,Prevx,WinPatrol and Malwarebytes(paid).