An mdo(1) introduction

This post takes a quick look at a recent addition to FreeBSD: mdo(1). The mdo(1) utility allows a given user or group member to execute a command as another user. In that sense it is similar to the doas(1) program from OpenBSD and at the same time mdo(1) has noticeable differences when compared with doas(1) – the most notable being covered in the next section.

Background

Traditionally programs that let one user execute a command as another user required a setuid binary (also known as a "suid binary") that is owned by root. When a "suid binary" is executed by another user, it runs with the effective user id of the file's owner and the real user id of the user executing the program.

In the case of tools like doas(1) and sudo(8), the file's owner would be root and that allows the program to change the effective and real user id through a system call, and finally go onto call one of the exec family of functions to execute a new program.

But mdo(1) is different. It does not depend on a "suid binary" and instead it depends on a mac policy (implemented as a kernel module) that allows a program transition from one (effective|real) user id to another (effective|real) user id through the setcred(2) system call.

This difference is what really sets mdo(1) apart from other tools in the same space, and why I set aside a section in this post dedicated to it. The rest of the post will focus on how to use mdo(1).

Policy

The mdo(1) utility depends on the mdo policy – and the policy must be loaded into the kernel before we can use mdo(1) from the command line. The mac(4) man page provides some larger context about the Mandatory Access Control (mac) framework. The following option is useful if you want to quickly try mdo(1) without rebooting the system:

# Enable mac_do(4) policy
root@freebsd# kldload mac_do

Otherwise the policy can be loaded into kernel early in the boot process by updating /boot/loader.conf. This change will make the policy persistent across reboots. It is also possible to compile the mdo policy into the kernel but we won't cover that here:

# /boot/loader.conf
mac_do_load="YES"

Rules

A rule defines which user or group members can execute a command as another user. Rules are stored as a list separated by a semi-colon and can be retrieved or modified via sysctl(8) under the security.mac.do.rules node.

A rule consists of two parts: a left-hand side and a right-hand side, separated by the : character. The left-hand side describes the user id or group id that is allowed to run a command as another user, and the right-hand side describes the target user id.

If we were to draw a comparison with doas(1) then security.mac.do.rules would be roughly equivalent to the doas.conf configuration file but it is neither a direct equivalent nor as feature-rich as doas.conf. It is also important to note that the rules belong to the mdo policy that the mdo(1) utility happens to use. Let's take a look at some examples:

# Permit alice to run commands as bob
root@freebsd# sysctl security.mac.do.rules=uid=$(id -u alice):uid=$(id -u bob)

# Permit members of the beatles to run commands as bob
root@freebsd# gid=$(getent group beatles | awk -F: '{print $3}')
root@freebsd# sysctl security.mac.do.rules=gid=${gid}:uid=$(id -u bob)

# Permit alice to run commands as root
root@freebsd# sysctl security.mac.do.rules=uid=$(id -u alice):uid=0

# Permit alice to run commands as any user
root@freebsd# sysctl security.mac.do.rules=uid=$(id -u alice):any

mdo

With rules and everything else in place, the user alice can run commands as bob through the mdo(1) utility:

# Launch weechat as 'bob'
alice@freebsd$ mdo -u bob /usr/local/bin/weechat