Firewall add-on applications hardly achieve the level of usability of a tcp/ip-stack that has it integrated from the start.
Yet this is sort of interesting, Amiga programs generally use either bsdsocket.library or TCP: device for the traffic. So you could not for instance let the TCP: device always have access, as that would be a security hole the size of Saturn. Which I think, leads to having a dual approach, the firewall program should intercept access both at the low- and high-level. Essentially a hack, I believe. Patching dos.library apart from having some extra wild stuff at bsdsocket.library, possibly even core parts of the operating system. Suppose every OpenLibrary() at it would be checked against the lists, and if it matches the "offender" list, it would be silently refused the library pointer with a zero returned, instead. In some cases, the program would just be silent about it as well, but likely it would give an error message, possibly in a requester. This would happen every time it was not granted access.
What of the logical device then? Mufs only works on filesystem devices I'm sure, so no help from there. Perhaps the ARexx scripts and whatnot, that require TCP: would have to be left out.
Detecting the programs is also tricky. As the task name more often than not depends on where a program was started from, it would be necessary to use wildcards. So how is the poor watchdog going to know the difference between yam, yam:yam and lyam? Somehow checking the starting/current directory of each program that tries to open a socket, would be very weird in my opinion. You would be tied to a certain installation path. So at the very least, the user would be swamped with configuration issues.
I haven't actually done these things personally but this is how I perceive it. May be too huge a task for one or two hobbyists to get done.
Also read the last paragraph from
