Page 1 of 2
SB not working with "Altiris Software Virtualization&qu
Posted: Sun Jan 21, 2007 1:13 pm
by OwenBurnett
Hi,
I got a free copy of "Altiris Software Virtualization" and unfortunatly it won't work together with Sandbixie, when I load some "layer" I can't use Sandboxed programy anymore, with a few exceptions all app's seems to have file access problems, for example on C thay see only what is in the SB no read accesss to the real drive, sometimes even the icons for the file open/safe fialog are not loaded.
When I unload all Virtual Software layers Sandboxed apps work again.
Owen
Posted: Sun Jan 21, 2007 6:22 pm
by tzuk
Seems a bit like running two kinds of anti-virus ... SVS does its redirection, Sandboxie does its redirection ... Somewhere along the line you're bound to experience a conflict.
Posted: Mon Jan 22, 2007 4:26 am
by street011
i'm experiencing the same problems, my sandboxie is messedup badly, wont even run with svs uninstalled or disabled...
anyway, i think sandboxie can learn a few things from svs, for example the very functional 'layers' sandboxie can use more then one sandboxes, but it's not so user friendly, disable / enable / reset layer etc
tzuk, maybe you can look at it and see what features can be intergrated into sandboxie...
Posted: Mon Jan 22, 2007 4:38 am
by OwenBurnett
I know that SB and SVS works in a simmilar way, but never the less what it does is completly different.
SVS isn't a sandbox it is a software management solution. And it provides only verry small protection, it allows the software to do everythink except it intercepts all file and registry operations.
Sandboxie could be modifyed to provide a major part of SVS's functionality when the user could specify for particular Sandboxes to not protect the system only virtualise files and registry.
So we would need an sb...ini obtion DontProtect=y that causes SB to dissable all protection except the file & registry
and as street011 wrote this layers thing from SVS would be realy cool.
Owen
Posted: Mon Jan 22, 2007 6:55 pm
by tzuk
I know that SB and SVS works in a simmilar way, but never the less what it does is completly different.
This thread is a review that says otherwise.
Though I must admit, I haven't tried SVS myself.
So we would need an sb...ini obtion DontProtect=y that causes SB to dissable all protection except the file & registry
You can say OpenIpcPath=* and achieve pretty much the same result. But I really don't recommend it. And if you try it, and it breaks something, don't complain.
Posted: Tue Jan 23, 2007 3:59 am
by street011
tzuk;
what exactly is an IPC port? i've tried google, i don't get much info on it, only forums with problems
where would a program gain access, in which way does it compromise security?
sometimes i just want to install an application for testing purpose, not so much for security, but when i'm done testing i don't want to use uninstall because it leaves a lot of junk behind... so sandboxie would be a solution i think.
For example, a new photoshop version or beta version...
it just won't run in sandboxie, starts complaining about no administrative rights and not being able to write configurationfiles, under SVS however everything works, and when done testing i delete the layer.
Posted: Tue Jan 23, 2007 7:56 am
by OwenBurnett
What excepted IPC, Filesystem, registry and loading drivers privileg, is protected by the current version of sandboxie?
This is I think an quite important information.
Owen
Posted: Tue Jan 23, 2007 7:22 pm
by tzuk
street011 wrote:what exactly is an IPC port
Not an IPC port, but IPC objects. Sandboxie treats the following classes of NT objects collectively as IPC objects:
Event
Mutant
Section
Semaphore
Port (renamed "ALPC Port" in Windows Vista)
It doesn't matter which specific class of NT object it is, OpenIpcPath and ClosedIpcPath work the same.
What excepted IPC, Filesystem, registry and loading drivers privileg, is protected by the current version of sandboxie?
What I wrote above.
There is also separation of processes (so sandboxed process can't inject into or terminate processes outside its sandbox), and separation of window objects.
Posted: Wed Jan 24, 2007 12:34 pm
by OwenBurnett
tzuk wrote:
There is also separation of processes (so sandboxed process can't inject into or terminate processes outside its sandbox), and separation of window objects.
And this works under vista without signing the code?
Owen
Posted: Wed Jan 24, 2007 5:34 pm
by tzuk
And this works under vista without signing the code?
Yes, it does. I think only the x64 variant of Windows Vista is blocking unsigned code.
Posted: Thu Jan 25, 2007 9:21 am
by OwenBurnett
I ment the question: do the current SB beta still uses kernel code or would it work on a vista that requirers kernel codes to be signed?
never the leess...
how about the feature requests in this thread?
Owen
Posted: Fri Jan 26, 2007 6:35 pm
by tzuk
do the current SB beta still uses kernel code
Yes, there is still a driver, and it runs in kernel mode. In principle it should not work an OS where drivers must be signed.
how about the feature requests in this thread?
Disabling protection except for files and registry keys? No, it's not that simple. For this to be possible, more and more exceptions would have to be made, and I don't like this idea.
Consider: if you sandbox just files and keys, then the sandbox program can talk to the real Windows COM server. (Which SandboxieRpcss replaces.) Now, you install a program into such a limited sandbox. It installs a new COM component, this involves creating new files and updating the registry. These changes occur in the sandbox.
Next, the installed program tries to use that COM component, but the real Windows COM server has no idea about this new sandboxed component.
There are probably more examples (services would also be a problem).
A better approach is to improve Sandboxie, for example, improve the sandboxed service manager, so sandboxed services can be properly installed and managed. There is nothing inherently problematic about this. It's only a matter of when I get around to it.
Posted: Sat Jan 27, 2007 4:48 am
by OwenBurnett
Ok, I see the point, without having the SBxed keys appear in the system as real this won't work.
But how about the layers think like in SVS, dissabling all protection and mapping keys and files into the real system works, could this be added? So that you could specify for particular sandboxes to be "integrated into the os" (Inntegrate=y) what would implicate no protection excepted registry and file writes.
Back to the primary toppic:
I have tested SVS with SB 2.64 and it seems to work OK, so it is possible to have SVS and SB running side by side, so that it won't work with 2.76 is a bug and should be fixed.
Owen
Posted: Sat Jan 27, 2007 6:57 pm
by tzuk
have tested SVS with SB 2.64 and it seems to work OK, so it is possible to have SVS and SB running side by side, so that it won't work with 2.76 is a bug and should be fixed.
I agree, but it isn't necessarily a
bug. Because the way Sandboxie is doing stuff has drastically changed in 2.7 over the way it was done in 2.64, perhaps there is now a
conflict, rather than a bug.
I'll look into this, but not immediately (sorry to say it isn't the most important problem on the table), and, I'm not sure I can promise a solution.
Posted: Sun Jan 28, 2007 4:01 am
by OwenBurnett
Could you add an obtion to make SB us the old way of doing things when the user needs it?
Owen