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.
       
 (HTM) OpenBSD presentation about Unveil (BSDCan2019)
 (HTM) 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.
       
 (HTM) 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.
       
 (HTM) 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.
       
 (HTM) OpenBSD man pages online
 (HTM) 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.
       
 (HTM) Meltdown: one of the first security issue related to speculative execution in the CPU
       
       ## 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.
       
 (HTM) 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.
       
 (HTM) 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. 
       
 (HTM) « Mitigations and other real security features » by Theo De Raadt
 (HTM) OpenBSD innovations
 (HTM) OpenBSD events, often including slides or videos