CIS apparently works fine, but Allows applications in "auto-containment"

  1. Exceptions to self-containment can be deleted or modified
    One or two sentences explaining what actually happened:
    CIS apparently works fine, but Allows applications in “auto-containment” to erase, change files in shared folders;

One or two sentences explaining what you expected to happen:
Advanced configuration of command line analysis, work in firewall and sandbox modules
If a software compatibility problem have you tried the advice to make programs work with CIS?:

Any software except CIS/OS involved? If so - name, & exact version:

Any other information, eg your guess at the cause, how you tried to fix it etc:
The problem came to be presented in this new version of the Comodo Internet Security v10.0.1.6209
Apparently the error will only occur in the default settings, since programs run in “auto-containment” have unrestricted access to the shared folder
The problem may be related to the runtime or persistence of the applications (trojanscrypt is a big problem).
At least with my common user experience, I realize this

Exact CIS version & configuration:
Comodo Internet Security v10.0.1.6209 update
Modules enabled & level. D+/HIPS, Autosandbox/BBlocker, Firewall, & AV:
antivirus: disable (The intention is to test “auto-contaiment”)
auto-contaiment: default and block> folders share > if all and *\cmd.exe *\conhost.exe (Partially works)
HIPS: disable

Have you made any other changes to the default config? (egs here.):
Have you updated (without uninstall) from CIS 5, 6 or 7?:
if so, have you tried a clean reinstall - if not please do?:
Have you imported a config from a previous version of CIS:
if so, have you tried a standard config - if not please do:
OS version, SP, 32/64 bit, UAC setting, account type, V.Machine used:
Other security/s’box software a) currently installed b) installed since OS, including initial trial security software included with system:

To understand better download the file of the topic:;msg846640#msg846640

Not a bug, sandboxed/contained applications are allowed write access to the shard spaces file group. You can disable such feature in sandbox settings.

Yes, I suppose this is “a necessary evil” but try to understand the text below:

People who work with image editing, documents or so important … can add folders containing photos people, work … and end up losing because a malware had improper access to shared folders, for example.

A solution not so sure, but that would reach the middle ground balancing security and usability.

Let’s say I downloaded a file with the extension * .txt, * .doc … and they are located in the “shared folder”. We know that a lot of people use notepad, MS office, libreoffice … each of them accesses these files in different ways if we click twice or through the context menu “open with …” even though they are secure files would be executed Virtually allowing you to save changes such as text, image, video editions … but in case of different access, Auto-contaiment would block access other than the command line used by these programs, for example: let’s say open a * .doc file via context menu is “open with …” (system> shell32> office> and the document). If the command differs from the applications in the Comodo trusted office application database, Auto-contaiment blocks