SuRun: Easily running Windows XP as a limited user

Hi Easter, I would like to help you, but I have to admit, that I have partly difficulties to understand, what you mean; I mean, it is not always clear for me, in which situation you get which results.

Let me try anyway: You mentioned problems, like freezing and impossibility to add further users to the surunner list. With intensive testing in the last days I have had never only one time such a problem. But I remember, that you use a HIPS. There might be the problem, that any action inside the Surun-Dialog might lead to a reaction / blocking by the HIPS. Normally the HIPS would pop up a dialog, but as Surun creates a own desktop, this dialog (on the standard desktop) cannot be shown and would not be reachable (for an interaction). So I would suggest, that you turn of your HIPS at first for testing. If the problems vanishes, you know, that the HIPS has to configured properly.

Another note: In addition to "Start as admin" (as it is known from the earlier versions of Surun already) Surun has now an option (to be found on the general page) to take over the standard Windows-command "RunAs". If this is enabled you get the typical Surun-designed dialog, so it is possible to mix them both. But although in both cases the program gets started with elevated rights, both commands are in some technical aspects not identical.

Regarding the point, you named an easter egg in your previous post: Do I understand you correctly, that you have started your browser via RunAs and then saved an image from the Internet?

 

EASTER, are you sure that you're using v.1.1.0.4? I'm asking this because 1.1.0.3 was buggy, and I had experienced similar problems with that version. It was replaced by Kay with the new version within some hours.

Have you tried Cosmo's recommendations in post #190?

 

I'll redownload it and reinstall again as per suggestions.

I have noticed some occasional interference with my HIPS blocking some actions so i had better try to pinpoint which rules are doing that and make appropriate provision for allowing.

Still in spite of what i encountered, SuRun is doing excellent!

 

Btw, a bit OT, but on my machine I´ve noticed that for some reason, "normal users" have write access to C/Windows+Program Files, how to fix this?

 

Rasheed, since your system seems to be heavily misconfigured I really suggest that you follow the instructions in my post #146 , particularly step 2, in order to restore the default security settings for the file system and the registry. (I wouldn't restore them manually via the security tab in explorer as above suggested solution is more comprehensive.)

 

It was just yesterday, when I got a phone call and the person on the other end told me some observation, which looked little bit similar then those of Rasheed. So I told this person to check, if his account was still a limited one (as it should be) or not; and this was it: The account was an admin account. (Why, since what time? Now one knows.)

So I would advise here to also check, if the "normal user" is actually still a normal user. Most simple way: If you go to the user account settings in system panel and you are able to change other than your own accounts or create a new one, you are no limited user any more. - Important: Do not(!) change this until you know exactly, how many accounts with admin privileges are in the system. It should be exactly 2: The predefined one called "Administrator" (normally hidden and hopefully untouched) and a second one (normally created directly after installation of the system). Not more but also not less.

 

@ tlu, I need to explain something, on my real system I haven´t even made a limited account yet. But with SRP you can use the "DropMyRights" method to lower app rights. But like I said, apps running as non-admin (on admin account) have more rights than they should have, and I wonder how to fix this.

 

I don't know since I'm not a DMR expert as I tried it several years ago. Perhaps somebody else can answer your question. But if it's really true what you're saying then DMR is considerably worse than I thought.

 

Why do you say that? I think you´re misunderstanding, DMR is supposed to make a process run exactly as it would run under LUA, it´s just that on my machine, non-admins have more rights than they should, and I haven´t got a clue how to fix this, well except for the instructions you gave me. The thing what I don´t get is that even when you haven´t even created a LUA, you still get to see various "Normal User" accounts, see pic.

http://img176.imageshack.us/my.php?image=screenshot220lx9.png

 

In a few weeks I will be installing Windows Xp, office 2007, paperport and a few other office type programs i.e no games, no security.
How/when would users recommend installing SuRun ? Is it best to install Xp inf drivers etc and then SuRun or better to install all programs as admin and then install SuRun ?

 

Taken the screenshot I see the following:

there is one(!) "normal user" in the last three rows, but there are 3 rows for them, because the are distinct rights for the objects and tasks. So far this is out of the box for XP

The astonishing point is the fact, that there are 2 rows for the admins, and that is not out of the box. Besides the standard-setting of full access for admins there is another one, which does not really make sense in this combination (except, if this special right would be a disallow-setting, but that would be problematic).

