I don’t know what you mean. Any access controls implemented on kernel-mode code is pointless because kernel-mode code can bypass any form of security you try to impose on it.
No, KProcessHacker does not have any access controls. However you can compile it so that only admins (or at least programs running as admin) can use it. This won’t be a problem until Process Hacker becomes more popular ;).
Thanks for clarifying this point as it was indeed something I misunderstood.
Guess so. 
Anyway I took the effort to add \Device\KprocessHacker to My protected files :-TU
I just want to make a few corrections. cmdagent.exe is in effect, the policy component of CIS. As an example, try suspending cmdagent and then performing an action which would cause a prompt. The offending program will simply hang until you resume cmdagent because the CIS driver is attempting to contact cmdagent. cmdagent would contact cfp which would prompt the user. When the user responds, cfp would send the result back to cmdagent which would tell the CIS driver to allow/deny the action (or cfp directly contacts the CIS driver, I don’t know).
Just because cmdagent is an important part of CIS doesn’t mean that it’s protected any differently to how cfp is protected. That means you can terminate cmdagent with Process Hacker, even though it’s not a good idea because it’s almost impossible to start it again.
If cfp is killed you won’t get any alerts, not “reduced” alerts. cmdagent can’t prompt you because it’s running in session 0 instead of the console session (on Vista and higher).
After allowing PH to terminate cmdagnet did you try to restart COMODO Internet Security Helper Service (cmdagent) form the service list finding that impossible? ???
Anyway is indeed a bad idea to install PH for the sole purpose of tampering CIS. Users concerned by the kernel driver based terminations should use CIS to prevent the installation of such drivers rather than being concerned at the effects of having such drivers installed.
I terminated cmdagent and nothing bad happened (although I couldn’t start it again because of CIS’ protections). However, I then terminated cfp and started it again. It was stuck on “COMODO Internet Security is being initialized” and all actions with no rules were getting blocked :).
Like mentioned, drivers run in kernel-mode and have very high privileges, and can do anything they want. Once the driver has been loaded, there’s no way for CIS, or any other software, to protect itself from being terminated. You can however prevent the driver from being loaded, by making CIS monitor Device Driver Installations. This option is found under Monitor Settings (Defense+ → Advanced → Defense+ Settings → Monitor Settings). Another option is to use a Limited User Account. A Limited User Account is not allowed to load drivers.
So indeed you didn’t try to restart cmdagent which is possible regardless of the termination/loading order of cfp.exe 
Who are you saying this to? ;D
:-[ I didn’t realise that it is possible to restart cmdagent (I just tried)! Cool.
It just proves that sometimes theorizing isn’t enough 
To him/her who listens (or more correct, reads it).
This is the best “explanation” to be honest. The program and driver can run without any restrictions ONCE INSTALLED. D+ prompts you if you want to install the driver or not, therefore it can not do any harm what so ever unless you allow it to be able to run without restrictions.
D+ does its job with warning you with what you want to do when it tries to install the driver and there is where the “prevention” part kicks in. If you do allow it to install the driver you kinda doomed yourself as no program is foolproof, if all comes down to the person behind the screen.
Absolutely. More generally, it’s impossible to stop kernel-code from doing whatever it wants, so the best way to stop it is by preventing it from loading. This topic is rather old though…
Hmm, didnt see the post date was in May <.<
Seems it has been quiet low activity on this board as this was the top subject cough
even with Post Date filtering “downwards” with newest topics first…
Yes, people freak out when they see CIS processes getting killed.
Freak out and uninstall xD Also, when killing Cmdagent and cfp.exe you only need to take Defense+ to Disabled and you have all rights to exit it really <.< Did it alot when figuring out how the hell to get around GameGuard Games -.-
bottom line. I think regardless of how cis is configured there should be an alert that plainly states if something is trying to terminate any cis process regardless of whether it’s a safe application or if something is being done that could potentially kill a cis process even if alerts are supersede. malware can use safe apps to do it’s dirty work.
This is a pretty old topic…
If you’ve read this thread, it’s not a case of the application being a safe app. It’s the fact that the app is using a kernel level process to terminate CIS. Kernel level code can do anything it wants.
my point is that comodo needs to find a way to control to the user when something tries to kill cis period. I just used an example of safe apps being used because it’s a no brainer for cis to do it for malicious apps. yes the is using kernel level code can do whatever it wants. my point is cis needs to find a way to monitor the kernel and if something tries to kill cis using kernel level code then cis needs to say hey user, so and so is trying to kill me. do you want me to allow it to kill me. I don’t know the level of possibility for this to be a reality but it doesn’t mean that it’s still not an issue just because it may or may not be possible to implement
very interesting topic. I learned something new.
Is it possible for cis to build a kind of protection or no?