1. What actually happened or you saw:
Under “Advanced Settings” > “Defense+” > “HIPS” > “HIPS Rules” you can edit the ruleset for a desired application.
Every access right rule can be set to “Ask”, “Block” or “Allow”, except for “Run an executable” rule which can only be set to “Ask” or “Block”.
2. What you wanted to happen or see:
Users should be able to set the “Run an executable” access right rule to “Allow”.
3. Why you think it is desirable:
There are various situations where a trusted application could run an executable. As for example “taskeng.exe” creates temporary/random visual basic scripts that launch the browser.
This could suppress all prompts of the known application if it is requested by the user without losing HIPS capabilities.
4. Any other information:
If there are multiple applications to be executed then every application will inherit this access right temporarily.
Let’s say Application tries to run Application which tries to run Application.
In this situation, Application and Application will inherit this access right as the user allowed Application.
After Application and/or Application are closed they lose the access right as it is only temporary (unless set to “Allow”).
This issue feels very familiar to me. However, I have not been able to find a report which covers this, either in the Wishes or the bugs. I’m not sure if this is just because I’m tired, or that there really has not been a report for this already submitted.
If anyone else also feels that this may have already be submitted please let me know. I really do believe this has already been submitted, and would hate to waste anyone’s time. However, if a report cannot be found I will have to conclude I am wrong and process it. However, for the time being I will leave this here.
Thank you for submitting this Wish Request. I have now moved this to the WAITING AREA.
Please be sure to vote for your own wish, and for any other wishes you also support. It is also worthwhile to vote against wishes you think would be a waste of resources, as implementing those may slow down the wishes you would really like to see added.
Yes, please add this option. I have missed this feature many times, and wondered why the option is missing.
There are programs whose main purpose is to start other programs, for example scheduling programs, terminal programs (e.g. PuTTY), and shells (cmd, conhost (I think), many Cygwin and MSYS programs). For such programs, this would be especially helpful.
So, if I understand correctly, this wish is not about just adding “allow” option, but about adding “allow and inherit allow to child processes” option which is quite different. In other words, you want to be able to create the rule, that (in Safe mode) will allow not only execute untrusted executables but also allow them to run other executables as well.
Well, I doubt that such option will be implemented, since its functioning is not obvious and kinda dangerous.
However, maybe even with the current version it is possible to create the policy that will work like you want.
For example, you have the application runer.exe that creates random-named vbs scripts in folder [i]c:\workfolder[/i] and run them. Those scripts in ther turn run other apps.
First you need to create a rule for runer.exe with c:\workfolder*.vbs in the allow exceptions list ( in “run an executable” section).
Then you create other hips rule for c:\workfolder*.vbs and set . in its allow exception list.
Also it is a nice idea to add c:\workfolder*.vbs to the protected objects list and allow its modification by runner.exe (by adding c:\workfolder*.vbs to “protected files/folders” exclusions list of the runer.exe hips rule) . This will protect those scripts from malicious changes.
Dangerous? Every method you will find is insecure (because it is insecure by design).
But then again, my method is indirectly suggesting that executed applications will not run unrestricted in terms of virtualization/segregation methods.
The user should have the choice. Why would you be allowed to disable every module (AV,ASB,D+,FW)? Isn’t that insecure as well?
Totally agreed. User should have the choice. Probably I expressed my thoughts wrongly. Dangerous not because you have such option, but because its functioning isn’t clear. This allow rule will be the only one allow rule (among others) that is inherited by child processes. And that should be somehow clearly stated when a user activates this option (somehow distinct from other allow rules). So, as you can see, I’m not against this wish, I am for its more detailed explanation in the UI.
And by the way, will the policy stated above work? If so, than a user already has some alternative.
I would like to thank everyone who has voted on this particular enhancement. As this wish has accumulated the necessary 15 points I have added this to the tracker for consideration by the devs. However, do note that even though this wish will be considered by the devs, it does not necessarily mean that it will be implemented. I will update this topic when I have any additional information.