Use `firejail` to restrict a script’s access to specific syscalls

Understanding Syscall Restrictions in Linux with `firejail`

In the realm of Linux, security is a top priority, and one of the innovative tools for enhancing security is firejail. This sandboxing tool limits the scope of program operations using Linux namespaces and seccomp-bpf, which stands for Secure Computing Mode with Berkeley Packet Filter. Primarily, it's used to restrict the system calls that a process can execute. In this blog, we will explore how firejail can be used to restrict a script's access to specific syscalls.

What is `firejail`?

Q: Can you explain what firejail is and why it's useful? A: Firejail is a sandboxing tool that uses Linux namespaces and seccomp technology to restrict the running environment of untrusted applications. It helps in reducing the risk of security breaches by confining programs to limited areas and restricting their capabilities to the essential minimum. This is particularly useful in preventing exploits that might utilize the vulnerabilities of programs to extend control over the whole system.

Restricting Syscalls with `firejail`

Q: How does firejail restrict syscalls? A: Firejail can employ seccomp filters to restrict the syscalls a process can use. When a restricted syscall is attempted, the process is either killed or the syscall fails with EPERM (operation not permitted), effectively reducing the potential actions a process can maliciously perform.

Example and Explanation

To give a practical example, let’s consider a simple scenario where you want a script to only execute benign activities but restrict potentially harmful syscalls like reboot() or setuid().

Q: Could you provide a simple example? A: Certainly! Suppose you have a script myscript.sh that you want to run in a restricted environment. You can create a firejail profile to specify the allowed syscalls. Here's a basic example of how to do this.

Let's first write a simple script:

#!/bin/bash
echo "Attempting to list home directory contents"
ls ~

Now, create a firejail profile:

Create a profile file, /etc/firejail/myscript.profile:

include /etc/firejail/disable-common.inc
include /etc/firejail/disable-programs.inc
seccomp.keep getdents64,openat,close,read,write,fstat

This profile keeps a minimal set of syscalls to run ls (to list filesystem contents) and blocks other non-specified syscalls.

Running the script with firejail:

firejail --profile=/etc/firejail/myscript.profile bash myscript.sh

Demonstration Script

To better demonstrate firejail in action, let’s expand our script and include a syscall that should fail under the restrictions:

#!/bin/bash
echo "Attempting to list home directory contents:"
ls ~

echo "Attempting to change user ID:"
id -u # This normally works
setuid 1000 # This should fail if blocked by firejail
id -u # This should not change if the previous command failed

Run it with the same firejail settings to see setuid blocked by your syscall filters.

Conclusion

Using firejail to restrict syscalls is a powerful method of sandboxing scripts and applications in Linux, adding an extra layer of security by minimizing the potential attack surface. While the setup can seem a bit detailed, it's ultimately about protecting crucial system resources from unauthorized access and potential misuse. By leveraging firejail, users and administrators can effectively enforce the principle of least privilege, ensuring applications operate within their necessary boundaries without compromising overall system integrity. This capacity for control makes firejail an invaluable tool in the arsenal of Linux security measures.

Understanding Syscall Restrictions in Linux with firejail

What is firejail?

Restricting Syscalls with firejail