Sometimes we have to run an application that we do not trust, but we are afraid that it might look at or delete our personal data, since even though Linux systems are less prone to malware, they are not completely immune. Maybe you want to access a shady-sounding website. Or perhaps you need to access your bank account, or any other site dealing with sensitive private information. You might trust the website, but do not trust the add-ons or extensions installed in your browser.
In each of the above cases, sandboxing is useful. The idea is to restrict the non-trusted application in an isolated container -a sandbox– so that it does not have access to our personal data, or the other applications on our system. While there is a software called Sandboxie that does what we need, it is only available for Microsoft Windows. But Linux users need not worry, since we have Firejail for the job.
So without further ado, let us see how to set up Firejail on a Linux system and use it to sandbox apps in Linux:
Many people believe that browser security is difficult. I created this guide as an overview of Firejail sandboxing technology. The goal is to show you that security can be simple and fun.
The video guide is structured as a hacking session. The victim is running a sandboxed browser. An imaginary zero-day exploit gives the attacker control of the sandbox in the form of a remote shell. Let’s see what damage we can do. And maybe, reconfigure the sandbox so the victim can survive the aftermath of such an attack.
Take a look at your Desktop and/or interface. Be it MATE (desktop/laptop), Phosh (Pinephone/Librem), or KDE. We use several buttons/shortcuts to programs everyday. Some of these need the internet. Some do not.
Have you minimized access to programs who do not need the internet? Did you know some programs secretly “call home” and share data/your IP address with 3rd parties (sometimes sold)? The most ideal setup is one which is restricted wherever possible, but not up to the point where your setup becomes unusable.
Here we are going to use a Hot Off the Press News example to demonstrate how to allow networking only to those programs requiring it (such as web browsers, encrypted messengers, etc). Other programs like VLC Media player, GIMP (image manipulation), and Libre Office do NOT need ANY networking for full functionality. So why do we allow it? Because this is default behavior, we accept it. We are going to change that today.
This is a small excerpt from a ISC Security Series webinar titled “Securing Bind 9 with AppArmor and Firejail”. ISC is a non-profit organization that develops several widely used open source software packages such as BIND 9, ISC DHCP, and Kea DHCP.
There are many reasons to choose Sailfish OS over other mobile operating systems, but at Jolla we never forget that privacy and control are things our customers care deeply about. That’s because we care deeply about them too, and that’s why we’ve introduced Firejail app sandboxing into Sailfish OS 4 Koli.
When you first run an application, the Firejail app sandbox will make clear which permissions an application needs in order to run. A Firejailed app is prevented from accessing any of the functionality not granted on the list. Why is that important? We know Jolla developers are trustworthy, but there’s always the possibility someone will release an app containing rogue code, or with an accidental vulnerability for an attacker to exploit. If this happens, it’s reassuring to know the app is confined to minimise any harm it can do.
Some users may be concerned that this increasing security and privacy may impact the control you have over your own device. Rest assured this is not the case. With developer mode activated you’re still free to execute apps outside the sandbox if you prefer. In contrast to other mobile operating systems we want all Sailfish OS users to have full control of their devices, while ensuring malicious hackers don’t.
In the latest release many of the Jolla apps are sandboxed by default, but we’re not yet applying this to third party apps. Sandboxing prevents the use of boosters and QML pre-compilation, with a performance penalty we’re working to avoid. Restricting its use initially to a selected set of apps will give us the chance to iron out some of these kinks before we activate it for third party apps in a future release.