Configure Linux to allow network activity based on binary?

Question

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?

Answer 1

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

Answer 2

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.

Conclusion

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.