Files in the top-level directory from the latest check-in

---

subdo

Separates privileges for each program.

(introduction video)

Each program gets its own user, and communication is through doas, sudo, or ssh.

subdo protects against many bugs and naive malwares, but it is easily defeated by a targeted attack.

Overview

Subdo installs packages such that your main user (the "super") has the right to run the program through doas, sudo, or ssh as a user dedicated to the particular program (the "sub"). The super and the sub are appended to each others' groups so that you can configure filesystem access appropriately.

Here are some reasons you might want to do this.

• A program has lots of dependencies, and you thus don't want to port it.
• You are using another package manager (Nix, npm, &c.) and want to keep its modules separate from the system modules.
• You do not trust the software to run properly, as it may contain bugs or malware.
• setuid, &c., is not appropriate, or you don't feel like using it.

It presently supports these user management backends,

• OpenBSD
• NetBSD
• FreeBSD
• GNU (shadow-utils)
• MacOS (Directory Service)

and these package formats/managers.

• openbsd
• netbsd
• freebsd
• slackware
• pacman
• yum
• rpm
• apt
• dpkg
• homebrew
• subdo(5)

A more detailed introduction is in subdo(7). There is a summary for use in presentations. The source code is in "summary.svg".

Example

Here is what changes when we add sxiv (an image viewer) with subdo.

If the super's name is "ibsen", the sub "ibsen_sxiv" is created with the "_subdo" primary group. This group provides no privileges at the moment; its purpose is to fill the required primary group slot.

The sub's home directory is "/home/ibsen". It is owned by ibsen_sxiv:ibsen, and it has 2770 permissions. The 2 at the beginning is for GNU compatibility, where Set-user-ID must be off and Set-group-ID must be on.

doas.conf starts like this. (sudoers or ~/.ssh/authorized_keys would be similar.)

ibsen$ cat /etc/doas.conf
permit nopass setenv { SUDO_USER=ibsen PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/sbin } ibsen cmd subdo_add
permit nopass setenv { SUDO_USER=ibsen PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/sbin } ibsen cmd subdo_delete

subdo_add creates a user.

ibsen$ doas subdo_add sxiv
ibsen$ tail -n1 /etc/passwd
==> /etc/passwd <==
ibsen_sxiv:*:1009:1001:sxiv for ibsen:/home/ibsen_sxiv:/bin/ksh

The sxiv executable wraps the system sxiv executable.

ibsen$ which sxiv
/home/ibsen/.subdo/usr/local/bin/sxiv
ibsen$ cat `which sxiv`
if test -n "$XAUTHORITY"; then chmod g=u "${XAUTHORITY}"; fi
doas -u 'ibsen_sxiv' '/usr/local/bin/sxiv' "${@}"

And it creates the associated doas (or sudo or ssh) rules.

ibsen$ cat /etc/doas.conf
permit nopass setenv { SUDO_USER=ibsen PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/sbin } ibsen cmd subdo_add
permit nopass setenv { SUDO_USER=ibsen PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/sbin } ibsen cmd subdo_delete
permit nopass setenv { SUDO_USER=ibsen } ibsen cmd /usr/local/libexec/subdo-chown
permit nopass setenv { PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin SUDO_USER=ibsen } ibsen as ibsen_sxiv cmd chmod
permit nopass keepenv setenv {XAUTHORITY LOGNAME=ibsen_sxiv HOME=/home/ibsen_sxiv } ibsen as ibsen_sxiv cmd /usr/local/bin/sxiv

Permissions

Since each sub is a Unix user, one can theoretically configure custom permissions for each sub. But I haven't figured out how to do that quickly, so I created permissions templates that can be set with the -e ("e" for extra permissions) option.

none

The sub can read and write its own directory. It can not read the directories of the super or of any other subs. It does not have network access. This is good for programs that you do not really trust, such as proprietary software or especially complex programs.

read (default)

The sub can read and write its own directory. It can read the directories of its super and of its super's subs; that is, it is a member of the super's group. It does not have network access. This is good for programs that need access to files from many different places, like rich text viewers.

net

