It will show up as coming from firefox. When you run the command with the browser already running, it tells the original browser process to open the tab, then exits. The restricted process never does any network I/O by itself.

and try to block it.

You would have to know in advance all the domains the malicious program would access and block them, so realistically, no, at least not pre-emptively.

I'm not sure if this specifically is used, as it requires the browser to be already running. If not, the new browser instance is spawned as a child process to the malicious program, inheriting all of its restrictions.

In general, if you don't have permission to do something yourself, it's common to find someone who does and ask nicely (or maliciously) for them to do it on your behalf. This is called the confused deputy problem.

See also the security problems related to the setuid bit.

For example, sudo should be owned by root and have the setuid bit set. This means that every time you run sudo, it runs with the permissions of the root user. Now, sudo is typically strict about checking if you're really allowed to run commands with elevated permissions, and only executes the command you give if it's sure that ypu're allowed to.

But, suppose that you could replace the call to the password cheking function with a call to exec. Now, your password is interpreted as a file path and the file it points to is run with the sudo process' peemissions (root). Authentication has now been bypassed.

It was a made-up example, but I hope that it illustrates the point.

In the real world, buffer overflows can potentially write user-supplied data over something important, essentially giving you a chance of achieving something similar. (Incidentally, the Rust programming language practically eliminates this class of memory-related bugs.)