"Treat as installer" & "Safe file runs safe file" changes V3->4

at Endymion:
yes, this (temporary)
and the list under "defense+ ----> security policy-----> “edit” explorer exe-----> “access rights”-----> modify: “is allowed to start other application” (permanent)
can cause that. because the rules remain there maybe forever. when you dont look in it.

at EricJH:
if you meant me, my example showed the described behaviour in my test post. the circumstances of installation caused mainly a question in the head of a customer, and didnt caused questions from cis :smiley: . as it happened while installation it would be anyway to late, if a maliciousprogram would take this place in this example.
as long as nothing takes the disc-place of the uninstalled game exe one day, in the same path as in explorer rights (see above), someone has to start the file himself.
whats about the replacing question? how could cis tell, if an exe is the real meant executeable file, which the user has choosen to be allowed to be started by explorer exe? what degree of changes must appear, so that another file couldnt take its place?

but what important is from what happened:
when you treat an installer as an installer with cis, MAKE SURE you dont start the installed program in any way connected (time, or process) with the installation process. only if you trust it to be right to have “installer”-rights too. because thats what it maybe get otherwise. (or at least it remains in a status inside a installation process, until its closed again).

someone should change the topic headline to this last fact. “programs might become child process of their installer”, or like that.

Since you were testing in paranoid mode does this mean…

…that you marked the alert to run that installer to be remembered then? ???

BTW Testing with ccleaner installer (D+ paranoid mode, sandbox disabled) confirmed the design behavior.

Perhaps this topic should be moved to the Help board. :-La

maybe i dont write exact enough in english.

at endymion:
i confirmed your words about “cis remembers something temporary as long as the allowed program is running”. in this case is explorer exe allowed to start the installer until explorer exe is closed. like you said.

the list was mentioned by me, to speak about things which had been marked as remembered to be allowed to be started by explorer exe. for example: explorer exe is allowed to start something. this rule would stay. as you dont erase explorere rules, it will stay “forever”. particulary for explorer exe rights to start another application. even if the application isnt anymore on your pc, and its own rules have been purged already.

the second thing what i was saying, confirmed what ss26 mentioned. when you start an installed program somehow inside the running installer (mark “start the program after installation”, or in any way inside a window of the installation), then the installed program may run the first time as a part of the installation, or as a child process of an installer, who was given rights “installer or updater”.

its not a bug, as we saw, in a direct way. but its a behaviour that is not very obviously. an installed program should never become a child process of its installer in the eyes of cis defense+

Despite users might distinguish it from other apps due to its purpose an installer is a program as well.

Besides the installer/updater policy is seemingly tailored to provide a seamless installation of trusted (but unrecognized) applications at the user convenience whereas by default (sandbox options) it also cause D+ to automatically add the installed files to the user safelist:

IMHO it would not be very obvious for any user to rely on the installer policy (and grant such executable full control over the system) and have concerns about the ability for the installer to automatically start the last executable they can see and thus recognize as the installed application.

Perhaps such snippet could warrant a new topic in the wish-list board. Please let everybody know if you create such topic as it is likely that many member will vote for it:
Indeed a purge option would be something good to have even for the access right (modify…) exceptions.

Not sure if an automated purging would be a desired option considering that some legitimate developers fancy with on-the-fly executables that are often deleted after use.

Whereas such executables might not be safelisted nor digitally signed they could cause the corresponding policies and exceptions to be removed if automated puring would be in place (thus triggering alerts again).

Adding any unrecognized (but trusted) executable to the safelist could be a far easier way to manage V4 and prevent the creation of policies and exceptions in the first place whereas “My safe file” list can be also easily purged.

I am urging you to give is a url of the program you are testing with. :P0l This topic gets needlessly abstract if we can’t verify your findings.

It is my hypothesis for the moment that the application you are trying to start is probably considered safe by Comodo.Therefor, with the new v4 defaults for Safe Mode, when starting it with Explorer will automatically start and add the application to the list of applications Explorer is allowed to start. I think you are confusing this with the effect of the Installer/Updater policy.

Similar FR (feature request)

Thanks. :-TU

i already said, i tested vietcong1 installer. this topic is finished. the result is: applications become child processes of an installer (and get the rights of a child process inside an installation), when they are started after installation, but with/inside the installer. this lasts until they are closed. next time starting will trigger expected questions from defense+. but until then, they have “more rights than a game for example should have”.
no bug, but in a way a not perfect way how defense+ acts in front of an installer who gives the possibility to start the installed application at once.
you can try it with any installer who gives you this possibility. “launch application after finish the installation”.

i will make a topic for the purge of modify rules suggestion in wish list (will see if theres one already).

This is obviously of no concern for the purpose that installer/updater policy serve though nobody is prevented to get “(way or somewhat) more alerts” if they wish whereas if the installed application raise immediate concerns the installer should be treated in the same way as well.

As for games in particular some of them might need to get more rights than the user expect them to request on their 1st run:
for example some games behave like installers and carry an one-time installation of their DRM device drivers.

And WHERE may I ask, is this hidden place? I do have quite a bit of obsolete rules to be rid off too… ;D

defense+ ----> security policy-----> “edit” explorer exe-----> “access rights”-----> modify: “is allowed to start other application”
there are modify boxes with some others. but the first one is handling the first question under paranoid mode: explorer exe tries to execute something.
https://forums.comodo.com/wishlist-cis/more-purge-buttons-needed-t54421.0.html

at Endymion:
you are right. but if you would install for example a “browser”, and start it right away in an installer, and theres a hacker or a site exploit, he/it could use the browser in that moment as a door which has installer rights, or which is part of an installation. usually everything is fine, but there are scenarios.
its something to know about, but anyway, to have cis is better than not to have it :wink: , because it reduces drastically the possibillity of threats.