The sub can read and write its own directory. It can not read the directories of the super or of any other subs. It does have network access. This is good for programs that mostly retrieve data from the network, rather than sending data to the network; examples include video downloaders, web browsers, and feed readers.

These templates adjust the sub's secondary groups and the configuration of pf or iptables.

I am considering adding heuristics specific to each package manager that will detect which is most appropriate. For example, a package in the net category should probably have net permissions, a project in the x11 category should probably have read permissions, and a contributed packages should probably have none permissions.

Names

When it is possible, subdo names sub users with the template _${super}_${packagename} or _${super}_${packagename}_${suffix}. If this would be too long or would clash with another user, the name is _subdo_u${identifier}, where identifier is a natural number.

Directory groups are always named _subdo_d${identifier}, where identifier is a natural number.

The mapping is

Installation

With make

Subdo is written in sh, and no compilation is required. Run this to unpack the subdo files into the appropriate directories under /usr/local.

make install

Or set the PREFIX to wherever you want to install it.

make install PREFIX=/usr/local

Or just run from the present directory.

Without make

Rather than downloading the full source repository, you can just download the distribution and extract it to the PREFIX, like this.

wget https://www.subdo.spacetechnology.net/uv/subdo-0.2.tar.gz
tar -xvz -f subdo-0.2.tar.gz -C ${PREFIX:-/usr/local}

Documentation

Subdo

• subdo(7)
• subdo_add(8)
• subdo_delete(8)
• subdo(5)
• subdo-shell(1)
• subdo-utils(8) (subgrp, subown, supgrp, supown)
• submod

Things subdo uses

• doas mastery
• doas(1)
• doas.conf(5)
• sudo
• sudo mastery
• sudo(8)
• sudoers(5)
• ssh(1)
• sshd(8)
• chmod(1)
• chown(8)

Known vulnerabilities

• doas and sudo communication mechanisms allow the sub user to retain control of the connecting pty after logout.
• X programs receive full control of the X server.
• Proper management of file owner and group can be annoying, and subdo is useful only if this is managed properly. In particular, most of the subdo protections are gone when super user sets the g+w file permission on a file belonging to the super group.

News and discussion

Two email lists are dedicated to subdo.

announce@subdo.spacetechnology.net

This list receives announcements of new versions and similarly significant news. Send mail to announce-subscribe@subdo.spacetechnology.net to subscribe.

discuss@subdo.spacetechnology.net

This is for any other discussion about subdo or about things that people interested in subdo may also be interested in. discuss-subscribe@subdo.spacetechnology.net to subscribe.

Ideas for future work

Avoid providing X server access.

• Copy the .Xauthority file rather than just giving access, so that you can restrict X access to certain subs.
• Detect whether a package uses X, and provide the .Xauthority only if necessary.
• Support Xnest communication, as I think it limits the client's access to just one section of the screen.
• Support VNC (or similar) communication. x11vnc with the -appshare flag could be nice. I have to figure out how to start a display per sub (Xvfb) and coordinate credentials (xauth).

SSH communication

• Interactive terminal programs don't work over ssh.
• The super user has full access to the sub users over ssh, rather than only having access to the executables of interest. This is usually fine, but it is different from how subdo configures doas and sudo. It would be easy to change this to match the doas/sudo situation.

Virtual machines

• Programs could be run in virtual machines. This changes the security considerations and also allows programs to run on other operating systems.

Desired features

• subdo_delete(8) could be improved; see the section "MISSING FEATURES".
• Contrary to the diagram above, subdo does not presently provide a convenient way for subs to communicate directly with each other.

Porting

• Experimental ports to several systems are available but untested. A warning is displayed for these systems.
• BusyBox (adduser, addgroup, deluser, delgroup) is not supported.
• Nix and emerge are not supported, though you can use them with custom subdo packages.
• Language-specific package managers (cabal, CPAN, CRAN, npm, pip, &c.) are not supported, though you can use them with custom subdo packages.
• Package for different package managers.

Design

• Human factors studies, especially in relation to how dangerous accidents can be avoided
• Security studies, such as adversarial testing

fossil clone https://subdo.spacetechnology.net/index.cgi subdo.fossil
wget https://subdo.spacetechnology.net/index.cgi/tarball/subdo.tar.gz