Title: What security does a default OpenBSD installation offer? | |
Author: Solène | |
Date: 14 February 2021 | |
Tags: openbsd70 openbsd security | |
Description: | |
# Introduction | |
In this text I will explain what makes OpenBSD secure by default when | |
you install it. Do not take this for a security analysis, but more | |
like a guide to help you understand what is done by OpenBSD to have a | |
secure environment. The purpose of this text is not to compare OpenBSD | |
to other OSes but to say what you can honestly expect from OpenBSD. | |
There are no security without a threat model, I always consider the | |
following cases: computer stolen at home by a thief, remote attacks | |
trying to exploit running services, exploit of user network clients. | |
# Security matters | |
Here is a list of features that I consider important for an operating | |
system security. While not every item from the following list are | |
strictly security features, they help having a strict system that | |
prevent software to misbehave and lead to unknown lands. | |
In my opinion security is not only about preventing remote attackers to | |
penetrate the system, but also to prevent programs or users to make the | |
system unusable. | |
## Pledge / unveil on userland | |
Pledge and unveil are often referred together although they can be used | |
independently. Pledge is a system call to restrict the permissions of | |
a program at some point in its source code, permissions can't be get | |
back once pledge has been called. Unveil is a system call that will | |
hide all the file system to the process except the paths that are | |
unveiled, it is possible to choose what permissions is allowed for the | |
paths. | |
Both a very effective and powerful surgical security tools but they | |
require some modification within the source code of a software, but | |
adding them requires a deep understanding on what the software is | |
doing. It is not always possible to forbid some system calls to a | |
software that requires to do almost anything, software designed with | |
privilege separation are better candidate for a proper pledge addition | |
because each part has its own job. | |
Some software in packages have received pledge or/and unveil support, | |
like Chromium or Firefox for the most well known. | |
OpenBSD presentation about Unveil (BSDCan2019) | |
OpenBSD presentation of Pledge and Unveil (BSDCan2018) | |
## Privilege separation | |
Most of the base system services used within OpenBSD runs using a | |
privilege separation pattern. Each part of a daemon is restricted to | |
the minimum required. A monolithic daemon would have to read/write | |
files, accept network connections, send messages to the log, in case of | |
security breach this allows a huge attack surface. By separating a | |
daemon in multiple parts, this allow a more fine grained control of | |
each workers, and using pledge and unveil system calls, it's possible | |
to set limits and highly reduce damage in case a worker is hacked. | |
## Clock synchronization | |
The daemon server is started by default to keep the clock synchronized | |
with time servers. A reference TLS server is used to challenge the | |
time servers. Keeping a computer with its clock synchronized is very | |
important. This is not really a security feature but you can't be | |
serious if you use a computer on a network without its time | |
synchronized. | |
## X display not as root | |
If you use the X, it drops privileges to _x11 user, it runs as | |
unpriviliged user instead of root, so in case of security issue this | |
prevent an attacker of accessing through a X11 bug more than what it | |
should. | |
## Resources limits | |
Default resources limits prevent a program to use too much memory, too | |
many open files or too many processes. While this can prevent some | |
huge programs to run with the default settings, this also helps finding | |
file descriptor leaks, prevent a fork bomb or a simple daemon to steal | |
all the memory leading to a crash. | |
## W^X | |
Most programs on OpenBSD aren't allowed to map memory with Write AND | |
Execution bit at the same time (W^X means Write XOR Exec), this can | |
prevents an interpreter to have its memory modified and executed. Some | |
packages aren't compliant to this and must be linked with a specific | |
library to bypass this restriction AND must be run from a partition | |
with the "wxallowed" option. | |
OpenBSD presentation « Kernel W^X Improvements In OpenBSD » | |
## Only one reliable randomness source | |
When your system requires a random number (and it does very often), | |
OpenBSD only provides one API to get a random number and they are | |
really random and can't be exhausted. A good random number generator | |
(RNG) is important for many cryptography requirements. | |
OpenBSD presentation about arc4random | |
## Accurate documentation | |
OpenBSD comes with a full documentation in its man pages. One should | |
be able to fully configure their system using only the man pages. Man | |
pages comes with CAVEATS or BUGS sections sometimes, it's important to | |
take care about those sections. It is better to read the documentation | |
and understand what has to be done in order to configure a system | |
instead of following an outdated and anonymous text available on the | |
Internet. | |
OpenBSD man pages online | |
EuroBSDcon 2018 about « Better documentation » | |
## IPSec and Wireguard out of the box | |
If you need to setup a VPN, you can use IPSec or Wireguard protocols | |
only using the base system, no package required. | |
## Memory safeties | |
OpenBSD has many safeties in regards to memory allocation and will | |
prevent use after free or unsafe memory usage very aggressively, this | |
is often a source of crash for some software from packages because | |
OpenBSD is very strict when you want to use the memory. This helps | |
finding memory misuses and will kill software misbehaving. | |
## Dedicated root account | |
When you install the system, a root account is created and its password | |
is asked, then you create a user that will be member of "wheel" group, | |
allowing it to switch user to root with root's password. doas (OpenBSD | |
base system equivalent of sudo) isn't configured by default. With the | |
default installation, the root password is required to do any root | |
action. I think a dedicated root account that can be logged in without | |
use of doas/sudo is better than a misconfigured doas/sudo allowing | |
every thing only if you know the user password. | |
## Small network attack surface | |
The only services that could be enabled at installation time listening | |
on the network are OpenSSH (asked at install time with default = yes), | |
dhclient (if you choose dhcp) and slaacd (if you use ipv6 in automatic | |
configuration). | |
## Encrypted swap | |
By default the OpenBSD swap is encrypted, meaning if programs memory | |
are sent to the swap nobody can recover it later. | |
## SMT disabled | |
Due to a heavy number of security breaches due to SMT (like | |
hyperthreading), the default installation disables the logical cores to | |
prevent any data leak. | |
Meltdown: one of the first security issue related to speculative execution in t… | |
## Micro and Webcam disabled | |
With the default installation, both microphone and webcam won't | |
actually record anything except blank video/sound until you set a | |
sysctl for this. | |
### Maintainability, release often, update often | |
The OpenBSD team publish a new release a new version every six months | |
and only last two releases receives security updates. This allows to | |
upgrade often but without pain, the upgrade process are small steps | |
twice a year that help keep the whole system up to date. This avoids | |
the fear of a huge upgrade and never doing it and I consider it a huge | |
security bonus. Most OpenBSD around are running latest versions. | |
### Signify chain of trust | |
Installer, archives and packages are signed using signify | |
public/private keys. OpenBSD installations comes with the release and | |
release n+1 keys to check the packages authenticity. A key is used | |
only six months and new keys are received in each new release allowing | |
to build a chain of trust. Signify keys are very small and are | |
published on many medias to double check when you need to bootstrap | |
this chain of trust. | |
Signify at BSDCan 2015 | |
## Packages | |
While most of the previous items were about the base system or the | |
kernel, the packages also have a few tricks to offer. | |
### Chroot by default when available | |
Most daemons that are available offering a chroot feature will have it | |
enabled by default. In some circumstances like for Nginx web server, | |
the software is patched by the OpenBSD team to enable chroot which is | |
not an official feature. | |
### Dedicated users for services | |
Most packages that provide a server also create a new dedicated user | |
for this exact service, allowing more privilege separation in case of | |
security issue in one service. | |
### Installing a service doesn't enable it | |
When you install a service, it doesn't get enabled by default. You | |
will have to configure the system to enable it at boot. There is a | |
single /etc/rc.conf.local file that can be used to see what is enabled | |
at boot, this can be manipulated using rcctl command. Forcing the user | |
to enable services makes the system administrator fully aware of what | |
is running on the system, which is good point for security. | |
rcctl man page | |
# Conclusion | |
Most of the previous "security features" should be considered good | |
practices and not features. Many good practices such as the following | |
could be easily implemented into most systems: Limiting users | |
resources, reducing daemon privileges, memory usage strictness, | |
providing a good documentation, start the least required services and | |
provide the user a clean default installation. | |
There are also many other features that have been added and which I | |
don't fully understand, and that I prefer letting the reader take | |
notice. | |
« Mitigations and other real security features » by Theo De Raadt | |
OpenBSD innovations | |
OpenBSD events, often including slides or videos |