On Windows, rules can be added to the firewall to allow/deny network traffic based on which binary is sending/receiving the data. Can this be done on a Linux box, and if not, why not? Is it a bad idea per se, or is it just not something that the makers of Linux thought of?

  • Very hard to implement, it should rely on a checksum + name to identify connections. Then the network stack has to be modified to intercept any call (or use k/ptrace) to send(). Then the system must interact with the user (many different DE/WM, no clean interface guarantied) and then change (permanently?) the ruleset of the packet filter to authorize accepted connections. It's more complex than that actually but this should let you understand why there is no such thing on UNIX yet (as I know). BTW, the program can still call another legitimate program to reach out, and users make mistakes... – Aki May 30 '12 at 11:39
  • @Aki Windows has it; I guess Microsoft are just more determined to make a secure firewall, eh? :-) Surely iptables could be upgraded to allow this. – Jez May 30 '12 at 12:10
  • they only have one Desktop Environment, which makes it easy to integrate notification from the kernel. By design in Unix systems userland is strictly separated from the kernel. System calls can be used to ask the kernel specific tasks (access to IO, etc). One could imagine this kind of improvement on some distribution of Linux, but I doubt this would get accepted upstream. It's not just iptable to upgrade and maintain. A firewall doesn't run application, so no need to deny/accept anything interactively, a firewall should be a headless (CLI) and at the network border. – Aki May 30 '12 at 14:10
  • 1
    Moreover, the 'firewall' on windows, is more an antivirus/malware/etc than a firewall (packet filter). – Aki May 30 '12 at 14:10
  • Why would it need to do anything "interactively"? These binary rules could be set up in advance like all other firewall rules. – Jez May 30 '12 at 14:12

This can be done via SELinux. There are examples here.

  • 1
    Too tired now to go Google'ing, but I've seen iptables modules that can identify binaries, UID/GID. I'm of to bed now. – jippie May 30 '12 at 21:16

Is it a bad idea per se

It is a bad idea to discriminate on process image and expect to gain some sort of security from that, if you do not protect these processes.

Executable image whitelist

For example, say you only allow wget and curl and block all other network accesses. You might think that this security setting allows arbitrary HTTP/s, FTP, etc. requests, but not sending arbitrary data via TCP, or starting arbitrary TCP servers sockets, or using UDP. But because wget and curl are ordinary dynamically linked non Set-something programs, they can be :

  • started with arbitrary LD_LIBRARY_PATH, started with a modified dynamic loader, any tricks ltrace does
  • traced, as strace does
  • modified at runtime with ptrace(2)

As strace/ltrace do, you can manipulate any process unless it runs with a different user or group ID, or with capabilities you do not have.

If you want to associate any specific rights to specific images (f.ex. /usr/bin/wget), you should protect processes launched from interference as strongly as set-something processes are protected. Unless this is properly done, you mostly have security theatre and protection from non-adaptive threats (which is perhaps all that you need, but you should explicitly say so).

Of course you can only protect a process if it is designed to be protected from its user, and most programs are not. In particular most browsers allow the installation of arbitrary extensions which are allowed to access the network, all from the browser process, with the process's rights, sometimes with no specific security restriction whatsoever, so you would also have to prevent installation of extensions in whitelisted programs.

Executable image blacklist

OTOH, you may use the firewall to prevent specific daemons from accessing the network, or opening any unexpected connections.

To enforce these restriction, you need at least to :

  • prevent restricted processes from starting unrestricted processes
  • prevent restricted processes from interfering (as above) with unrestricted processes

Starting arbitrary executable images is done with exec, and the kernel should either prevent restricted processes from launching unrestricted images, or tag the new process so that it is restricted as its parents.

But an executable image can also be indirectly done by adding cron/anacron/at/batch jobs, so restricted process should be prevented from editing job lists, possibly by making sure that they do not own the jobs lists files, and have no write access to them. Any user might also procmailrc, and run arbitrary commands whenever mail is received, etc.

These restriction have to be integrated OS-wide, not just kernel-wide. This goes against Unix tradition where any process with a user-ID is expected allowed to start any process with its user-ID, and the cron/at/maildrop DAEMONs/programs have integrated this assumption. You have to look for any daemon that starts programs on user behalf, and blacklist these features.

See the pattern? Enforcement of a blacklist of specific processes preventing specific system calls (network access) leads to more backlists not only on other system calls (exec family) but also on other OS components. Any secure, Unix-reasonable (that is: whose behaviour is fully expected under a traditional Unix system) DAEMON can introduce a security loophole.


The "kernel" of the kernel (the micro-kernel part of a monolithic kernel) must know about process rights, not just a specific subsystem (network subsystem, file-system, etc.). The "right to network" is an essential property of a process, just like user-IDs or the capability set.

Or you can say that all you need is a protection from non-adaptive threats: you are afraid of standard worms/viruses, not targeted attacks.

This is a general problem in any retrofitted security feature.

Personal conclusion

This is why I think that capabilities is fundamentally a terribly broken idea. Unix is based on user-ID: if you want security isolation, use a different UID. This resource is cheap.

  • 1
    I wouldn't envisage this as being used to implement a blacklist (if you don't trust the binary, why is it even on your system?) BTW, what on earth is a "set-something program"? – Jez May 31 '12 at 10:38
  • 1
    @Jez "I wouldn't envisage this as being used to implement a blacklist (if you don't trust the binary, why is it even on your system?)" why do you need a firewall if you trust your system? "BTW, what on earth is a "set-something program"?" ever heard of set-UID, set-GID, set-cap? – curiousguy May 31 '12 at 20:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.