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.
After years of using Linux on my main computer, I got really tired of seeing how many low-quality Linux antivirus programs were floating around the internet. While Linux is much more secure than other operating systems, I kept finding vulnerabilities that I was struggling to patch.
One of the reasons for this is that there simply aren’t very many antivirus scanners for Linux. While malware is still an issue, Linux users don’t face the same risks as PC and Mac users, so we need to utilize other cybersecurity tools to harden our devices.
I spent a long time finding the best free Linux cybersecurity tools on the internet. After testing 29 different programs, I’ve come up with some rock-solid programs to help bulk up security on my Linux machine.
- ClamAV: Open-source freeware antivirus scanner with a GUI.
- Sophos: Free for one user, scan and remove malware, command line only.
- Firetools: Sandboxing software prevents malicious web scripts with a GUI.
- Rootkit Hunter: Behavior-based rootkit scanning, command line only.
- Qubes: A distro designed to keep your computer as secure as possible.
more… Also in French and Romanian
Firejail is a program that can prepare sandboxes to run other programs. This is an efficient way to keep a software isolated from the rest of the system without need of changing its source code, it works for network, graphical or daemons programs.
You may want to sandbox programs you run in order to protect your system for any issue that could happen within the program (security breach, code mistake, unknown errors), like Steam once had a “rm -fr /” issue, using a sandbox that would have partially saved a part of the user directory. Web browsers are major tools nowadays and yet they have access to the whole system and have many security issues discovered and exploited in the wild, running it in a sandbox can reduce the data a hacker could exfiltrate from the computer. Of course, sandboxing comes with an usability tradeoff because if you only allow access to the ~/Downloads/ directory, you need to put files in this directory if you want to upload them, and you can only download files into this directory and then move them later where you really want to keep your files.
For running applications sandboxed in Linux, Firetools is a good utility to do so. Sandboxing is essentially restricting applications in their own space and thereby limiting their reach to the overall system. This is a security layer to prevent any malicious programs to have full access to the system.
Firetools is a graphical front-end for the command-line sandboxing tool Firejail.
Mainly Tor and DNS because that’s what I’ve been doing lately.
Before we start, let’s get into the habit of cleaning up some files when we shut down the computer. For this you need a systemd unit file (see Appendix 1) and a simple script (see Apendix 2). Copy the unit file in
/etc/systemd/system directory, and the script in /etc. The contents of the script is as follows:
rm -fr /home/netblue/.cache
.cache directory is the place where people find copies of all the webpages you visited, torrent trackers you connected to, and all that emails you thought you deleted – all 3 GB of them!
After that, take a look at
/etc/machine-id. This is a world-readable file containing a huge random number:
$ cat /etc/machine-id
Sort of a serial number, it is used to uniquely identify Linux computers. You definitely don’t want it on your home network. But since it is required by systemd, generate a new one on shutdown. Actually, there is another copy of this file in
/var/lib/dbus/machine-id, so you have to deal with both of them:
Security is one of the most important and overlooked aspects of modern computing. We tend to let the default security configurations do the work, or on Windows, we simply install some anti-virus and be done with it. However, applications are increasingly privileged and we find ourselves running programs that could represent a security vulnerability to our systems and, more importantly, to our information.
Sandboxing allows us to limit what each application can see and what it can access, as well as what it can do in your system. Clearly not all applications need sandboxing, for example, your text editor probably isn’t a security vulnerability. Regardless, applications like browsers are the source of many security vulnerabilities, even though they already do some sandboxing themselves.
In this post, we will use a very simple sandboxing method using Firejail and AppArmor on Linux.
If you use Firejail to run Signal Desktop in a sandboxed environment on Linux, you will likely be surprised by the fact that a new application instance is opened every time you execute the firejail signal-desktop command. Attempting to open a second instance of Signal Deskop should simply cause the existing one to be activated instead, but Firejail breaks this default behavior.
On top of that, if you use the –use-tray-icon parameter to have Signal Desktop place an icon on your desktop environment’s icon tray, the icon may not only be displayed incorrectly, but each new opened instance will place an additional (incorrect) icon there as well, making things even worse.
Addressing these issues is fortunately easy. All you need to do is create a Firejail profile file named signal-desktop.profile inside the ~/.config/firejail/ directory containing the following:
This page lists the changes I make to a vanilla install of Arch Linux for security hardening, as well as some other changes I find useful. While Arch is my target platform, most of the changes will work on any Linux system that’s reasonably up to date.
I typically favor security over performance. You may also see suggestions merely to make something more useful or shave precious seconds off a wait time. It’s not a one-size-fits-all setup, but hopefully certain pieces of it will be useful.
I chose Arch for a few reasons:
- The install size: The base install is relatively minimal compared to a “prebuilt” distro like Fedora or Mint. This lets me focus on adding just what I want, rather than constantly trying to strip out things I don’t need.
- The kernel: A common misconception about the Linux kernel is that it’s secure, or that one can go a long time without worrying about kernel security updates. Neither of these are even remotely true. New versions of Linux are released almost every week, often containing security fixes buried among the many other changes. These releases typically don’t make explicit mention of the changes having security implications. As a result, many “stable” or “LTS” distributions don’t know which commits should be backported to their old kernels, or even that something needs backporting at all. If the problem has a public CVE assigned to it, maybe your distro will pick it up. Maybe not. Even if a CVE exists, at least in the case of Ubuntu and Debian especially, users are often left with kernels full of known holes for months at a time. Arch doesn’t play the backporting game, instead opting to provide the newest stable releases shortly after they come out.
- The Arch Build System: Having enjoyed the ports system of FreeBSD and OpenBSD for a long time, the ABS has been a pleasure to use. It makes building/rebuilding packages easy. It makes updating packages easy. It shows how things are actually built and with what options. This BSD-borrowed concept makes interacting with the package system simple and intuitive.
Now on to how I set things up.