Application firewall coming to Linux devices near you

By on 28 Oct 2020

Category: Tech matters

Tags: , , , ,


Blog home

How many of you have seen LittleSnitch on macOS, and how many times have you wished it worked on Linux? Well, I certainly have!

The Linux Application Firewall (LAF) Project plans to create a personal host-based firewall for desktop Linux users that will let users selectively block or allow programs network access to specific domains.

Why would you want this? 

Most phones have a similar function, allowing you to grant or deny permissions to apps. This is a privacy issue, whereby programs can transmit personal information or application usage back to creators or third-party companies. It is not possible to assess all applications on your computer before installing them; even if that were possible you’d have to audit each one of the updates.

For example, you install a calculator program. This program should not need network access. So you can prevent any requests from reaching the network. Later you decide to use a feature that converts currency; it may initiate a connection to get the latest exchange rate. You can allow it once to access only one site.

Example workflow showing app access rules and how they are dealt with by associated firewalls.
Figure 1 — In this example, each application on the computer has its own set of access rules. We can see that App0, the media player, can access, while Apps 2 and 3 are denied any network access.

Can’t SELinux can do this?

You might be thinking “But I can do this with SELinux or AppArmor”, and you’d be right. However, not everyone understands what these words mean.

The LAF Project aims to create a simple and intuitive application that can be used by non-IT people without having to read the manual. Everyone has a mobile phone, and so they are used to the idea of allowing programs access to resources. Underneath this clean simple interface, it becomes more interesting.

Existing application firewalls have historically been implemented using:

  1. NetLink interface in the kernel, as a kernel module.
  2. The proc process information to map the PID to the network socket then the Netfilter queue.

Both of these methods have disadvantages. The kernel approach, while fast and efficient, requires untrusted code to be loaded into the kernel, which can reduce the robustness of the overall system. The procs method provides more assurances, since it runs in userspace. Yet, it incurs additional overhead and performs slower than the kernel method.

We are proposing to use an alternative approach, eBPF, which is a new(ish) feature of the Linux kernel that allows verified, secure, and lightweight VMs to be attached to a code path within the kernel, which it takes over. This allows extending the kernel without compromising the robustness of the whole system.

So basically we can combine the advantages of using a kernel module and a userland program, without the disadvantages.

What else are we working on?

As well as developing a host-based firewall using eBPF, we also plan to create a way to share your RuleSets with other users. It would be very annoying if every time you install a fresh distro, you have to recreate all your rules for each application. That is why we plan to let users subscribe to community RuleSets. This is still in the design stage.

This sounds good, can I use it?

Not yet! We’re currently in the design and prototype phase. So that means you can come and join us. Our source code (BSD) is hosted on Github

For more details on the project checkout our academic paper or watch the lightning talk we gave at TMA 2020.

Watch Peter Maynard present on the LAF Project at TMA 2020.

If you want to run a Linux Application Firewall right now, check out OpenSnitch and Douane.

Peter Maynard is Senior Researcher at Uncharted Security Research, UK.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.


Leave a Reply

Your email address will not be published. Required fields are marked *