OpenBSD Handbook

    • Part I. Install & Configure
      • Introduction
      • Installing OpenBSD
      • The X Window System
      • Networking
      • System Configuration
      • OpenBSD Basics
      • Managing Software: Packages and Ports
    • Part II. Daily Operations
      • Graphical Environments
      • Multimedia
      • Printing
      • Linux Compatibility
      • Windows Compatibility
      • Games
    • Part III. System Administration
      • Security
      • Virtualization
      • Storage and File Systems
      • Updating and Upgrading
      • Localization
      • The OpenBSD Boot Process
    • Part IV. Networking & Daemons
      • Services
        • Database
          • MariaDB
          • PostgreSQL
          • Redis
          • memcached
        • Directory
          • YP (NIS)
          • LDAP
        • File
          • NFS
          • Samba
        • FTP Services
          • ftpd
          • ProFTPD
          • vsftpd
          • TFTP
        • Mail
          • Dovecot
          • smtpd
          • Postfix
          • Exim
          • Rspamd
        • Name
          • Named
          • Unbound
          • NSD
        • Networking
          • OpenBGPD
          • rtadvd
          • DHCP
          • slaacd
        • Web
          • Apache
          • nginx
          • httpd
          • relayd
        • Logging
          • syslogd
        • Monitoring
          • SNMP
        • Remote Access
          • Audit OpenSSH
          • sshd
        • File Synchronization
          • rsync
        • Messaging
          • RabbitMQ
        • Time
          • NTP
      • PF
        • pfctl cheat sheet
        • PF Anchors
        • PF Filter Rules
        • PF Forwarding
        • PF Lists and Macros
        • PF Load Balancing
        • PF Logging
        • PF NAT
        • PF Options
        • PF Policies
        • PF Shortcuts
        • PF Tables
      • Advanced Networking
        • High Availability and State Replication
        • Multi-WAN and Policy-Based Routing
        • VPN and Cryptographic Tunneling
        • Classic and Lightweight Tunnels
        • IPv6 at Scale
        • QoS and Traffic Shaping
        • MPLS and Label Distribution
        • Network Services at Scale
        • Virtualization and Host Networking
        • Large-Scale L2 and L3 Design
        • Telemetry, Logging, and Flow Export
        • Hardening and Operational Safety
        • Reference Architectures
        • Troubleshooting Playbooks
      • Serial Communication
    • Part V. Miscellaneous
      • Virtualization Cheat Sheet
      • OpenBSD Cheatsheet
      • Howto
        • Install Z shell (zsh)
        • Set Up WordPress
        • Build a Simple Router and Firewall
      • OpenBSD for Linux Users
      • OpenBSD for FreeBSD Users
      • OpenBSD for macOS Users
    • Package Search
      Security
      • Doas
      • Sudo
      • Su

      Security

      Since regular users are not allowed to run so called “administrative commands”, there is a need to elevate their privileges. Ideally, this is done in a simple way and without endangering the security of the system. There are 3 regular ways for a regular user to elevate their privileges. Two of them are considered good practise and the last one is considered bad practise in general but might be nessecary in specific use cases.

      Doas #

      The doas tool is the OpenBSD implementation of the well known sudo tool. It allows regular users to run commands as another user but in practise will mostly be used to run commands as the root user.

      The configuraton for doas can be found in /etc/doas.conf but that file doesn’t exist by default. There is an example config file in /etc/examples/. Copy the file from /etc/examples/ to /etc/:

      cp /etc/examples/doas.conf /etc/

      The default config will allow all users in the group “wheel” to execute commands as the root user. One of the things people familiar with sudo may notice is that doas, by default, will ask for a password every time a command is executed, no matter how much time has expire since the last invocation of the command. This behaviour can be altered by modifying the doas.conf file and adding the persist option. Please see below for an example.

      # Allow wheel by default
      permit persist keepenv :wheel
      

      By default, the doas command will assume the target user to be the root user but an alternative user can be defined using the -u option. Another default is that all commands invoked with the doas command will be logged to the /var/log/secure log file.

      In case the doas utility is configured correctly, the following command should open the passwd file.

      doas vipw
      

      If the doas config file is not configured correctly, or if the user is not in the correct group, the following message is displayed.

      vipw: the passwd file is busy or you cannot lock.
      

      Make sure the user is in the right group by executing the id command as the user or by checking the /etc/group file getent group | grep wheel.

      More configuration examples can be found via man doas.conf.

      Sudo #

      The sudo utility is probably the best know privilege elevation utility in the UNIX world. It’s included in most or all modern UNIX or UNIX-like systems. It is also available on OpenBSD but is not installed by default since the doas utility is available.

      In order to use sudo, it first needs to be installed.

      pkg_add sudo

      By default, only the root user is allowed to use the sudo command. Following the doas example configuration above, the users in the group wheel can be allowed by uncommenting the last line of the section below in /etc/sudoers:

      The visudo command checks the syntax of the /etc/sudoers file before writing it and helps prevent misconfiguration. It’s the recommended way to edit the sudoers file instead of opening it directly with an editor.
      # Uncomment to allow people in group wheel to run all commands
      # and set environment variables.
      # %wheel        ALL=(ALL) SETENV: ALL
      

      In order to check if sudo is correcly configured, run the following command

      sudo -l

      In the output there should be a line like:

      (ALL) SETENV: ALL
      

      In case the user is not in the group wheel, the output will be the following:

      Sorry, user USERNAME may not run sudo on HOSTNAME.
      

      This can be fixed by adding the user to the group “wheel”

      usermod -G wheel USER

      Su #

      The final way to elevate a users privileges is to become the root user. Generally, this is considered a bad practise as, amongst others, the user needs the root password in order to become root.

      The only users allowed to become root are the ones in the “wheel” group. Once a user is in that group, the following command can be used to become root:

      su -

      Report a bug
      • Doas
      • Sudo
      • Su