The short answer is: no by design, and here's an example of what would need to happen if it was possible:
- netcat opens socket on port X by calling the relative syscall (such as
listen
)
- kernel traps syscall, executes network code (in this case, opens port)
- kernel talks to the relative
iptables
module (assuming it's available and loaded) and opens a hole in the firewall to let traffic go to the newly opened port.
This would open up a potential security hole: how would the kernel know that the program is legitimate, i.e. is not a trojan that wants to open a remote shell? Here are a few answers:
- Because the program is whitelisted somewhere; but this would shift the security into another set of issues:
- how do you know that the program hasn't been compromised? You could use something like tripwire, but this opens up another security question: how can you guarantee that the master list is not compromised?
- how do you deal with updates? E.g. version Z of
ssh
can punch holes through the firewall; your system self-updates, now the hash of ssh
changed, and you are locked out.
- Because the user launching it belongs to a privileged group: how do you deal with SUID binaries? Take a look at the
ping
program permissions for example.
Another can of worms^W^W^W set of potential issues would be the interface between iptables (at kernel level) and the syscalls; every minor change in iptables would require a potential rewrite of the code underlying the syscalls, introducing bugs, etc.
In a nutshell, you are describing the problem that application firewalls face (think about Windows or Mac firewalls). It's do-able, but it's not simple.
At a networking level you might want to take a look at UPnP whose function was to allow services to punch holes through a gateway's firewall. With the obvious security consequences.
Or you could use a script instead :)