Containment V12.2.2.7036 - What applications can be run in it and what not?


I would like to know more about what type of applications can be run in containment and will be isolated from the underlying system and as such not make any changes to the underlying system.

To sum up some type of applications:

  • Installers that install service(s) for the application being installed which needs the service(s) to work.
  • Installers that install driver(s) for the application being installed which needs the driver(s) to work.
  • In general, applications that install and use service(s) for it to work.
  • In general, applications that install and use driver(s) for it to work.

Are the above applications types supported and can they be fully run in contaiment?

What is not supported to be run in containment?


completely virtually (install application complete)
virtually restricted (installation limited)

Hi liosant,

Thank you for your reply.

I’m trying to understand your reply… :slight_smile:

I think I get your first line “completely virtually (install application complete)” most likely meaning that when the installation of an application in containment is successful it then runs completely virtually. That makes sense to me.

Now for your second line “virtually restricted (installation limited)” do you mean by that when parts of the installation of an application in containment could not be virtualized it then runs as virtually restricted?

I would like to know what parts of an installation or what parts of an application cannot be virtualized in Comodo containment.
From other Sandbox products I know that they cannot create or start services and/or drivers is their sandbox which limits their Sandbox usability. Is Comodo Containment able to virtualize the creation of services and drivers and running them virtualized?

Any application running as Fully Virtualized level can be installed succesfully inside Containment. If the program you plan to install attempts to register Keystrokes or copy content from the Clipboard it won’t work though, due to security limitations imposed by the Fully Virtualized level.

I think Liosant probably meant that Restriction levels (Partially Limited, Limited, Restricted, Untrusted) may break some programs if selected, and this is true indeed.

As for Services or Drivers running inside Containment, there are no incompatibilites as far as I know. There is an option enabled by default in Containment settings which is "Enable automatic startup for services installed in the container ", as long as that is enabled you probably won’t face any issues if installing something inside Containment.

There used to be an incompatibility with .msi (Windows Installer) file extensions in the past which were unable to install/be executed inside Containment, but I think this has been adressed in recent versions of CIS if I am not mistaken.

If you Reset the Container, the programs installed inside Containment, as well as their files/folders located at C:\VTRoot\ will be completely erased though.

I’m not sure, but there could be a danger if there are folders that are not virtualized, e.g. shared space. This could be a way for a program to break out to the host/real PC:

Setting in Containmaint: “Do not virtualize … .”

Have a look in comodo help 12 page 123: short explanation about virtual desktop and secure shopping. In secure shopping you can use programs etc. as well. Secure shopping not only is for shopping, an isolated environment, too.

mmalheiros, prodex,

Thanks a lot for your information, that already clarifies a lot about how Containment can be used.

Regarding registering Keystrokes, I assume that a contained application which is using standard API calls to read the keyboard will still work and that low-level Keyloggers are blocked from reading the Keyboard directly,

Regarding the Clipboard usage, I guess that multiple applications can be run in Containment at the same time (correct me if I’m wrong) and the clipboard (copy) function will work between the contained applications but the Clipboard (copy) function will not work between any Contained application and the host system, am I correct?

About the Restriction Levels, I understand that depending on the Level this can have an impact on how an installer or application behaves inside containment and that their functionality can be affected.

As for Services and Drivers, good to know that these can be installed in containment and be run in containment and that even after a reboot these contained services/drivers still continue to work, that’s really a great feature!

Reset The Container, that function is similar to other Sandbox products so that I’m familiar with.
I already found out that containment stores the virtual file system in "C:\VTRoot". The naming of the sub-directories (if you have multiple partitions on the HD) is something to get used to. The sub-directories are named “HarddiskVolumex” (x being the volume number starting from 0 for drive C:) instead of just using the drive letter assigned by the OS as a name for a sub-directory.

When an application is running in containment and that application makes changes to the virtual Registry (create/modify/delete keys) where are these modifications then stored?
Are those virtual Registry changes kept in RAM or also stored in a file in "C:\VTRoot"? (I didn’t checked that yet).

About the Shared Space (or non-virtualized directories) danger, when an application which is running in containment creates a child executable in the Shared Space (or in any other non-virtualized directory) and starts/runs that child executable from that location then that child executable is potentially able to access the host. If this is correct then this is something to pay attention to.

About Virtual Desktop and Secure Shopping, I have read the manual but to me all these features, compared to Containment, look more or less the same with respect to how they protect your data and the host system. For my better understanding I have a some questions.

  • Do these features add extra protection layers to Containment or are these features based on another principle (apart from Containment)?
  • If they are based on Containment and add extra protection to it what are these protections?
    For example, what would be the difference between running a browser in containment and on the Virtual Desktop and in Secure Shopping?

An additional question, suppose one is using an email client and that email client normally stores all its received and sent emails in a local file on the HD. That file is text based and a malicious application could read its content. Could one of the Comodo features be used to protect or prevent this file from being read by malicious applications whether or not the email client is running? (And without losing the file content when the content is changed by the email client of course).

Thanks a lot.

Yes, both are correct.

I am not entirely sure on this one but I think they are also stored at VTRoot.

You can check this wish for more details on this.