It’s really great that this (and the explorer issue) have been tracked this down.

A question I have for Endymion is: how does this relate to how v3 operated, as we are going to have to explain any change to users? In version 3 you defined something as an installer/updater and this launched an (optional) installation mode, which was time limited, but did this mode apply to more than just the installer and the files it (directly/indirectly) ran? In version 4 it seems that the effects are limited to files that are run directly or indirectly by the installer (ie called by files which are called by files and so on recursively), but the duration of the privs is not time limited. The duration is until the installer (or any programs calls be it) are closed.

Another question is how we deal with this really useful thread, as it could drift if we leave it. It’s revealed important wishlist items rather than bugs, I think, both in respect of the explorer and installer issues. (Is that right?). Would anyone like to take on adding wishlist items (or clarifying existing ones). Maybe I or EricJH could re-post this trace in Help and you could refer to it from the wishlist items?

Tell me what you think

Mouse

IIRC in V3 long installations spanning over a sequence of multiple processes could cause the Run Executable alerts to popup again (and request users to select the installer policy again) whereas installer mode triggered another series of specific message boxes during the whole installation (to disable policy inheritance):

That was a whole deal of alerts that the users had to cope when they got to install a Trusted application.

As far I remember while V3 installer mode was active it extended the (installer/updater) policy to the setup application and a certain number of its child processes (policy inheritance) and within its constraints it could cause the finally installed application to inherit the installer/updater policy as well (and thus full privileges).

There was no guarantee that the message box meant to disable the policy inheritance would appear soon before the setup was to launch the finally installed application:

On the other hand it was possible to manually disable V3 installer mode anytime using CIS summary screen but simply unticking the setup’s checkbox to launch the finally installed application was (way) faster.

As far I see V4 streamlined this approach and might automatically add the installed files to “My safe files” list granting them full privileges whereas this is seemingly meant to make the installation of unrecognized but Trusted applications as seamless it is possible.

AFAIK V3 Installer mode enabled policy inheritance globally.

IIRC V3 Policy inheritance itself affected child-applications (with undefined access rights) whose parent got a policy and this had some side-effects:

[ol]- Desirable: Using a custom predefined policy on an unrecognized installer/application to trigger user defined alerts for such unrecognized installer and also its recursively spawned unrecognized sub-installers/applications (with undefined access rights) :-TU

  • Undesirable: Inheritance got enabled also for existing policies under "Computer security Policy and thus also for their eventually spawned unrecognized child processes (with undefined access rights): each one got a different policy inherited by the corresponding parent :-X[/ol]

Thanks very much Endymion, so summarising:

V3 Updater/Installer policy + Installation mode: Wider inheritance of rights, but you are asked whether you want to terminate it after a given period.
V4 Updater/Installer policy + Elevated privs mode: Narrower inheritance of rights, which terminates only on termination of the installer.

Both leave the installed application with installer rights if run from the installer.
In both cases the rights held by installation software is pretty wide - the ‘elevated privs’ ilanguage in version 4 arises in part from the restriction of OS account privs in version 4 sandboxing.

If I move this topic to Help and, if appropriate, do a brief FAQ (after confirming what v3 did with Egemen). Could you, if you have time, add wish list items for this and the explorer issue (if appropriate and not already there) as you clearly understand this better than I?

I’ll probably move the topic tomorrow am

Best wishes and thanks again.

Mouse

Looks there is/are already wishes that apply to explorer in more PURGE buttons needed but perhaps adding a poll could provide more visible acknowledgement.

As for policy inheritance it was recently removed restricted and I never saw any other member wish for or appreciate that possibility so I’ll wait for a while until V4 complete the addition of the other announced features (eg GUI, behavior blocker)

Thanks Endymion, that sounds very sensible.

Moving topic now.

Best wishes

Mouse

Sorry to bump this topic after the immediate action. After initial scepticism that lead me to believe clockwork was erroneous I did some testing. My findings I meant to post somewhere halfway the current topic length but I got sidetracked and forgot about it.

In the process of testing and making reproduction scenarios I incidentally reproduced the scenario from clockwork until I rebooted:

  • Install a program and after installing don’t let the installer start the program
  • When starting the program with Explorer/shortcut I would get no D+ alerts
  • Start the program with Explorer/shortcut
    The reboot broke the reproduction. Looking back at the process I see that the installer I used more than several times in the fine tuning process crashed once or twice.

For now I am wondering/hypothesizing that a crash by an installer may trigger the inheritance of rights from the installer to Explorer.

When I get an installer crash I will try to test again.

On a serious moderator side note.

This topic was initially posted in the bugs board and to be honest the topic start lacked more than just a few requirements as set by Important: how to submit bugreports (read this if you want them fixed).

The lack of these requirements lead to needless confusion and abstract conversations.

What was most missing was a clear and concise description of steps to reproduce the problem. Nor was there a program we could easily download and install and play with.

In short when making a claim about a bug or proof of concept of a breach give us something we can click on. That way all users can start testing and post their findings. As a consequence we can further refine or falsify a claim. Some bugs may be triggered on certain version of Windows, or only with certain program(s)…etc…

As a practical consequence when you notice something odd or peculiar about CIS and when you are not a long term user start with a topic in the Help board with a title like “[odd behaviour]bug or by design?”. This will prevent the bug board from being cluttered and will gave fertile playground for further and fruitful investigation.

I believe that systematic investigation by multiple users will lead to better bug reports and wishes to Comodo. O0

When judged a bug no moderator will object to moving it to the bug boards.