The /Box: parameter can be used to specify which box to use to start a program. That's fine, but I would like an option to select the box interactively from a simple list or a popup menu. I suggest the argument "/Box:?" to specify that the box name should be entered interactively.
(As a demo of what I wish, I wrote myself a tool to do that, and more, called SandboxToys.)
Also, it might be useful to have a "/Box:unsandboxed" parameter to be able to launch forced programs unsandboxed, without having to temporarily disable forced programs.
/Box: parameter extensions
Seems like not just here, but a few times recently, members have indicated a displeasure of some sorts with "temporarily disable forced programs". My feeling is just the opposite, I think it is just fine the way it is. I wouldn't even mind tightening it a bit.
If I designate a program to be a "forceprocess" that means that the overwhelming amount of times I use it, it will be sandboxed. If I only wanted to sandbox it sorta 50-50, I wouldn't force it but use "run sandboxed" instead. If something I want to do turns out to be a mouseclick away from perfect, I learn to work within that.
I think that there is a danger in making the program too interactive, as in security holes. Making the program all things in all situations might just make it all things for the wrong people.
"temporarily disable forced programs" should be a very important command to Sandboxie and one that is interpreted by the program correctly. Don't forget, the bad guys are out there trying to do one thing and one thing only - "temporarily disable forced programs".
I can only speak for my set-up of course, but my feeling is that if you very often have the need to disable a forcedprocess, you probably should consider "runas" as opposed to setting it forced. Not here in this case but I think many members take a blanket approach to forcing and then run into this situation.
mitch
If I designate a program to be a "forceprocess" that means that the overwhelming amount of times I use it, it will be sandboxed. If I only wanted to sandbox it sorta 50-50, I wouldn't force it but use "run sandboxed" instead. If something I want to do turns out to be a mouseclick away from perfect, I learn to work within that.
I think that there is a danger in making the program too interactive, as in security holes. Making the program all things in all situations might just make it all things for the wrong people.
"temporarily disable forced programs" should be a very important command to Sandboxie and one that is interpreted by the program correctly. Don't forget, the bad guys are out there trying to do one thing and one thing only - "temporarily disable forced programs".
I can only speak for my set-up of course, but my feeling is that if you very often have the need to disable a forcedprocess, you probably should consider "runas" as opposed to setting it forced. Not here in this case but I think many members take a blanket approach to forcing and then run into this situation.
mitch
I agree, however it is necessary to define your web browser as a forced program, as it is launched by many applications indirectly, and it runs unsandboxed in some circumstances when it is not forced. I hate to have to switch to the right box and to temporarily disable forced programs just to be able to launch my browser.
Also, I don't want a shortcut to launch the default browser unsandboxed created automatically by Sandboxie's installation procedure. I think that if the user has to create a specific shortcut manually to do that, he should know what he is doing.
Note that there is a trick to do what I suggest. I have copied firefox.exe as unsandboxed_firefox.exe, and created a shortcut pointing to that file. That works fine, but IMO it's not an elegant solution.
Also, I don't want a shortcut to launch the default browser unsandboxed created automatically by Sandboxie's installation procedure. I think that if the user has to create a specific shortcut manually to do that, he should know what he is doing.
Note that there is a trick to do what I suggest. I have copied firefox.exe as unsandboxed_firefox.exe, and created a shortcut pointing to that file. That works fine, but IMO it's not an elegant solution.
Lucas invented firefox1.exe and has it "secured" to his bank - I forget the thread but maybe Lucas can explain it here.
You are right in that is not an elegant solution, but Tzuk is working on things such as a revamped gui. I kinda like being able to tweak things lol.
Dlguild invented a means to use autosizer interactive with sandboxie - so I agree that individual applications need special "know how". I would just not like to see a blanket command approach.
mitch
You are right in that is not an elegant solution, but Tzuk is working on things such as a revamped gui. I kinda like being able to tweak things lol.
Dlguild invented a means to use autosizer interactive with sandboxie - so I agree that individual applications need special "know how". I would just not like to see a blanket command approach.
mitch
Last edited by MitchE323 on Fri Sep 07, 2007 6:32 am, edited 2 times in total.
There is one thing that I do not know, let's say I have three programs running and they are all sandboxed. Now I need to open unsandboxed a fourth program that I have set as forced in the sandboxie.ini file.
If I temporarily disable forced programs to open that fourth application - am I losing the sandboxed security in the other three programs?
mitch
If I temporarily disable forced programs to open that fourth application - am I losing the sandboxed security in the other three programs?
mitch
Ok thanks that makes sense. One more note back on topic;
I know it's just me, but I just don't feel right in renaming the exe files as a workaround. I can see the hash marks there or not there and the files are in the correct places - either in or out of the sandbox. But I've never read anywhere in the official documentation that it is a reccomended thing, also drag and drop. I think it works, but we have sorta stumbled into it. I dont know if there is a connection, but in at least three cases - members that advocated that they do that alot also have hard to delete files, "overlays" and "zero or empty files" - which I never have. It's like the sandboxes are broken.
I do it differantly (and much more tediously) by creating differant sandboxie.ini files and renaming them "on-the-fly" - thankfully it is a very rare thing. But at least at all times I am "official". lol
mitch
I know it's just me, but I just don't feel right in renaming the exe files as a workaround. I can see the hash marks there or not there and the files are in the correct places - either in or out of the sandbox. But I've never read anywhere in the official documentation that it is a reccomended thing, also drag and drop. I think it works, but we have sorta stumbled into it. I dont know if there is a connection, but in at least three cases - members that advocated that they do that alot also have hard to delete files, "overlays" and "zero or empty files" - which I never have. It's like the sandboxes are broken.
I do it differantly (and much more tediously) by creating differant sandboxie.ini files and renaming them "on-the-fly" - thankfully it is a very rare thing. But at least at all times I am "official". lol
mitch
I can confirm the "zero or empty files" problem. I noticed it immediately after having used Sandboxie for the first time, and before having made any tweak, and even having modified the INI file.
If you want to see a good demo of the problem, run Skype sandboxed, and have a look at the %TEMP% folder in the box.
BTW, I have just reported this bug today in this thread.
Maybe the problem has something to do with something non-standard installed on your machine (although I try to avoid non-standard apps and tricks), but it is certainly not related to any Sandboxie tweak.
If you want to see a good demo of the problem, run Skype sandboxed, and have a look at the %TEMP% folder in the box.
BTW, I have just reported this bug today in this thread.
Maybe the problem has something to do with something non-standard installed on your machine (although I try to avoid non-standard apps and tricks), but it is certainly not related to any Sandboxie tweak.
Ok I read that and will just let that play out over there. I agree that if a file doesn't exist on the real drive - it shouldn't be "held over" in the box. Something is wrong. The other instances I mentioned indicated that their overlays were systematic, and happened all the time. Is yours just with that one application? I'm like you, nothing weird the better. I've got the same Xp setup and everytime I close out the box emptys completely.
When you say that you noticed it immediately upon installation of Sandboxie, was that with or without Skype? Also of course I'm assuming that Skype is set as a "ForceProcess" in the ini and not merely "inserted" into a box?
mitch
ps - just noticed that Toys thread, will check it out later today on break.
2ps - This has nothing to do with this subject but since you are using the program you might want to check this; http://about.skype.com/news.html
When you say that you noticed it immediately upon installation of Sandboxie, was that with or without Skype? Also of course I'm assuming that Skype is set as a "ForceProcess" in the ini and not merely "inserted" into a box?
mitch
ps - just noticed that Toys thread, will check it out later today on break.
2ps - This has nothing to do with this subject but since you are using the program you might want to check this; http://about.skype.com/news.html
No, I have the same problem with all applications. I have mentioned Skype because it creates thousands of empty files each day, and it's therefore a good demo of what's happening, but I have the same problem with the temp files created by Firefox, and probably all other applications.MitchE323 wrote:The other instances I mentioned indicated that their overlays were systematic, and happened all the time. Is yours just with that one application?
I have first used Firefox to test Sandboxie, but haven't verified if it left some files in the box after completion. It's when I deleted the box after some hours using Skype that I noticed that there were many files to delete, thanks to the hard disc noise! Therefore, I launched Skype again, visited immediately the box with Explorer, while Skype was still running, and found several hundreds of empty files in the temp folder! Then, I checked this forum, and noticed that I'm not the only one having that problem. When Skype runs unsandboxed, only one or two temp files are present at the same time.
I will try to delete some files with a sandboxed explorer and a MS-DOS shell to see if they produce also the same problem...
Hum, it's somewhat confusing.
Here is what I see in my %TEMP% folder from a sandboxed MS-DOS shell:
Of course, since the shell is sandboxed, I can see a file that is not really in D:\Temp, but is in the box.
The same directory, virtual version in the sandbox:
No problem till here.
But if I check the virtual image of the Temp folder with an unsandboxed shell, here is what I see:
After having quitted Skype and the sandboxed shell, nothing is still running in the box, but its Temp folder contains still the 116 files.
Here is what I see in my %TEMP% folder from a sandboxed MS-DOS shell:
Code: Select all
Directory of D:\Temp
07/09/2007 15:43 <DIR> .
07/09/2007 15:43 <DIR> ..
07/09/2007 09:09 16,384 ~DF5CEB.tmp
1 File(s) 16,384 bytes
2 Dir(s) 26,231,713,792 bytes free
The same directory, virtual version in the sandbox:
Code: Select all
Directory of D:\Sandbox\Skype\drive\D\Temp
07/09/2007 15:43 <DIR> .
07/09/2007 15:43 <DIR> ..
07/09/2007 09:09 16,384 ~DF5CEB.tmp
1 File(s) 16,384 bytes
2 Dir(s) 26,231,713,792 bytes free
But if I check the virtual image of the Temp folder with an unsandboxed shell, here is what I see:
Code: Select all
Directory of D:\Sandbox\Skype\drive\D\Temp
07/09/2007 15:53 <DIR> .
07/09/2007 15:53 <DIR> ..
07/09/2007 15:53 0 sqlite_1UdzbWYRH6gbVz2
07/09/2007 15:53 0 sqlite_23fAJWux6cFRbd0
07/09/2007 15:53 0 sqlite_35oh9CnJZrLwOPE
07/09/2007 15:53 0 sqlite_3DNnuOxW0ucWDN8
07/09/2007 15:42 0 sqlite_4b94PL7hu2ub5Gw
07/09/2007 15:53 0 sqlite_5IFFPpsHSkLABC3
07/09/2007 15:53 0 sqlite_5V8BoRSpTxXe54l
07/09/2007 15:53 0 sqlite_5WWlSC3MbvkUg2g
07/09/2007 15:53 0 sqlite_6pe7sULNw5YN6te
07/09/2007 15:42 0 sqlite_7OO6WcxTLgvML0D
07/09/2007 15:42 0 sqlite_8Hw1fx9KZGXOVIX
07/09/2007 15:53 0 sqlite_9AgeQZZlMo8SxZH
07/09/2007 15:53 0 sqlite_9f7q9bXRi5NmxUQ
07/09/2007 15:42 0 sqlite_9jvT4OAIvFqua9V
07/09/2007 15:42 0 sqlite_bA6RyBwN954lNPw
07/09/2007 15:53 0 sqlite_BF0rSd300zyDn7n
07/09/2007 15:53 0 sqlite_BhhTfqPg9oDhPg2
07/09/2007 15:53 0 sqlite_bvpzceNcMegn83x
07/09/2007 15:53 0 sqlite_C5fzcEHvK1pJCu8
07/09/2007 15:53 0 sqlite_CaZaQimdvore2ai
07/09/2007 15:42 0 sqlite_cckbWzpA9YoqMR4
07/09/2007 15:53 0 sqlite_cEeOiBoWbKrAFGA
07/09/2007 15:42 0 sqlite_cH0Qpv3Uw2ruTsm
07/09/2007 15:53 0 sqlite_Ct3uGUtQfgFKvfX
07/09/2007 15:42 0 sqlite_cvhgBmSn1ztTki9
07/09/2007 15:53 0 sqlite_cXcr4YtMabr5qb2
07/09/2007 15:53 0 sqlite_dGwVPmmJ6WMz3GY
07/09/2007 15:53 0 sqlite_DLDSPuLMUm4Jdd7
07/09/2007 15:53 0 sqlite_dsSm7t0iNKmYdDQ
07/09/2007 15:42 0 sqlite_EmKZu4PprhNHXbL
07/09/2007 15:42 0 sqlite_EqDxfGShDdqW5bO
07/09/2007 15:53 0 sqlite_eUlUYSPEba2DzxP
07/09/2007 15:42 0 sqlite_ey9Ba7rr53yzj6G
07/09/2007 15:53 0 sqlite_F0HJjeL5tbbf1Yd
07/09/2007 15:42 0 sqlite_fQrQcYIPUShiyWo
07/09/2007 15:53 0 sqlite_gefwonTQFjHKFyb
07/09/2007 15:42 0 sqlite_gt75yaXYm1rvVHZ
07/09/2007 15:43 0 sqlite_Hbrh2BWCIQXoU4L
07/09/2007 15:42 0 sqlite_HTel10MkVWPeu5E
07/09/2007 15:53 0 sqlite_I00EoCKHYNfsQ8K
07/09/2007 15:42 0 sqlite_IhRLeGRQd81N3Xe
07/09/2007 15:53 0 sqlite_iKUqfuabqBSO0ba
07/09/2007 15:53 0 sqlite_iL1iHnKK0ylddsX
07/09/2007 15:53 0 sqlite_IW04GR23OTxEGCw
07/09/2007 15:42 0 sqlite_jd6UVZuiUXvc1KB
07/09/2007 15:42 0 sqlite_JqFINfbbM2yTB6U
07/09/2007 15:42 0 sqlite_k3o97WuaB0q1RvX
07/09/2007 15:42 0 sqlite_KvrugOKw7mva8qY
07/09/2007 15:53 0 sqlite_kXW3XjuBKrpCZzk
07/09/2007 15:53 0 sqlite_kzN4Txy9vpRw4tZ
07/09/2007 15:42 0 sqlite_lA1EV3KpQR9DdZh
07/09/2007 15:42 0 sqlite_lyP1Qc877dsKayl
07/09/2007 15:53 0 sqlite_MoYBGsY6FpP2mEM
07/09/2007 15:53 0 sqlite_muk7f8GCfQ5Ai0t
07/09/2007 15:53 0 sqlite_mxt6V8SGwghv6eT
07/09/2007 15:53 0 sqlite_n2Tu7MeIvd8ifPQ
07/09/2007 15:42 0 sqlite_n5JeFSVHnx7akeG
07/09/2007 15:53 0 sqlite_nbYTBf5t8SOuRsq
07/09/2007 15:42 0 sqlite_NHr7Rrz64tULfAk
07/09/2007 15:42 0 sqlite_paNcQDyxTmkIt0S
07/09/2007 15:42 0 sqlite_pvCnhXNk86ex8Ib
07/09/2007 15:53 0 sqlite_Qeq9Gwnwn6ybMYZ
07/09/2007 15:53 0 sqlite_QocGy1g8x5sqhE9
07/09/2007 15:53 0 sqlite_RZxzgNXRLyB8jsV
07/09/2007 15:42 0 sqlite_sb4FQn2RPdFb3bV
07/09/2007 15:53 0 sqlite_SF4w1OKqaBFhfw8
07/09/2007 15:53 0 sqlite_sVVLpqeus6hW4w3
07/09/2007 15:42 0 sqlite_t8k7Scj8NUsX4A3
07/09/2007 15:53 0 sqlite_TCHBmigMpBLunDT
07/09/2007 15:53 0 sqlite_tHMiTxQ2b1rMLeK
07/09/2007 15:42 0 sqlite_UbJhLuedYtaDxYo
07/09/2007 15:53 0 sqlite_UHyWhsKyp1Dyh2x
07/09/2007 15:42 0 sqlite_uiLgKjkZ2cYQxBg
07/09/2007 15:42 0 sqlite_VHCPBf0BoMV9yl6
07/09/2007 15:53 0 sqlite_VJ2UxM9v5CMZMXO
07/09/2007 15:43 0 sqlite_VXniZUQyd3obQ6O
07/09/2007 15:53 0 sqlite_W0SYN3pCRqee7eq
07/09/2007 15:42 0 sqlite_W32rjC6CFdlNG3h
07/09/2007 15:42 0 sqlite_wipVjejetFDmAwC
07/09/2007 15:42 0 sqlite_WK5TMlhHw1MMcmr
07/09/2007 15:53 0 sqlite_WUGI8UQqzVvWEb4
07/09/2007 15:42 0 sqlite_Ww1ggNEE5R6kmFd
07/09/2007 15:53 0 sqlite_x4qhPEYnLsOAPTh
07/09/2007 15:53 0 sqlite_XnjywgDRnroAehM
07/09/2007 15:53 0 sqlite_Xog3jkgFulxJXeg
07/09/2007 15:42 0 sqlite_xYjVBBzcNgqkB1X
07/09/2007 15:53 0 sqlite_yLhiXlWJ2eirRoc
07/09/2007 15:53 0 sqlite_YTCc9cqcrNupXtB
07/09/2007 15:42 0 sqlite_Z3HEPx5kwehRq7e
07/09/2007 15:42 0 sqlite_Za9FNjY60ym3PpL
07/09/2007 15:53 0 sqlite_ZbKhZ9UFoiPMtZo
07/09/2007 15:43 2,115 VMS124.tmp
07/09/2007 15:43 1,663 VMS125.tmp
07/09/2007 15:43 3,064 VMS126.tmp
07/09/2007 15:43 1,323 VMS127.tmp
07/09/2007 15:43 38,806 VMS128.tmp
07/09/2007 15:43 150,408 VMS129.tmp
07/09/2007 15:43 6,235 VMS12A.tmp
07/09/2007 15:43 1,794 VMS12B.tmp
07/09/2007 15:43 12,432 VMS12C.tmp
07/09/2007 15:43 443 VMS12D.tmp
07/09/2007 15:43 5,205 VMS12E.tmp
07/09/2007 15:43 1,543 VMS12F.tmp
07/09/2007 15:43 6,751 VMS130.tmp
07/09/2007 15:43 731 VMS131.tmp
07/09/2007 15:43 646 VMS132.tmp
07/09/2007 15:43 307 VMS133.tmp
07/09/2007 15:43 5,317 VMS134.tmp
07/09/2007 15:43 1,042 VMS135.tmp
07/09/2007 15:43 2,808 VMS136.tmp
07/09/2007 15:43 1,084 VMS137.tmp
07/09/2007 15:43 14,510 VMS138.tmp
07/09/2007 15:43 5,642 VMS139.tmp
07/09/2007 15:43 1,585 VMS13A.tmp
07/09/2007 15:43 1,406 VMS13B.tmp
07/09/2007 15:43 925 VMS13C.tmp
116 File(s) 267,785 bytes
2 Dir(s) 26,231,693,312 bytes free
Well, since this topic has kinda switched over to the concern over empty files posted in your other thread, and there has as yet been no replies in that thread - maybe it might avoid confusion if you just go ahead and delete that post or copy paste it here.
We can work towards the answer on this but first there is one item:
Once before and I'll look for the thread, a member had a similar concern. In both cases the members assumed this was normal behaviour (I guess because it happened from the start.) -
This is not normal, your box should empty completely. No zero files, overlays or anything. Now I remember, it was Tristan's problem here http://sandboxie.com/phpbb/viewtopic.php?t=1955 I think Tristans problem was created along the way - but you've had this from the get-go on day 1?
mitch
We can work towards the answer on this but first there is one item:
This is from your other thread.Not sure if it's intentional, but when a sandboxed program deletes a file it has created, the file is not really deleted, but only emptied.
Once before and I'll look for the thread, a member had a similar concern. In both cases the members assumed this was normal behaviour (I guess because it happened from the start.) -
This is not normal, your box should empty completely. No zero files, overlays or anything. Now I remember, it was Tristan's problem here http://sandboxie.com/phpbb/viewtopic.php?t=1955 I think Tristans problem was created along the way - but you've had this from the get-go on day 1?
mitch
OK, I've linked the other thread to this one.
Don't be confused (and sorry if my english is not always easy to understand - it's not my native language.)
The box is correctly emptied when I use the Contents of Sandbox -> Delete Contents tool. It's when the sandboxed program itself deletes a file it has created that the empty file remains. When the program is terminated (either normally or killed by Sandboxie) and if the Automatically Delete Contents of Sandbox option is not ticked in the Automatic Cleanup Options dialog, the file remains too. The whole box is correctly deleted otherwise.
Don't be confused (and sorry if my english is not always easy to understand - it's not my native language.)
The box is correctly emptied when I use the Contents of Sandbox -> Delete Contents tool. It's when the sandboxed program itself deletes a file it has created that the empty file remains. When the program is terminated (either normally or killed by Sandboxie) and if the Automatically Delete Contents of Sandbox option is not ticked in the Automatic Cleanup Options dialog, the file remains too. The whole box is correctly deleted otherwise.
OH, Ok, so a sandboxed program is running and during it's normal process - it deletes a file (and that file is also sandboxed). Now when you close that program, the deleted file remains and if auto delete isn't ticked, will remain there forever. Your english is just fine.
The first program must be trying to delete from the standard C:\Temp file (maybe you can redirect this within that program just for at least Skype as an interum fix). It does delete the contents but a zero file is still in the sandbox. Nothing has told Sandboxie to delete all - so they just sit there.
Sounds like a cache thing - like sometimes when you change a programs icon, you dont immediately see the new icon and have to clear the icon cache before it appears. But if you click on the properties on that program, it shows the new icon.
Some kind of a bug though - I think Sandboxie primarily does a good job as far as sandboxed programs interacting with your system, but maybe there is something here as far as Sandboxie governing the interactions required "within" the sandbox.
Sort of like Sandboxie needs some kind of 'real time' function as far as deleting these files. In the meantime maybe you can set a custom clean within CCleaner to that sandboxed Temp folder - so at least those files are gone on reboot.
The first program must be trying to delete from the standard C:\Temp file (maybe you can redirect this within that program just for at least Skype as an interum fix). It does delete the contents but a zero file is still in the sandbox. Nothing has told Sandboxie to delete all - so they just sit there.
Sounds like a cache thing - like sometimes when you change a programs icon, you dont immediately see the new icon and have to clear the icon cache before it appears. But if you click on the properties on that program, it shows the new icon.
Some kind of a bug though - I think Sandboxie primarily does a good job as far as sandboxed programs interacting with your system, but maybe there is something here as far as Sandboxie governing the interactions required "within" the sandbox.
Sort of like Sandboxie needs some kind of 'real time' function as far as deleting these files. In the meantime maybe you can set a custom clean within CCleaner to that sandboxed Temp folder - so at least those files are gone on reboot.
That's it. I agree totally.
I have already made something to clean all boxes automatically at reboot. I have placed a shortcut to my SandboxToys.exe with the /cleanup /quiet arguments, in the Startup folder of my Start Menu. But I would prefer to see this bug fixed in a future version of Sandboxie. It's why I report bugs, not just to complain!
I have already made something to clean all boxes automatically at reboot. I have placed a shortcut to my SandboxToys.exe with the /cleanup /quiet arguments, in the Startup folder of my Start Menu. But I would prefer to see this bug fixed in a future version of Sandboxie. It's why I report bugs, not just to complain!
Who is online
Users browsing this forum: No registered users and 1 guest
