Introduction
Introduction Statistics Contact Development Disclaimer Help
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
You are viewing proxied material from dataswamp.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.