SuRun problems -- the solutions

Hopefully this thread becomes a collection of small problems that peeps run into when using a LUA and SuRun. For me, the forum for SuRun is frequently down, so I post here instead.

One of my common problems with SuRun and LUA is that of a directory or file needing Admin privelages.

PROBLEM:

I use RivaTuner to underclock my 8800gtx when in 2D mode, to keep heat down. 3D mode is default. Since switching a gaming machine over to LUA/SuRun, on bootup an error is reported that the driver RivaTuner32.sys, which lives in the RivaTuner directory in Program Files, needs admin privelages.

ATTEMPTED FIXES:

In the GPO, I set the RivaTuner directory for full read/write. I also set the file in question, RivaTuner32.sys to full read/write. For the LUA. This fails, so I now try to include RivaTuner32.sys into SuRun as always allow/always elevate. This fails too.

SOLUTION:

RivaTuner requires admin rights. This is documented in RivaTuners release notes. The author states that there is an easter egg that will shut this off, and also eluded to some power user settings that might also work. I was unable to find any answer. RivaTuner gives the option of starting via registry using the Run key, or via the startup folder. I tried various methods, and finally decided on the easiest. By placing the shortcut to RivaTuner.exe in the startup folder, then modifying the shortcut with 'c:\windows\surun.exe' to the front of the target string, this solved the problem. SuRun asks for the permissions to do this, and I checked the box to remember the answer. Now RivaTuner starts with elevated privelages. I like the registry to run things, but in this case, I found using SuRun in the same manner in the regsitry Run key to cause some issues.

 

PROBLEM:

The utility Unlocker is used to unlock files that you wish to delete/rename/etc, but get the error "This file is in use". In my case it is integrated into the OS install. Running this application in a LUA/SuRun environment gives a debug error of some kind from the application.

ATTEMPTED FIXES:

Adding the program as an exception to SuRun, elevating it's rights. There is a driver involved in this, a legacy driver enumed in the regsitry in an area that is normally not allowed to touch. I tried to find the resources the driver uses, but this so far has proved fruitless. This problem will be a tricky one, yet also I can see this happening from time to time in a LUA environment. Unfortunately, SuRun so far has no way to handle this. I will attempt next to modify containers/objects and registry keys in the GPO.

SOLUTION:

awaiting

 

I'd also like a way to be able to re-arrange, delete, and/or sort my start menu and shortcuts from within my limited account.

I install new programs every so often which sometimes sticks shortcuts in the
"All users" folder and I end up not being able to sort the folder or delete them without logging into my admin account first.

 

Hmm. I think I am going to give up on running in a LUA environment. For me, tweaking and doing things that truly an admin does, this is turning into an exercise in futility.

Consider, something so simple as the app Unlocker, which is a very useful tool, needs debug privileges. I can use a command line tool to grand the user or group the correct rights, but this essentially allows kernel mode tampering. As Unlocker is doing just this for legitimate reasons, there is no way I have found to get the legacy driver for Unlocker to be 'ran' as an admin via SuRun.

The more I use it, the more I begin to see that for a standard user, this would be fine. I would at the minimum need to be a power user, which has inherited vulnerabilities itself.

So, rather than waste any more time on trying to make my personal account a LUA/SRP/SuRun uber fighting machine, I will go back to finding a happy medium of an AV/Firewall/some other security app. Using common sense and Sandboxie more.

It is a pity, as LUA does lock down very well, too well it seems for what I do.

Sully.

 

Thank you for mentioning this, Sully. I had thought about using LUA+SuRun, but potential issues like this (I use Unlocker) convinced me not to. I think I'll hold off until I switch to Vista or Windows 7.

 

Yes, to be using tools like this and be shut out in LUA is not nice. I am *again* looking for a way to 'lock' down critical areas with minimal user intervention. That method of creating a 'Basic User' might hold promise.

I already have an easy way to manipulate the GPO (actual local secpol on non domain) with some .ini files. I can set basically either BU or BA (user or admin) rights to any container/folder/regkey pretty quickly. This was made to be used with SuRun/LUA. But now I am rethinking.

