Opening the "box" to named executable files

[RonC]

When opening a path or registry key to writes from a named executable file, will any other processes started by, and running under, the same-named executable also enjoy the same privileges? I want to double-check this before making a wrong guess and discovering some data I wanted to save was accidentally being "dumped."

If anyone saw this being already answered, please point me in the right direction. Something to this effect was "buried" at the end of a long thread elsewhere on the board, and now I can't locate the post, let alone whether or not the question was ever resolved.

• To avoid confusion, to clarify the question (the primary assertion is incorrect!) and get the best explanation of the basis for selecting the executable in Open*Path statements, go directly to Tzuk's post at the end of this thread.

[SBIE User]

RonC,

As I believe you understand, when a sandboxed program calls another program, that other program is also sandboxed. However, the rights of the parent program are not granted to the spawned program.

So, let me offer an example. If you have opened a file path for a browser which is allowed by an OpenFilePath entry to access a specified downloads folder on your hard drive and the browser then opens Adobe Reader to read a pdf file, I don't think Adobe will be allowed to save the pdf file to the downloads folder outside the sandbox. Adobe Reader will save it to the named folder, but it will be the virtual folder in the sandbox rather than the actual folder.

Now if you just save the pdf file directly using the browser and not going through Adobe Reader, the file would be allowed direct access to the downloads directory outside the sandbox because the action would be related to the browser's privileges and not Adobe's privileges.

I hope that makes sense.

SBIE (Happy) User

[RonC]

SBIE,
Yes, and thanks for the explanation. Thinking about the example you gave, and what I have observed with some software I run, what do you think of these two statements as general rules:

In the first case, if an executable calls another in such a way that the second program becomes visible on Task Manager/Process Explorer, then separate rules in Sandboxie.ini are needed to control the second program's behavior.

It is the second case is what initially confused me, and still does, so see if you agree with this: if a one executable calls another in a way that it runs without appearing on the above two process/service monitoring utilities, then its behavior will be determined by the rules applied to the program that does appear.

In the case of my PDA synchronizing program, with 4-5 executables in the directory, I saw nothing new appear in Process Explorer as I clicked-on menu selections for backing up, exporting or importing. Perhaps I am safe in limiting the sandboxie.ini rules to the main executable?

I wonder if I'm the only one who has strange programs like this? Or am I not looking closely enough? Actually, I never even thought about these things until I had to, in order to configure the Sandboxie .ini file.

For a second example, when MS Internet Explorer runs under StarOffice (StarOffice gives me no other choice ), I see no new processes appearing. So I suppose the rules applying to the office suite would automatically apply to the browser?

If Tzuk agrees with this, the second case in particular, perhaps it could go into the FAQ section, for others who have the same types of programs. I'm not sure if I'm using correct terminology in calling "processes" these programs that run this way, as a process should appear in the monitor utility's listing (I think).

[SBIE User]

RonC,

I think using the programs listed in SandboxIE's list of active processes is probably a good way to determine which programs require OpenFilePath and OpenKeyPath permissions.

This is above my pay grade, however, and I would feel more comfortable hearing from Tzuk -- although I would also put a lot of trust in mizzmona's suggestions if she offers any.

SBIE (Happy) User

[RonC]

I think using the programs listed in SandboxIE's list of active processes is probably a good way to determine which programs require OpenFilePath and OpenKeyPath permissions.
SBIE (Happy) User

SBIE, I think this is the answer, unless Tzuk says otherwise. If he agrees, then your idea is what should go into the FAQ, and not what I wrote.

If one sandboxed program calls another, the user should just look at Sandboxie Control, and not worry about what other executable files may be in that program's directory. It may be a good idea to run through the other menu selections and make sure nothing else "pops-up." Then, only make .ini-file rules for whatever processes may appear.

For the benefit of other users, Tzuk mentioned that there are some MSIE shells that act as does StarOffice (likely there is no one else using StarOffice in this way). It can get complicated if one tries to guess, or look at the many processes in Task Manager, as I did.

As an example, MSIE running under StarOffice runs in the StarOffice Task Bar, but does not show as a separate process. This would not respond to rules for iexplore.exe (I would imagine). AcroRead32.exe also runs in the StarOffice Task Bar (only) when called from MSIE, but does show as a separate process in Sandboxie Control. This would require to .ini-file rules for acrord32.exe.

Other cases are more obvious, when the programs show (only) in the Windows Task Bar, and then the only question is whether they call other executables that then appear in Sandboxie Control. Now that I know what to look for, I have nothing that performs in this way (I've only looked for this with one program, my PDA synchronizer).

Does this sound OK? Any comments are invited.

[tzuk]

I find myself a little lost by the end of this thread. I'll try to make this clearer but I think everybody got this by now?

Settings specific to a process, like the Open*Path settings, are associated with a sandboxed process when it is created. They are not inherited or otherwise passed from one process to another. You should set these rules up according to what you need and what you see in the Sandboxie Control process list.

A process is one row on the Task Manager, and has one process ID (which doesn't appear by default, as far as I remember, you have to ask Task Manager to show it). It also starts with one executable, that's an .exe file, and typically does not get other .exe files inserted into it. It is, however, very common that .dll files are inserted into and removed from a process during its run.

When Internet Explorer seems to run inside some other process, it isn't iexplore.exe that joins the parent process. Rather, the MSHTML rendering engine (mshtml.dll and friends, from \Windows\System32) joins the parent process. Iexplore.exe is itself a shell that embeds MSHTML, much like StarOffice and other IE-based browsers embed MSHTML.

I hope that helps.

[RonC]

Please see the Detour warning message edited into my first post, telling anyone who comes across this thread to come directly to Tzuk's post, above.
RonC