Praetor, thats a good idea... in theory. But what if the child is even remotely smart, and simply renames the process? Such as this?
Good question -- it doesnt matter. Each process is handled independently (welcome to my world of firewall security). What this means, in english is when you change the filename/process-descriptor block that counts as a new process and the firewall says "OMG do you want to allow this application to run" (this is before the application even bothers trying to connect) ... of course you can even override this and default it to block anything new. And naturally this extends to different versions of the same program... so some real examples:
Suppose we have some programs
[1] C:\UTIl\CPUz\CPUz.exe (version 1.28)
[2] C:\UTIl\CPUz\CPUzRenamed.exe (version 1.28)
[3] C:\UTIL\CPUz\CPUz.exe (version 1.31)
[4] D:\CPUz\CPUz.exe (version 1.28)
Our current rules are as follows:
- program [1] is allowed to run
- program [4] is allowed to run and is allowed outbound access to the internet
This is what happens
[1] ... we double click and it runs no problem, if there is a need to connect to internet then the firewall says "omg this program is connecting from IP

ort to IP

ort using PROTOCOL in this DIRECTION, do you want to allow?" (we can default allow/block as well)
[2] ... some kid thought he was clever, the firewall notes this is a different program and says piss off (or we can have it ask us)
[3] ... this is a different program, firewall says piss off
[4] ... this program is allowed and thus can start freely, we've also allowed it outbound access to the net (but no inbound)
So yeah, it's not as easy to circumvent as it might appear without examples
Edit: the process lockdown goes further technically and you can define if you want a given program to be able to launch another program etc (a good way to deal with installers that try and silently install stuff)
@Geoff: did you really think i'd post something with such a big hole in it?
