I Blocked Dangerous Linux Syscalls with Seccomp

Added: 2026-05-14

[00:00:00]This Linux machine is vulnerable to copyfail.

[00:00:04]But if we run the exploit, nothing happens.

[00:00:07]Dropping to root didn't succeed.

[00:00:10]We are still using a non-privileged user.

[00:00:15]In this video, I will show you how seccomp can prevent dangerous exploits from working. Seccomp stands for secure computing.

[00:00:23]It filters system calls and decide whether to allow it or not. Rather than reading this whole man page, let's go and see some practical examples.

[00:00:31]Seccomp works on syscalls. Whenever we execute a program or binary, it calls different functions in the background.

[00:00:38]Those are the system calls. To see them, we can use the s trace command.

[00:00:46]Here are the typical system calls you will see.

[00:00:49]This output is often hard to parse. So, if we want to see a better view, we can run s trace like this.

[00:00:58]Here is a summary output about the different syscalls invoked when running ls command. As an example, execve is a common system call that runs a binary on a particular path. The easiest way to demonstrate how seccomp filters syscalls is through firejail.

[00:01:15]We already have a previous video about firejail, but for the sake of others, let's do a quick recap. Firejail is a sandboxing tool. If we run it, we will be dropped inside a restricted environment.

[00:01:28]Inside this, we cannot run privileged commands.

[00:01:32]Most binaries are also missing.

[00:01:36]Now, let's find out how seccomp works through firejail.

[00:01:40]Let's say we want a restricted shell that will prevent running the execve syscall. We would run it like this.

[00:01:51]The seccomp drop parameter is added, specifying the syscall we want to remove. If there are multiple syscalls we want to target, we can just separate them by commas.

[00:02:03]Once we are inside, we won't be able to run commands that rely on that syscall.

[00:02:09]It is also important to note that not all commands rely on execve.

[00:02:14]Take a look at this one.

[00:02:16]Why did it work? The reason is that PWD command is a shell built-in. That means the program code is already in memory and it no longer needs to invoke execve to call a separate binary on disk.

[00:02:28]Let's have another example.

[00:02:32]We have here a file that is owned by my current user, meaning I can delete it or modify it in any way I want. If we want to block file deletions even for a file you owned, we can do that by dropping the unlinkat syscall.

[00:02:55]Now, if we try to remove it, it says operation not permitted. This can be a neat strategy if you want to maintain the immutability of a file. For example, if you have a critical configuration that you want to defend against attackers trying to delete it, this can be a good way to do it. We can see the underlying syscall being blocked in action if we use strace. But by default, firejail prevents the use of debuggers.

[00:03:16]What we can do is to rerun firejail, but this time we add the allow debuggers flag.

[00:03:28]If we run again rm with strace, we would see the actual syscall being denied.

[00:03:37]The error returned can also be customized. For instance, we can make it appear as no such file or directory rather than permission denied.

[00:03:45]We just put a colon followed by the official error code. In this case, the official error code for no such file or directory is error no entry.

[00:03:56]Let's try to delete the file.

[00:04:00]There is no error, but the file is still there.

[00:04:02]This confirms the seccomp filter took effect. Just to see it again under the hood, let's run it with strace.

[00:04:09]This line clearly shows us that the unlinkat syscall didn't succeed followed by error no entry.

[00:04:15]We can also use seccomp programmatically using the libseccomp library. To demonstrate this, let's try blocking the copy fail exploit.

[00:04:23]If your system is vulnerable to copy fail, an attacker will be able to run a small shellcode to drop to a root shell.

[00:04:37]So, here's a way to prevent this attack.

[00:04:40]Using the libseccomp, we can create a small wrapper program like this.

[00:04:45]The copy fail vulnerability works by cloning a process while sending data to AF_ALG socket type. So, the goal of this program is to prevent those unusual cloning of processes. At the top, we need to import the seccomp header file.

[00:04:58]Next to that is to define the type of clones we want to block.

[00:05:02]Inside the main function, we need to initialize the seccomp context.

[00:05:06]Then we also have a process control line here that tells the kernel not to let the process gain new privileges.

[00:05:12]The next two lines would be the actual seccomp filters we want.

[00:05:18]The first parameter is the seccomp context. Then next is the action we want, which is to deny it. Third is the syscall we want to block, which is clone. The clone syscall accepts a parameter, so we will tell seccomp to look into the first one.

[00:05:32]The last part is checking whether the clone VM bit is present when invoking the clone system call.

[00:05:37]The next line is similar, but here we also filter the clone 3 syscall, which is a modern version of clone. Once the seccomp filters are defined, we can now load the context.

[00:05:48]Lastly, we call bin bash through execve.

[00:05:51]What happens after this is that any process launched within this shell will automatically inherit the seccomp rules above.

[00:05:58]Let's compile the program. To do that, we use GCC but with the following flag.

[00:06:02]This tells the compiler to use the seccomp link library.

[00:06:07]Once that is compiled, we can run that to drop us to a restricted shell.

[00:06:14]We are currently still running as some user account. To confirm that the seccomp filters worked, we shouldn't be dropping to root when we execute the copy fail exploit.

[00:06:27]As we expected, we remained on our current user, effectively blocking the exploit. So, seccomp is an alternative way of stopping different attacks. The important thing is you know what system calls to block. Else, you might break legitimate programs from running.

[00:06:41]Aside from firejail and using as a program wrapper, seccomp is also used in different services such as containers and systemd. Using seccomp to block attacks can be a more precise solution.

[00:06:52]The downside is that it can get complicated if you are working on a large amount of system calls. You need to do thorough testing to make sure normal programs will continue to work without issues. I hope you learned something today. If you find my content valuable, please support me by liking this video and subscribing to my channel. See you on the next one.