1. What actually happened or you saw:
Having Containment Policy set to Run Virtually for all Unknown Files, with Untrusted restriction level selected. When manually running an application inside Containment (Right click → Run In Comodo Containment) and using said application for opening a Unknown file, the Unknown file will inherit the “Fully Virtualized” level (without restrictions) from the application that was used to open it.
2. What you wanted to happen or see:
Let’s say I have a Web Browser Manually Contained. Then use it to download & open a Unknown file (Malware). I would like having my selected Auto-Containment policy for all Unknowns (Run Virtualized & Untrusted) being applied to such Unknown file, in this case.
3. Why you think it is desirable:
This also would be useful when setting Comodo to Block Unknowns, so users will be able to emulate the behavior of NVT ERP (Anti-executable software) + Sandboxie (Application Virtualization) security combo.
Also helpful against Cryptocurrency Mining Malware and other Malware that abuses CPU usage or System resources usage.
Possibly could exist a checkbox in Containment settings for enabling/disabling such behavior, for those not wanting it.
4. Any other information:
Should apply only for Files rated as Unknown. “Safe” Files opened by Manually Contained Applications should always be runned as Fully Virtualized level.
I’m confused as to why you would manually run a file in the sandbox that you do not trust, but that your own Auto-Containment rules do not have a problem with, however you would allow any file that it creates to potentially be trusted by the same Auto-Containment rules that you disagreed with to begin with?
By using Auto-Containment rules for a file opened by a manually virtualised file, you are potentially weakening (although not in all cases) the security by allowing these files to not be contained at all (never mind having a restriction level applied to them).
If you are just concerned about the Restriction Level set to to manually virtualised files and their child files/processes, then maybe the more simple solution would be instead to allow the user to select a restriction level to be applied for manually virtualised files. Otherwise you run into the issue above.
It’s just that I like to run my Web Browsers inside Containment, always at Fully Virtualized level. Restriction levels often causes the Web Browsers to not work properly/glitch some of its functionality, this being the main reason for this Wish.
When I manually open some dangerous file inside Virtualized Browser, my Auto-Containment policy (Restriction level) do not apply, e.g the dangerous file is opened as Fully Virtualized. I would like having an option to change this behavior if possible.
Yes I do know I can just open the file outside the Virtualized Browser, however a novice user which I share my PC with, would not know that (I have set CIS to always contain Web Browsers as Fully Virtualized).
Also one could argue why I just don’t run my Browsers inside Containment, I do virtualize them for Privacy purposes (Retaining temporary files/junk inside VTRoot folder for flushing it later).
EDIT: You do have a point, this should apply only for files rated as Unknown. Safe files should always be opened as Fully Virtualized. I changed first post to mention that. Thanks for your input.
Allowing an application that is contained to pass on data to a file/process that is outside of containment voids the application being contained in the first place.
Regarding privacy, allowing your contained browser executable e.g. chrome.exe to access and update files outside of containment also voids your use in terms of privacy. I.e. The contained chrome browser would then be able to update the browser cache etc outside of containment as normal.
If you would like contained applications to write to files that can also be accessed by none-contained applications, then the 'Shared Space’ is already setup for you to be able to do this and should be located at C:/Program Data/Shared Space
Thanks. Maybe I was not very clear, but the intention of this Wish is to apply the Containment Policy (Run restricted, block, etc.) for Unknown Executables run/called-by/invoked by user-manually Contained Applications.
Safe applications called by user-manually Contained Apps in this case, should be treated as default Fully Virtualized only, and not allowed to run outside Container.
Let’s say a novice user which I share my PC with, download some infected file with Keylogging capabilities, then open it through Manually Contained Browser (Infected file will be opened as default Fully Virtualized, e.g no protection against its Keylogging capabilities), then novice user goes straight to Paypal login page or proceed to insert sensitive information on another Website… Yes there is Firewall outgoing monitoring for that, but some Malwares do use Windows BITS Service or svchost.exe for phoning home…
Also those annoying PUPs/Browser Hijackers that get installed inside Virtualized Browser, monitoring browsing behavior, etc. A Block Policy or Access Restriction level being applied to them, would suffice.
Third example would be a Cryptocurrency miner malware, it needs Access Restrictions or Block policy being applied to it, because default Fully Virtualized is not enough in this case. Those are all I can think of at this moment.
you can kind of already do that second thing. By auto denying admin access to things running in the container. I would totally want to be able to continue blocking all unknown files as well as all known malware while running my applications in the container.
That’s why I submitted a wish that they allow the user to make more containers each with their own auto-sandbox rules and exceptions to the virtualization.
The main sandbox would continue doing as it always does, static analysis in a controlled environment to determine the safety of an unknown file, but the sandboxes that the user would make and configure to their own wishes would be specifically for the user to sandbox legitimate applications.
The user could even temporarily disable the auto sandboxing rules so they can update the applications they use in the container before enabling the rule again.