How can I tell Defense+ to ignore all the (executable) files in certain directory, or all the (executable) files, created by certain other executable (compiler).
.NET and ASP.NET creates bunch of temporary dlls, which Comodo puts for “my review” which o messes up the proper functioning of ASP.NET…
Hi Grandpa - what happens that indicates that asp.net is messed up? The Pending Files list is just a list of the new files created on your hard drive. The reason for the Purge function is to allow you to identify and remove from the list any files that are temporary files that no longer exist (or have been moved). As far as I know, the files are not moved or otherwise altered by being listed on My Pending Files. Purging the files is the first step in tracking down the files that have been added to your system. Personally, I would like to see an option to allow the list to clear itself at intervals. The process is Purge (removes files that no longer exist); Lookup (identifies files that are safe or known); Submit (sends unknown files to Comodo for review) and finally, Remove (clears the files from the list). I do this fairly mechanically now, but I guess that it does give you the chance to look at potential trouble sources.
When ASP.NET is running (aspx web pages) it often creates dlls on the fly - cache etc.
I had to shutdown Comodo (and by the way - setting Defense+ to “disabled” or even shutting down CPF did not work - I had to kill cmdagent too) to get ASP.NET working without problems again.
From reading the help it seems that the pending files are considered “not safe” under few of the Defense+ modes. What does that mean? It won’t allow what?
Anyways, Defense+ definitely seems to get in the way. There has to be a way to exclude certain folders and/or programs from this process.
You can define the directory that ASP.NET uses as safe in My Own Safe Files (Defense+>Common Tasks>My Own Safe Files). Click Add and choose Browse Files. On the browse window, locate My Computer and double-click to open sub-directories until you locate the ASP.NET directory. With the directory selected, click the arrow to transfer it onto the Selected list. If there are sub-directories, you might want to tick the “Include files from subfolders too” box. Click Apply and Apply. This might slow down the loading of CFP at bootup - I seem to recall a report that large folders added to this list slowed bootup. I am surprised that it should be necessary to do this if CFP’s Defense+ is disabled. I saw a reference to uninstalling Defense+, but I don’t know how that would work - the only way I know of would uninstall CFP entirely.
I don’t know if this would help. I think this adds to your Safe Files the files currently in that path, but not the files that will be created in the future there. Which is of course safer, but sure can get in the way.
But try anyway. If it doesn’t help, try temporarily disabling not the Security Level, but Defense+ > Advanced > Image Execution Control Settings > Image Execution Control Level.
I suspect that there is more to this. The problem is likely not due to .dll’s being created, but either they are being used by rundll.exe or there are also .exe files created that need privileges for some protected action. I have had .dll’s and .exe’s created on my system in the C:\documents and settings.…\Local Settings\Temp folder without any problem. My guess is that the actions that the files created by ASP.NET attempt are restricted by Defense+. There may be other factors at work - for instance, ASP.NET executables would not have the privileges to run executables that are created (it may be troublesome to discover the processes that would be launching the created files, but if they are discoverable, they could be given privileges to run files using wildcards). I am sure that there are other possibilities that I have not thought of.
I guess you need training mode at least to look at the D+ rules to understand what D+ permission are needed an what paths are used.
BTW I never attempted this but maybe it is possible to create a rule like * and put it as first rule so you could try to create a rule for C:\test* and set the privileges there
That sounds promising, if a bit risky. You could put a path like C:\Documents and Settings.…\Local Settings\Temp*.dll (or *.exe) in the application path in the Add dialog in the Defense+>Advanced>Computer Security Policy page. You would have to pick a file in that directory (any one would do) and then right-click the path entry in the Application Path box of the Edit dialog (“Application System Activity Control” window) and select Edit and type the wildcard.extension into the path box. You could then define privileges for it. The downside of this is that ANY program or dll that appears in that directory has those privileges.
The same kind of thing could be done for the ASP.NET executables that invoke these programs (if that turns out to be necessary) using the Modify button for “Run an executable” of the Access Rights page for that program’s Edit dialog.
I suppose that could be tightened up by specifying asp.net as the parent process of *.dll
d+ > advanced > computer security policy, find the asp.net process(es), highlight then press edit. Select ‘process permissions’, and then in the execution permissions row, press modify. In the allowed tab, click add > browse. In the text bar at the top of the file explorer, type the full path to the temp folder, followed by *.dll (C:\documents and settings.…\temp*.dll
If I understand the way cpf3 works, you should be alerted about any other process launching *.dll.
Is that the case?