If the 'Basic User' is the group 'User', and applying for instance an SRP rule to have iexplore.exe start as 'Basic User', this is good for that process. Very simple and easy 'nasties' can be halted because that process is currently 'owned' by the User, so rights thereof apply. Now I imagine that since I am still the admin, that I can apply a greater level of lockdown to the User. Already the User has only write access to certain areas of the %profile%, and not any to system or program related areas. This is perhaps adequate, but considering the possibility of an 'escapee' that can write to for example the HKCU autorun reg keys, this may be not good. So maybe I can 'lockout' some still available reg keys that the User has write access to, thus stopping the somewhat unlikely event.

Making the User even more restricted should only apply to a non-existent user, namely not the admin. So to start demoted rights to a process may be a good thing.

Likely I will just put ThreatFire back on, and then follow up on some of Kees1958 excellent ideas on how to monitor critical areas. I do not worry about any issues really, but to have a quiet 'built in' protection of TF, and then to add on some other reg keys to monitor, and possible some file extentions might be also a quiet yet effective approach.

To also state that demoting iexplore.exe (as an example) to a 'Basic User', and have further lockdown of certain %profile% or registry areas for the User group, and then couple this to (and I don't know yet what ramifications will develop) using Sandboxie forcing process iexplore into sandbox, yeilds better results? Testing to find out this week.

Your link to PsExec, is also of interesting note. Now I use Sandboxie, but my 'browser' box is not forcing all browser processes into the box. It is locked down in respect to only allowing browser processes access to network though. So I have a shortcut for Kmeleon as both raw and pushed into sandbox. This way I still have a browser that is capable of running in both worlds. I will be looking to how PsExec also can realate to this type of scenario. Perhaps demoting iexplore.exe with PsExec is a better solution. Then again, the beauty of using the demoted SRP is that no matter what thread may start the iexplore.exe, it will be then running demoted. I am wondering now if PsExec can promote the iexplore.exe to admin when needed, perhaps overriding the token string that SRP will provide to iexplore.exe. It would be very handy indeed to find a way in SRP to normally demote by default the .exe, and never giving it a second thought. Yet still have some flexibility to IF really wanted, and without using secpol or gpedit, running the .exe as admin.

Too many questions now for this.

Sul.

 

Perhaps this approach would work if you want flexibility in SRP policy for a given program:
1. Make a copy of the .exe that starts the given program
2. Make a SRP 'Basic User' path rule involving the original exe only.
3. Make a different shortcut to the copied exe, with '(admin)' appended to the shortcut name. You can launch this shortcut whenever you want admin access to the program.

When you update the given program, you will have to remember to also update the copy.

 

This is a spledid thought. Unfortunately I was not thinkout outside my box enough to realize for myself that the path rule is so stupid. This brings up the issue of why a HIPS type app is both so complicated as well as popular. Rather than a simple path, it may wathc for the process and handle it.

Still, to keep a known .exe into a user policy, is a great thing. The psexec tool I have played with, and it only seems to demote, so using it may be mute with what you just described.

Now I can say that I have done a few tests and have found a rather nice thing. I will make an example. I use SRP to block Iexplore.exe. So then I start Iexplore and try to install flash. This fails of course because the User has no rights to most areas. This is as expected.

Now, if I start Iexplore as a User via SRP, and then, whether forced or not, it starts in Sandboxie, it is intersting. Because SB creates an alternate file system, the User can then install flash with no problems. The sysroot diretory that it may need to write to is now c:\sandbox\sysroot. And of course there are no User restrictions on this directory, not in a default template anyway.

So, I like this. To give internet facing apps a demotion to User. And then to use SB to not only contain, but also rid one of the issues that arise when you are only a User, this is truly a treat.

I will play with your idea some. But I can say that although SuRun is a keen tool, and LUA is also a good thing, I am not giving up my admin. Hopefully this coupled with Avira and TF can provide the level of protection that one can hope for without over-complication.

Sul.