For Secure Shopping, they implemented some protection layers existing on Comodo Secure Box enterprise product. As well as the AV module will check/scan all Web Scripts/Objects loaded during browsing in Secure Shopping.
Not sure about Virtual Desktop, but I think it’s mostly a graphical interface for Containment (This maybe will help to prevent some Malware from abusing flaws on Windows GUI elements or related stuff if I am not mistaken).

There is Protected Data Folders for that (it will work even if HIPS is off) but it will hide the content of selected folders/files for all applications running inside Containment.

That’s indeed a pitfall, when running an executable directly from a shared space and the user doesn’t know that it isn’t or won’t be virtualized, harm can be done to the system in that case.

That pops up another question, when one runs an executable directly located in VTRoot (the executable was put there when it was run in Containment before) does it then run automatically in Containment again or does it run outside Containment directly on the system?
From another Sandbox product I know that when you run an executable directly inside their local virtual directory (like VTRoot) then that executable still runs within the Sandbox so not affecting the system.
How does Containment handle an executable run from VTRoot directly?

There is an Auto-Containment rule for Blocking the execution of files/programs opened through the Auto-Containment folders (In this case VTRoot, according to File Groups).

Thank you for pointing to that Blocking rule for VTRoot, I understand it.

Would it work when this Blocking rule for VTRoot is set to Run Virtualize (so any executable opened through VTRoot would then again be run in Containment) or would that cause some sort of recursion inside Containment?

I did a quick test here, by using HitmanPro.exe executable (removed SurfRight from Vendor List, as well as HitmanPro.exe from File List, disabled Cloud Lookup) to make sure it was treated as Unknown. I temporarily disabled my Auto-Containment rule for Unknowns (Block), changed the rule for Auto-Containment Folders from Block to Run Virtually, copied and pasted Hitmanpro.Exe onto VTRoot and tried to manually start it from there > It was isolated as Fully Virtualized.

I hope you have the test rules still in place :slight_smile:
Does it also still work when you first start hitmanpro in Containment (start with an empty VTRoot (reset Container first)) and then after closing hitmanpro (not resetting the Container) run it manually from VTRoot directly?

Thanks for checking this, much appreciated!

I tried to launch HitmanPro.exe around 5 times or more through an empty VTRoot folder and without reseting the Container, it was isolated all times. Also was able to succesfully do a Scan with it (lol).
If I open Explorer.exe through Containment and try to manually start HitmanPro through virtualized VTRoot folder, it won’t start showing an error message.
Forgot to say I am still on CIS V12.0.0.6882 and on Win7 x64, but I doubt this behavior could change/been modified on V12.2.

I’ve done also some testing, I couldn’t resist :slight_smile:

Auto-Containment rule for VTRoot set from Block to Run Virtually.

Instead of hitmanpro.exe I used explorer.exe from the windows directory as test object (I didn’t need a scan :)).
Started with an empty VTRoot, then ran explorer.exe virtual by using the “Run Virtual” button (or right mouse click “Run in COMODO container” would do the same) and did a copy and paste of explorer.exe from the windows directory into the C:\User (just a random pick, doesn’t matter) directory.

With the above, I have observed the following:

  • Virtual explorer.exe cannot access VTRoot directory (Access Denied, I think that is obvious).
  • Virtual explorer.exe can access C:\Users\explorer.exe and run it (C:\Users\explorer.exe also runs virtual because the parent explorer.exe runs virtually).
  • Explorer.exe running directly from the system can access C:\VTRoot\HarddiskVolumex\Users\explorer.exe and it runs virtually as set by the Auto-Containment rule.
  • Trying to start C:\VTRoot\HarddiskVolumex\Users\explorer.exe using the “Run Virtual” button or per right mouse click “Run in COMODO container” results in an error (I think the same error as you have seen).

I think above behavior is quite normal and nothing worrying.

It is good to know that one can choose how an executable located inside VTRoot is handled when opening it through VTRoot directly by setting the appropriate Auto-Containment rule (Run restricted/Run Virtually/Block/Ignore).


I’ve did some tests to find out where Containment stores the changes made to the Registry by a contained application.

Started the test with an empty VTRoot (Reset Container)

I ran regedit.exe directly from the system (and left it open during the test) and navigated to a random location (location is not important) easy to remember.
Now I ran another regedit.exe in containment and navigated to the remembered location and added a random (test) Key to that location and set it to a random (test) value.
Regedit.exe ran from the system directly doesn’t see the added Key added by the virtualized regedit.exe even after refreshing by pressing F5, this is expected of course.

When I now check the content of VTRoot it remains empty (apart for some created sub-directories but all of them are empty).

To check if the added Key by the virtualized regedit.exe would survive a reboot I rebooted the system.

I ran regedit.exe directly from the system again to check for the added Key and as expected it was not there.
When running regedit.exe in containment the added Key as expected is still there so it survived the reboot.

However the content of VTRoot is still empty (not counting the empty sub-directories).

So the question is: Where does containment stores the virtualized Registry?


While writing all this it popped into my mind that it could be stored in the local registry itself, so I did a search for the added Key and found it. It seems containment stores its virtualized registry here:

HKEY_LOCAL_MACHINE\SYSTEM\VritualRoot ( Is VritualRoot a typo or intended? :slight_smile: )