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?
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
- modified at runtime with
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
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
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.
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.