Note: "Users" is not a specific user, but a group of users; this group is there by default and is not dependent from creating an account. You could(!!!) remove this entry, but I would not consider this as a good idea. In fact, the shown rights mean, that a user may create subfolders and may create files inside subfolders (but not in the root of the drive), but he cannot(!) change or delete any file, except those, he has created himself (meaning he is the owner).

(I suppose, that this is from a virtual machine, otherwise I would be surprised, that the machine is called "Virtual".)

 

To understand this issue, you must understand, that any file and folder on your machine has an OWNER, by XP-default this is the user (regardless, if he is an admin or a limited user), who has created the object. The owner has nearly always all privileges for those objects as an admin has - the difference is, that an admin has those privileges also for objects, that have been created by someone else. The consequence is, that if a "Normal user" does install software or drivers by elevating his rights (doing the elevation with Surun or with MakeMeAdmin by Aaron Margosis), would make him the owner of those objects and he would be able to anything he wants with this objects without having elevated rights anymore. More troublesome: Also an attacker (physically on the machine or an digital one) would be able to do so from this account.

To solve the named problem, Kay has added an option in Surun, which is normally activated; this option changes the system's policy, so that no longer the creator of system objects is the owner, but the group of admins. The consequence: From the shell and with apps, that are not started via Surun "Start as Admin" those objects can only get read or executed (Mostly that is the reason, they are there), but not altered or deleted. So in the consequence it is possible to install programs as a Surunner.

(Will be continued, because I have not the time at the moment to do so.)

 

Okay. I agree with Cosmo's answer, and I still think you should apply what I suggested to you in order to restore the default permissions. Have you tried that already?

 

(Continuing my previous post

Regardless of my description I would use the standard procedures for installing a system as long as possible. This makes it easier to tell about the system, if there should at anytime the need to seek for assistance with any problem. That means:

If you are asked at the end of the XP-installation process to enter up to 5 account names, do enter only one. This will be your admin account. Now you create a new limited account (LUA), this is your working account for daily use. If you make your settings in Windows and the programs, that you install, do it for the LUA. The question, at which time to install Surun is not the point, if you do not make the admin account to a Surunner. Instead make the LUA a Surunner. In this case the installation of Surun itself does not change the system (except installing the software, as any installation process does). As long, as installations are done via admin account, the problem about ownership (described in my previous post) does not exist; so you do not have to deal with it and have not to tell a supporter , in case you need help. I would not install Surun (as all not essentially needed software) before having installed all needed drivers properly. In fact, I would not even do this, before making the pc Internet-ready and going to Windows-Update to install all important updates to have the system secured. BTW, at now it will be nearly 100 updates; if you have the time, wait until SP3 is finally (!) released (not RC = not suitable for production system), so you will have those updates at once.

 

Cosmo, I don't think this is correct as the ownership itself doesn't affect the actual permissions - see my discussion with Cerxes in posts #147 ff. See also for details here. E.g., if the admin has the ownership for all folders/files in c:\Documents and Settings\<user>\... , the respective <user> still has full control for them.

@Long View: If you do a fresh installation of Windows I would really recommend to create a new limited account before installing any software. The next step would be to install SuRun (with the default option that Administrators become the default owners enabled, of course!). From now on you can install any software with SuRun from your limited account. The only exception would be HIPS or Personal Firewalls which should be installed in your admin account as in many cases you have to reboot after the installation of these programs, and after the reboot a configuration window automatically pops up for which admin rights are needed. If you did the installation in your limited account with SuRun you might run into problems - not necessarily, but in order to avoid possible problems I'd use above approach.

 

Hi tlu, do we have a misunderstanding here?
The CREATOR/OWNER (as a special kind of user-group) has mostly ever full access to the objects, that he created. Taking the ownership away from the Surunner (with the repeatedly said option) gives this account the rights and limitations, that normally apply to a LUA - as long as the Surunner does not access those objects with a program, that he started "as admin", of course). This is true for all objects, that are created after this option is set. But as the LUA would (normally) not be able to install anything befor installing Surun and as this option should be / stay checked with the installation of Surun, this is not a real problem. The case, that you discussed with Cerxes, that there might be older objects with the ownership of an LUA does not apply here.

Together with the 2nd part of my post I expressed my opinion, that in the ideal situation of a fresh new installation of the OS the admin account, that gets created at first should stay what it is. So if this account or the groups of administrators has the ownership is of no parcatical consequence; such ownerships need no change. Perhaps the misunderstanding is here?

