How to test programs sandboxed with LUA + SRP enabled

Discussion in 'other anti-malware software' started by ssj100, Oct 23, 2009.

Thread Status:
Not open for further replies.
  1. ssj100

    ssj100 Guest

    Awgust asked the question of how to test programs in Sandboxie while working in LUA (+ SRP). The issue here is that generally nothing is able to be installed correctly in LUA. Furthermore, SRP will block any executable from even running in the first place. So how to get around this? One very simple way is as described (you need to have SuRun installed):

    With Windows XP:
    1. Go to Start - Programs - Sandboxie -
    2. Right click on "Run any program sandboxed"
    3. Left click on "Start as administrator"
    4. A pop-up of some sort should come up asking you if you really want to start the program with administrator rights. Click OK.
    5. Now if you have more than 1 sandbox, another window will appear asking you to select the sandbox you wish to use to run the program. Select your "testing" sandbox.
    6. Browse to the program you want to test, and run it. You will thus be running the program as an admin but in a sandbox!

    Note that this will work as long as you have applied SRP for everyone except administrators.

    Just ask if you have any further questions Awgust.
     
  2. Awgust

    Awgust Registered Member

    Joined:
    Oct 19, 2009
    Posts:
    21
    Firstly, thank you for taking your precious time to help me with this problem! :D

    I have followed your steps and this is what happened:
    1. Successful, located "Run any program sandboxed"
    2. Successful, right clicked
    3. Successful, located "Start as administrator" and clicked on it
    4. Successful, the SuRun pop up did appeared and I clicked OK
    5. I have only the defaultbox (why do I need more than one? o_O ), so this step is skipped
    6. I browsed to the program which is located on my desktop and clicked "OK", but a SRP pop up tells me that it could not invoke the program and the system error code 1260 states that it is prevented by SRP.

    I tried to place the installer.exe in my program files and repeated the steps, which then worked. So is it necessary to have the programs I want to install to be in program files for it to be run admin sandboxed? The SRP I used is exactly like the one taught on http://www.mechbgon.com/srp/ that is found in this forum (I think it's exactly the same, but I don't understand some of the english in that site, so I'm not fully sure, sorry :( )

    Thanks again! Have a nice day! :)
     
  3. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    Users rights (this applies to LUA) - read and execute by default in windows and program files directories. create/modify/delete/read/write/execute in %user space% by default.

    SRP as you imply you are using, typically denies execution of programs in %user space%. Normally the .lnk is removed from the file types so that you can have a shortcut to an executable and it is not denied by SRP.

    When you try to execute in %user space% SRP denies it. Moving the setup.exe into program files works because of the default SRP rule which says to allow all exections in program files, and because the User group has rights to execute also.

    Clear as mud?

    Sul.
     
  4. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    I believe the step needed here that SSJ is eluding to, is that as a User, you have used SRP to restrict your %user space% from execution (default deny). In order to run setup.exe from %user space%, you must first use something like SuRun to "elevate" setup.exe to Admin instead of user. This way, since SRP in this case is probably not effecting Admins (only Users), the program starts without the SRP restrictions. So while a User, you elevate to Admin to sort of 'bypass' the restrictions you have imposed on all Users with SRP.

    Sul.
     
  5. Awgust

    Awgust Registered Member

    Joined:
    Oct 19, 2009
    Posts:
    21
    No :(

    I think I understand from your kind replies the reason behind why I cannot run the installer... but can you please do a step by step walkthrough like the one ssj100 provided? I really cannot see or understand any solutions you may have provided... sorry for my bad english :(

    In any case, thank you two very much :D
     
  6. bman412

    bman412 Registered Member

    Joined:
    Mar 4, 2008
    Posts:
    261
    1. Run an admin instance of windows explorer or whichever file manager you use via SuRun then browse to the setup file or folder you wish to sandbox.

    2. Invoke the file/folder to run sandboxed by either Right click > Run Sandboxed or Right Click > SendTo Sandboxie.
     
  7. Awgust

    Awgust Registered Member

    Joined:
    Oct 19, 2009
    Posts:
    21
    Hi, and thanks for your help, but sadly even after following your step, it didn't work, and I was shown the same error 1260. :doubt:

    Hi, I've checked again, and yes it is the same one as the picture you've provided. I followed and double checked everything according to the http://www.mechbgon.com/srp/ website, everything seems right.... so this problem only occurs to me? I messed up somewhere again? Why does this always happen to me :'(
     
  8. wat0114

    wat0114 Guest

    I wonder if you need to create a path rule in SRP for some of your programs? Is that program actually on your desktop or is it just a shortcut to it? Also, are your programs installed under C:\ Program Files or a different drive letter than C?

    *Edit*

    you know, I also get that exact same error only if I don't right-click Run any program sandboxed -> left click start as administrator. The screenshots might seem overkill, but just in case you're missing one step along the way...you should hopefully be seeing what's in the screenshots.
     

    Attached Files:

    Last edited by a moderator: Oct 25, 2009
  9. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    Check your setup. Assume you are a User (LUA), not an admin.

    1. The secondary logon service must be running to start something AS an admin.
    2. SRP should have two default rules, allow any execution in %windir% and %programfiles%.

    Now, this should be done before you move on. Implementing a default deny scenario as mechbogon describes is as follows.

    1. Enable SRP for All Users EXCEPT Admins.
    2. Remove .lnk from the executable types monitored.
    3. Set the default rule to be deny execution.

    Now you have created default deny EXCEPT in the two directories %windir% and %programfiles%. Starting ANY executable outside those directories will fail because of the SRP rules. You may use shortcuts (.lnk files) to start items in %windir% and %programfiles%. If you had not removed the .lnk file type from SRP, it would treat those as executables as well.

    Now you wish to start an executable from LUA, but you are locked down due to SRP. You must use some form of RunAs to ELEVATE the executable to Admin status. Remember that Admin group is not restricted by SRP, only the Users group. So you find a setup.exe that is for example on your desktop. If you run it, SRP denies it. But if you were to right click and use the RunAs, and give an admins username and password, the Secondary Logon service is engaged and the program in question is started with the Admins rights. Now the setup.exe will perform fine.

    You can also use SuRun or other variants to Run things As an admin or other group/user.

    Ok, now enter Sandboxie.

    Understand, that in windows, MS has declared what directories and files are off-limits to Users. Typically speaking, Users have access to Read and Execute in %windir% and %programfiles%. This way, you can still use/start all the programs you need to, but cannot modify these areas, deemed to be 'system critical'. This is good, because as a User, you are not allowed to 'mess' with areas that could pose problems.

    A User can create/modify/delete/read/execute anything in thier %user profile% directories. That is, you know, my documents and desktop, etc. Users may also create new folders. For example, you create a folder like this: c:\my folder. Now you, the User, a member of the Users group, have full rights to that directory. You can do whatever you like.

    So now you see, that when you are being a User, you cannot touch certain areas, but can others. However, when you apply SRP default deny, you have lowered yourself from Users rights to less than Users. Not a lot, it only applies to executables.

    Examine Sandboxie, and note that it creates a directory called c:\Sandbox. Within this directory are your sandboxes. Windows has imposed no security restrictions on this directory, because it is not a standard windows directory. Thus, as a User, you have full rights to it.

    Now, imaging that you are logged in as a User, and you wish to execute the file 'setup.exe' that is on your desktop. This setup.exe file is going to install a ping pong program into %programfiles%. Because you are only a User, you cannot create or modify in %programfiles%, only read and execute. So, the installation of this ping pong game fails.

    But, if you start that 'setup.exe' in a sandbox, it will work. Why? The reason is that the program is really installing to c:\sandbox\default sandbox\drive\program files\ping pong game. It is not REALLY in the REAL %programfiles% directory, so it is not restricted.

    But, take it a step more. If you use the option in Sandboxie, to "Drop Rights", then Sandboxie will treat what is started within it AS IF the user were only a member of the Users group. Meaning, it sort of re-creates the effects of real world Users within the sandbox, thus denying the 'setup.exe' just like would happen outside of sandboxie.

    I think I have this correct, running on little sleep tonight. Someone feel free to correct me if I have botched this at all.

    Sul.
     
  10. Awgust

    Awgust Registered Member

    Joined:
    Oct 19, 2009
    Posts:
    21
    The program is on my desktop, and my programs are all installed under Program Files. Thanks for your image attachment, they always make things so much easier! :D

    Here are my screenshot images of my problem:
    1. I located the "Run any program sandboxed" in my start menu and right clicked on it, going to click on the "Start as administrator".
    002.JPG

    2. This window showed up after the click. I click on "Browse..." next.
    003.JPG

    3. I browsed to my desktop and then clicked on the installer I plan on installing in the sandbox. Going to click on "Open" next.
    004.JPG

    4. This warning window showed up, so I'm going to click "Run" because that's what I want.
    005.JPG

    5. This error window showed up next, preventing me from installing the program. The SRP 1260 error.
    006.JPG
     
  11. Awgust

    Awgust Registered Member

    Joined:
    Oct 19, 2009
    Posts:
    21
    Firstly, thank you for teaching me all those technical stuff! :D

    I don't get the part I quoted from your post though. What do you mean by option in Sandboxie? The configuration? But it's in notepad and it's full of texts like "SbieCtrl_ColWidthProcTitle=310" which I cannot understand. :doubt:
     
  12. ParadigmShift

    ParadigmShift Registered Member

    Joined:
    Aug 7, 2008
    Posts:
    203
    3. Set the default rule to be deny execution.

    Are you sure a newbie is going to understand how to implement #3?
     
  13. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    No, it is not enough explanation, but I am assuming he is using Mechbogon instructions, so I am just recapping what has already been done there. lol, why rewrite what is an already superb instruction of his.

    Sul.
     
  14. Awgust

    Awgust Registered Member

    Joined:
    Oct 19, 2009
    Posts:
    21
    Thanks! I've finally managed to get the installation within sandbox working by disabling the "Drop Rights" in the Sandboxie options. The second method method you taught worked too! Big big thanks to everyone who helped, and to this wonderful forum! :argh:

    Huh? I don't get what are you asking, but I understand how to implement #3. My english might be bad, but at least I can still follow step by step instruction (I think :ouch: )... although...

    ...although I have no idea what you're trying to say. Sounds like riddles. Sorry for my bad english :(
     
Loading...
Thread Status:
Not open for further replies.