1. What version of CIS, or Comodo Firewall, are you currently using:
7.0.313494.4115
2. What actually happened or you saw:
When CIS encounters an unknown file, it’s moved to unrecognized file list. There, the user can move said file to trusted, check against online database, submit to Comodo or delete from list.
3. What you wanted to happen or see:
When CIS encounters an unknown file, it’s moved to unrecognized file list. Default ruleset is created for this file (depending on your autosandbox level), “edit rules” button is present at the bottom menu. The user can change some of the rules, while leaving other intact, can also load default rulesets (partially limited, limited, etc). All options from section 2 remains of course.
4. Why you think it is desirable:
This will give more control over unrecognized files to advanced users, while keeping it simple for average users.
5. Any other information:
An example of what this could look like is given below:
- Go to D+ logs and discover that cis is blocking game.exe from using svchost.exe.
- You go to unrecognized files list, locate game.exe and press edit rules.
- You’re presented with a window similar to HIPS application rules editing window, where rules are set according to “partially limited” limitation.
- You look for “Protected com interfaces” and switch it to allow, or add svchost.exe as exception, and save the settings.
- CIS now asks you what you would like your new BB level to be used just for this application, or to be “saved as new ruleset”, which you could then rename something like ‘Partially Limited for svchost’.
- After this the game that runs as ‘partially unlimited for svchost’, but svchost.exe works fine.
- From this point on, assuming you selected to option to “save as new ruleset” there is also an added BB level, called ‘Partially Limited for svchost’, which can be selected for the BB.
Is this wish similar enough to what you are looking for? If so, it has already been moved to verified and forwarded to the devs.
Thanks.
No, not really.
My suggestion doesn’t really “change” current autosandboxing system, it’s just adds to it.
From what I understood from Sanya’s suggestion, CIS will ask what to do with each unknown file, and that leads to more prompts, which I thought Comodo tries to avoid if possible.
Since many files can work just fine under “partially limited” (default) sandbox, I ask \ wish that we’re given an option to “fine tune” the rules, so to speak, for programs that don’t work correctly under “partially limited”, yet you don’t want to place in trusted list.
Okay, I think I misunderstood. Do you essentially want Partially Limited, Limited, Restricted, etc… to be editable in the same ways as HIPS rulesets are? In addition, you also want the ability to create new user-defined BB restriction levels. Is that correct?
Umm… yes you can say that, on file to file basis.
I basically ask that:
-
When a file is placed in unrecognized files list, a HIPS-type ruleset should be created based on limitations of currently active autosandbox \ bb level, for that file.
-
Add an ability to edit said ruleset if necessary, like allowing a file access to some parts (restricted by current bb level), but maintaining other restrictions.
2a) If user wants (s)he can “load” a ruleset that corresponds to certain BB level. Like for example if you want some files to behave as in “limited” sandbox, but the other files as “partially limited” (default)
- All of this should be done from “unrecognized files” list, so that you don’t have to jump several menus. Basically add “edit rules” button there.
And again it’s on per file basis and is optional, since many files work fine under default sandbox \ bb level.
Perhaps I am misunderstanding, but couldn’t this essentially be accomplished if there was an option included to allow the user the choice as to which BB level each file should be run at. In addition, the user could be able to create customized BB levels of their own.
Thus, combining these two would allow the user to create customized levels, which they could selectively apply to each file (either through the BB popup, or manually through the Unrecognized Files List). Am I correct that this would satisfy this wish, or am I mistaken?
Thanks.
But wouldn’t that mean that user will have to answer a question \ popup about what sandbox level he wants a file to run for every unrecognized file?
Maybe I’m misunderstanding you as well…
Let me give you a step by step example of how my suggestion would work.
Let’s say you have a game (game.exe) that uses internet (for highscore uploading, for example), and isn’t recognized by CIS. CIS is in default settings, plus my suggestion.
Now you start the game, CIS says file game.exe isn’t recognized and is sandboxed under partially limited. The game runs fine, but can’t upload scores to the leaderboard, and there is no firewall alert.
So, you actions:
- Go to D+ logs and discover that cis is blocking game.exe from using svchost.exe.
- You go to unrecognized files list, locate game.exe and press edit rules.
- You’re presented with a window similar to HIPS application rules editing window, where rules are set according to “partially limited” limitation.
- You look for “Protected com interfaces” and switch it to allow, or add svchost.exe as exception, and save the settings.
- You have a game that runs as partially unlimited, but can use svchost.exe.
Now can you please provide a step by step example of your (Sanya’s) idea?
Okay, now I better understand what you are suggesting. I like it. However, I think that if they are going to go far enough to make it possible to edit it for an individual app, they may as well make the following possible:
- Go to D+ logs and discover that cis is blocking game.exe from using svchost.exe.
- You go to unrecognized files list, locate game.exe and press edit rules.
- You’re presented with a window similar to HIPS application rules editing window, where rules are set according to “partially limited” limitation.
- You look for “Protected com interfaces” and switch it to allow, or add svchost.exe as exception, and save the settings.
- CIS now asks you what you would like your new BB level to be saved as (You could choose something like ‘Partially Limited for svchost’)
- After this the game that runs as ‘partially unlimited for svchost’, but svchost.exe works fine.
- From this point on there is also an added BB level, called ‘Partially Limited for svchost’, which can be selected for the BB.
What do you think of that suggestion?
Thanks.
Yes, as long as steps 5 and 7 are optional, that can be useful.
In step 5 CIS could ask you, if you want to save changed rules as new ruleset, or there could be a button like “save as ruleset” or something. Would be useful if you have several programs with same problem (in this case unable to access internet), you could edit rules for one, save as custom ruleset and just copy from ruleset (ability present in current HIPS application rules edit window) to other programs.
As for step 7, I don’t think it would be wise to set custom rulesets as global BB level because it can lower overall security…unless special situations…
So they just need to drag \ connect \ combine HIPS application rules section to unrecognized files section of CIS with pre-creating said HIPS rules for unknown files based on global BB level (similar to “create rules for safe applications” in firewall settings…in a way)
Okay, what do you think about the following steps:
- Go to D+ logs and discover that cis is blocking game.exe from using svchost.exe.
- You go to unrecognized files list, locate game.exe and press edit rules.
- You’re presented with a window similar to HIPS application rules editing window, where rules are set according to “partially limited” limitation.
- You look for “Protected com interfaces” and switch it to allow, or add svchost.exe as exception, and save the settings.
- CIS now asks you what you would like your new BB level to be used just for this application, or to be “saved as new ruleset”, which you could then rename something like ‘Partially Limited for svchost’.
- After this the game that runs as ‘partially unlimited for svchost’, but svchost.exe works fine.
- From this point on, assuming you selected to option to “save as new ruleset” there is also an added BB level, called ‘Partially Limited for svchost’, which can be selected for the BB.
Yeah, looks good.
For step 5 I’m not sure witch is better: to have CIS ask you if you want to save changes as custom ruleset or have a button “save as ruleset” somewhere in the editing window.
That’s a minor detail though, the main idea is to be able to edit limitations of each unknown file from unrecognized files window, without disabling sandbox \ bb.
P.S. This is a bit offtopic, but I wonder where can I see ideas \ wishes rejected by comodo themselves (not the users) ?
I have edited the first post, and the title. Please let me know what you think.
As for your question about wishes rejected by Comodo, so far there are none. That is because this system is still new. Over time wishes will be rejected. After being rejected what I will do is reply to that post and explain why it was rejected (regardless of whether I agree with the reasons or not). I will then move it to the rejected section. For you, the only way to find these would be to go through the rejected wishes and check the last two or three replies. That should give you an idea of why it was moved there. Sorry, there is no simpler way.
Thanks.
Looks good.
You can add a poll and move it to waiting area.
I hope this will go through, this will greatly increase flexibility of autosandbox part of CIS, while leaving avarage users as is.
Thank you for submitting this Wish Request. I have now added a poll and 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.
Thanks again.
I would like to thank everyone who has voted on this particular enhancement. As it has already garnered 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.
Thank you.