The case, that an object gets created inside a user profile, where the respective user has full access regardless of ownership, is a special one, because the profile folder / branch has a not inherited right for full access for the respective user (but this right gets inherited to the objects below). <This is the reason, why the whole concept of distinct rights gets meaningless, if installer-free (mostly portable) software gets installed here (as some "clever" people tell again and again).> So, if the respective user has full access to the objects in his profile this does not say anything about the access in other places.

 

Cosmo, all I wanted to say is: Create, e.g, a directory c:\test by starting the explorer with SuRun (=> owner = admin) and give full control to users (or at least change/write permission). Now start explorer with limited rights and create a subfolder or a file in c:\test - in both cases the user has ownership. The user is able to create or delete any subfolders or files - and he is even able to delete c:\test in spite of the admin ownership. This example illustrates again the quotation in post #152: "The significance of ownership is that the owner of a file or folder always has the ability to assign permissions for that object. The owner can decide what permissions should be applied to the object, controlling others' access to the file or folder." Thus, the actual permissions are the crucial factor and not the ownership.

Well, it's probably only a matter of words. What you wrote is actually identical to the last paragraph of post #152 or in #215. In this case any manual changes regarding ownership are unnecessary.

Agreed, although software installed in that folder cannot be executed if a SRP as recommended is applied.

 

tlu, I think I start do understand what you mean. (At the time of my previous post I was not sure about that.) If I understand you now correctly, you think about the rights in folders. One part of what you describe - the user being able to create subfolders and files: There is no need to give him any special permission. This is quite normal and IMHO expected by design. And also it is self-evident, that he (as a creator of an object with limited rights) has the ownership and so far full access. Excepted from this access are some special folders, namely Windows and program files (the inheritance is broken in those folders), also the root of all drives, the admin can add some more folders to this behavior (by changing the advanced security settings). As long as the admin does not do this, there does not exist a limitation to create objects on any place; it doesn't matter, who is the owner of the parent-folder.

Regarding the last thing you mentioned: The user can delete the test-folder (with having only limited rights): Of course, if you give the user manually the right to change, he can. But if you do not (Most Windows-users do not know anything about that, user of XP Home can normally not even see those settings.) I see something else, if the ownership-option in Surun is set (as we both recommended). If I create the test-folder with elevated rights I cannot delete this folder from the same account with limited rights. (The same would be true for file-objects.) And this easily explainable, if you uncheck the ownership-option in Surun and repeat the procedure. If you take a look now into the advanced security settings you will find, that in this case there is a new entry for the name of the Surunner-account, because now this account is the Creator/Owner; because of this this account has full access. Even changing the ownership now afterwards to the group of admins does not change the situation, that this account can also delete the test-folder with only limited rights. But if the ownership-option is set (naturally before creating the folder), you will not find this Surunner-account entry in the advanced security settings, and because of this the Surunner - as long as he does not start a program with elevated rights - has only read and execute access. So, I cannot see (or I am still not able to see), how far there is something wrong in the quoted paragraph from yesterday by me; o.k. in the questioned quote I forget to add: create objects in subfolders.

 

If you've ever modified permissions using the Windows' built-in Security tab, chances are you've seen permissions given to CREATOR OWNER before. Those permissions are inherited by whoever has ownership over a particular object (file, folder, registry key, etc). By default, CREATOR OWNER has full control over many areas, including the entire Program Files folder. Therefore, if your user account has ownership of a file or folder in \Program Files\, there's a good change you have full control over it.

Normally this wouldn't be a problem because a normal user doesn't have write permissions to Program Files. All software would have to be installed in a separate Admin account, and that account would have ownership over the files that are installed. However, when you use MakeMeAdmin or SuRun to get temporary Admin rights and install software, your user account gets ownership of any new files and folders. This is a problem because your normal user account gets full control over those new files even though you're not an Administrator.

The reasoning behind making the Administrators group the default owner of new objects is to make sure your non-admin account isn't unexpectedly given full control over anything that a non-admin account wouldn't normally have such control over.

The important thing to understand is that changing the owner of a file or folder DOES NOT override any permissions you would normally have. Ownership generally only applies for permissions given to CREATOR OWNER, not permissions given to the Users group or to your specific account. For example, your user account has full control over its \Documents and Settings\<user>\ folder, so you still have full read and write permissions in your My Documents folder regardless of who has ownership of the files.

I don't see any reason why anyone wouldn't want to make the Administrators group the default owner since there's nothing to loose. In the case that you need write permission somewhere that a non-admin doesn't normally allow, you can just change the permissions using the built-in security tab (XP Pro/MCE) or Fajo XP (XP Home).

 

