How OpenBSD and Linux Mitigate Security Bugs

At Open Source Summit in Prague, Giovanni Bechis will discuss tools that improve software security by blocking unwanted syscalls.

Bechis is CEO and DevOps engineer at SNB s.r.l., a hosting provider and develops web applications based on Linux/BSD operating systems that is mainly focused on integrating web applications with legacy softwares. In this interview, Bechis explained more about his approach to software security.

Linux.com: What’s the focus of your talk?

The talk will focus on two similar solutions implemented in Linux and OpenBSD kernels, designed to prevent a program from calling syscalls they should not call to improve security of software.

In both kernels (Linux and OpenBSD), unwanted syscalls can be blocked and the offending program terminated, but there are some differences between Linux and OpenBSD’s solution of the problem.

During my talk, I will analyze the differences between two similar techniques that are present in Linux and OpenBSD kernels that are used to mitigate security bugs (that could be used to attack  software and escalate privileges on a machine).

Linux.com: Who should attend?

The scope of the talk is to teach developers how they can develop better and more secure software by adding just few lines to their code. The target audience is mainly developers interested in securing applications.

Linux.com: Can you please explain both solutions and what problems they actually solve?

The main problem that these solutions are trying to solve is that bugs can be exploited to let software do something that it is not designed to do. For example, with some crafty parameters or some crafty TCP/IP packet, it could be possible to let a program read a password file; it should not read or delete some files that it should not delete.

This is more dangerous if the program is running as root instead of a dedicated user because it will have access to all files of the machine if proper security techniques have not been applied.

With these solutions, if a program tries to do something it is not designed for, it will be killed by the kernel and the execution of the program will terminate.

To do that, the source code of the program should be modified with some “more or less” simple lines of code that will “describe” which system calls the program is allowed to request.

A system call is the programmatic way in which a computer program requests a service from the kernel of the operating system it is executed on, by allowing only a subset of the system calls we can mitigate security bugs.

Last year, for example, memcached, a popular application designed to speed up dynamic web applications, has suffered by a remote code execution bug that could be exploited to remotely run arbitrary code on the targeted system, thereby compromising the many websites that expose Memcache servers accessible over the Internet.

With a solution like seccomp(2) or pledge(2), a similar bug could be mitigated, the remote code would never be executed, and the memcached process would be terminated.

Linux.com: What’s the main difference between the two solutions?

The main difference (at least the more visible one without viewing under the hood) between Linux and OpenBSD implementation is that, with Linux seccomp(2), you can instruct the program in a very granular way, and you can create very complex policies, while on OpenBSD pledge(2) permitted syscalls have been grouped so policies will be simpler.

On the other hand, using seccomp(2) in Linux could be difficult, while OpenBSD pledge(2) is far easier to use.

On both operating systems, every program should be studied in order to decide which system call the application could use, and there are some facilities that can help understand how a program is operating, what it is doing, and which operations it should be allowed to do.