Hi
I have some more problems to report:

1. when I open cmd.exe in sandbox it is started in ...\Sandbox\???\user\current> but this folders are not accessible, the working directory should be set to some valid folder.

2. when I specify OpenFilePath=cmd.exe,* and go to a folder where i have some sandboxed files I see them with the dir command but i can not access them to for example copy them out of the SBox (type test.txt also does not work so obviusly cmd.exe can not read the particular file).

I would like to can access the sandboxed files. and can use copy or move or rename commands to unsandbox them when the app doing it have OpenFilePath open for the needed folders.


Owen

But why do you specify this?

hehe,
of cause to see how well SB work
I was looking for a possibility to unsandbox files with an app that is inside, a further thought would be to make an small app or script that have the rights do do so and that will unsandbox files specifying as parameter by renaming them to something and than back to original what shell result in making SB transfer the file to the real drive. I would putt this small app into my SendTo explorer menu (explorer started of cause inside the SB). Ofcause the app/script would request manual confirmation for such operations.
This thoughts was inspired by the following FR: http://sandboxie.com/phpbb/viewtopic.php?t=1191

Anyway its a bug, if the files are not meant to be accessible when path is open there shouldn't be listed there in the first place, right?

Owen

If you'd like, when you're finished, I'd be happy to host your script/program here.



That's right. If they can't be accessed, then there is no reason to show them. You'll see this fixed in the updated 2.80, maybe as soon as tomorrow.

What about point 1. the not accessibility of sanadbox paths like ...\Sandbox\???\user\current> it would be cool when the path "...\Sandbox\???\" would be handled as openfilepath instad of no access.

This way the recovery app could check if the current file is really sandboxed or not.

The next evolution step would be an shell menu item that is enabled only for sandboxed files and starts the recovery exe instead of using the send to.

btw: I noticed that when I try to run explorer sandboxed while having already an open one SB terminates the sandboxed version, it would be cool if it would start instead and don't see the instance outside.

It would have to be an app in order to can set the openfilepath* only for it and not for some general script parser for security reasons,
There would be also sense full when sboxed programs wouldn't be able to overwrite the exe, there for a setting like ReadOnlyFilePath could be used.

When I'm ready and it works I would be happy to see it hosted here

Owen

I am not sure understand. Yes, if I start a sandboxed cmd.exe, I get the prompt \Sandbox\???\user\current. But what's the problem then? Everything works, whether I have OpenFilePath=cmd.exe,* or not.

Do you still have that three-letter virtualization solution installed? I remember I saw some problems getting 'dir' to work correctly, when I was testing against it, about a month ago, per your request.



I think this means you need a DLL that loads into explorer.exe and implements IContextMenu.



It would be cool, yes, but the problem with explorer.exe is that it wants to own your desktop. So if it actually starts, it will put up a second wallpaper covering everything. That's no good.

I'm sorry but I couldn't understand the next paragraph in your post.

emmm,
ok I havn't tested this enough, dir works indeed, but anyway "cd.." don't
I can't change to uper directory mo mather if open path is * or not.
The problem seems to be in paths below the sandbox root directory and above the directoris inside current, current>cd desktop and than current\desktop>cd.. back works, going more back like ...\defaultbox\user\ does not work. I get "Bad Handle" or "the system couldn't find the specyfyed path"

EDIT: yes I still have the Altiris SVS installed, but it seems that sandboxed apps have only problems reading the root C directory, subpaths work and commands liek "c:\>cd Inetpub" work.
btw. would be nice if thsi could be resolved to to work properly

Explorer will not try to take the desktop if "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell" is set to everything else than "explorer.exe"

I'll try to rewrite the last paragraph of my previous post:
1. it must be an exe not a script as when it would be a script i would have alop openfilepath* for the script parser, in case of an *.cmd it would be cmd.exe and this would be exploitable.
2. when it is an exe there is still a small rist than an program inside the SB overwrites in the sandbox the exe with an own and execute it and gets this way openfilepath*,
2a. I see right now that it would be for the atacker sufficient to create an exe with the name of the recobery app that have the openfilepath*

So there is a way needed to prevent exe's from inside the sandbox to have openfilepath* if thair names match the names of files outside that have the openfilepath*

Owen

Yes, I can confirm. I won't be doing anything about that for the official 2.80, but I can try to fix it for later versions.



You have to talk to them about it. They're not implementing some OS calls correctly.



Sweet! I'll try it . . . if you're right, it could mean the end of SandboxieExplorer even.

As for your concerns about OpenFilePath being abused. Perhaps it makes a difference that EXEs that reside in the sandbox are not able to take advantage of Open*Paths? (They do in the version you have, but I have already noticed and fixed it.)

I have posted the dir c: problem in the SVS board lets wait what they say.
EDIT: While looking across their board i found a beta version 2.1 beta 1.6 that seems to have solved the problem with dir c:

So in the next release exes inside the SB wont be longer able to use Open*Paths, cool

Owen