Actually, you can get around that if you throw the DropMyRights approach into the mix. I personally prefer StripMyRights since it's slightly more flexible, but either will work.

If you use SuRun to start DMR with admin rights, DMR will be able to start the target program without being constrained by the SPR. As a plus, the target program won't have admin rights and will still have to abide by the SPR when launching other executables. It's an excellent way of opting-out of SPR to launch a specific program without losing any of the SPR's benefits.

It's fairly simple do to from a non-admin command line. Assuming you have DropMyRights (or StripMyRights) in the windows folder, it would work something like this....

1. Open command prompt.
2. type "surun dropmyrights " (note the space at the end)
3. drag and drop the file from explorer to the command prompt window
4. press enter and then confirm the SuRun prompt
5. Success! The app will launch.

Interestingly enough, you can actually replace dropmyrights with a second SuRun (i.e. "surun surun ") to bypass SPR and run the app as admin. SuRun is smart enough to not prompt you if it's started with admin rights, so you only get prompted once.

It should only take a few registry entries to add this to the right-click context menu. I haven't tried that yet (I will in a minute though ), but if I can get that working it should make working with SPR in place easier, especially when launching installers.

 

Theres still a "experimental" setting in SuRun i'm sure they'll eventually sort out as well as annoying screen freeze up every single solidary time i access the Control Panel, Open Up SuRun Settings, make my changes then press APPLY, then thats as far as i get, not even able to press SAVE, it locks up the screen and the pointer goes into an infinite loop with the dark screen background or not.

Definitely a work still in progress, but on the plus side it's rather convenient otherwise and try using SuRun with a HIPS like i do, man you got the system barbed-wired for sure for any apps that attempt a forced elevated rights.

Nice App, just hope they iron out that screen freeze, that thing is annoying and costs a manual reset every time, forget about Log Off too, screen is frozen tight.

 

If you do the test described in the last paragraph of my previous post you will see the reason.

(BTW: If software would get installed in a "Admin account", it would be unreachable for all non-Admin accounts, as they would even not be able to read those folders and files.)


@EASTER: I have the feeling, that you are moving in circles. Such a freeze has at my knowledge never been reported and as long as you do have your HIPS activated, you will stay in your trap. Although this is IMO now bug, Kay is trying to find a way, to make some cooperation between Surun and HIPS inside an Amin-account possible. But don't expect it very soon, there is no deadline for this.

 

Well how about this. I shut down my HIPS and theres still no change, This SuRun is a nice app and all but it still EXPERIMENTAL, i would not recommend any program that even adds a "experimental" setting in it. That freeze screen is a reality, i run a simple XP pro SP2 with minimal securit apps, so this is not normal by any stretch.

Anyway it was nice to toy with but cost me a lost of wasted time, it is a VERY UNFINISHED PRODUCT!

 

BTW, SuRun 1.1.0.5 is out.

@Cosmo 203:

I think you may have misunderstood me; I'm agreeing with you (I think…). I'm saying that the default owner of objects should be the Administrators group. It prevents the problem from happening in the first place.

However, changing the default owner doesn't correct any ACL pollution (for lack of a better term) that has already happened. It only prevents it from happening in the future.

IMO, the easiest way to prevent previously set ownership from being a problem is to create a new user account. As long as the default owner is set to the Administrators group before creating the account, any objects created using the account will belong to the Administrators group and not the actual user account. Although the permissions for existing files and folders will still be "polluted", most, if not all, of those permissions will not apply to the newly made account.

That was a poor choice of wording on my part. I was referring to using an Admin account to install software to the Program Files directory where the Users group has read access, not the Admin account's user directory.


@EASTER

Actually, I've had something a lot like that pop up since I updated to 1.1.0.5.

The blurred effect when switching to the secure desktop hangs and you get "stuck" in the secure desktop. It only seems to happen if you have the blurred background option on. Pressing Alt+F4 when it happens seems to be a workaround. You can also press Ctrl+Alt+Del to bring up the Windows Security and restart from there if you're using the classic login prompt.

I am using ThreatFire, but it has never caused conflicts with SuRun in the past and still happens with it disabled, so as far as I'm concerned this is a bug in SuRun. I'll be reporting this to Kay via his forum as soon as I have a chance to look in to the problem a little more.

 

You just would and have to announce another new version is out, like i said i like it, but it's still a work in progress and has some serious bugs to overcome yet.

I might D/L it and store it for another drive, but something tells me they are several versions away yet from getting this app stable enough to depend on in a production environment.