SUBDO(7) Miscellaneous Information Manual SUBDO(7)

NAME

subdoseparates privileges for different program, with users, groups and doas

DESCRIPTION

subdo manages packages such that your main user(8) (the "super") has the right to run the program through doas(1), sudo(1), or ssh(1) as a user dedicated to the particular program (the "sub"). The super and the sub are appended to each others' primary group(8) memberships so that you can configure filesystem access appropriately.
Here are some reasons you might want to do this.

DESIGN

While logged in primarily to one general-purpose account, we log in to other accounts that are each dedicated to particular programs. We call the primary general-purpose account a “super” and the other accounts “subs”.
This is accomplished by modifying the following files/configurations.
doas.conf, sudoers, and authorized_keys
For each sub command that is exposed a the super, we write a line in doas.conf to allow the super to run the sub command. For each super user, we write lines to allow the super to change file ownership with subown(8), supown(8), subgrp(8), and supgrp(8).
wrapper
For each sub command that is exposed a the super, we write a file that configures and runs the sub command with doas.
users and groups
We create sub users and groups, of course. The sub's primary group is set to the super's primary group, and the super is appended to the group with the same name as the sub. Groups are set up this way mainly so you can change file ownership and modes to configure filesystem access appropriately for a particular sub. Ordinarily, only root can change a file's owner or group, but the aforementioned subown(8), supown(8), subgrp(8), and supgrp(8) commands, run through doas(1) or sudo(1), allow the super to change file ownership.
home directories
Each sub's home directory is owned by the sub user and is group-owned by the sub group.
Each combination of a super and a sub corresponds to a user named “${super}_${sub}”. In the very common situation where only one person uses a computer, there is only one super, specified as a group with the same name as the user, where the group happens to contain only one user.

PERMISSIONS

subdo expects a certain permissions configuration.

NON-ROOT ACCESS

I suggest that you configure your system so non-root users can use subdo_add(8) and subdo_delete(8). Below are configurations for doas(1), sudo(1), and ssh(1).

doas

Put something like this in /etc/doas.conf.
permit nopass setenv { SUDO_USER=tlevine PATH=/usr/local/sbin } tlevine cmd subdo_add
permit nopass setenv { SUDO_USER=tlevine PATH=/usr/local/sbin } tlevine cmd subdo_delete
This allows user “tlevine” to run “doas subdo_add” and “doas subdo_delete”. Then you can install subs from “tlevine”, with doas(1).
$ doas subdo_add r

sudo

Put something like this in /etc/sudoers.
tlevine ALL = (root) NOPASSWD: /usr/local/sbin/subdo_add
tlevine ALL = (root) NOPASSWD: /usr/local/sbin/subdo_delete
This allows user “tlevine” to run “sudo subdo_add” and “sudo subdo_delete”. Then you can install subs from “tlevine”, with sudo(1).
$ sudo subdo_add r

ssh

See subdo-shell(1).

PATH

When subs are installed, wrapper executables are placed in their normal locations except rooted at /subdo/$SUPER. If your operating system distinguishes between base packages in /usr and contributed packages in /usr/local, I recommend including /subdo/$SUPER/usr/local/bin in your PATH and not including /usr/local in your PATH. For sh(1) you could put this in your shell rc.
export PATH="${PATH}:/subdo/$SUPER"
With tcsh(1) you could put this in your shell rc.
set path = ($path /subdo/$SUPER/usr/local/bin)
If your operating system conflates base and contributed packages, putting both kinds in in /usr, I suggest including both /subdo/$SUPER/usr/bin and /usr but giving priority to the subdo location. In sh(1) it would be this:
export PATH="/subdo/$SUPER/usr/bin:${PATH}"
And with tcsh(1) it is this:
set path = (/subdo/$SUPER/usr/bin $path)

HOME DIRECTORY ACCESS

If a user needs its secondary group privileges in order to access its own home directory, su(1) will consider the home directory not to exist and will thus use / as the home directory.
# ls -lhd /home/tlevine/ 
drwxr-x---  99 tlevine  tlevine   8.0K Mar 12 20:12 /home/tlevine/ 
# useradd -d /home/tlevine/blah -G tlevine -m blah 
# su -l blah 
No home directory /home/tlevine/blah! 
Logging in with home = "/".
On a reading of kdump(1) output, I got the sense that this happens because su(1) attempts to chdir(2) to the home target user's home directory before setting the secondary groups.
An earlier version of subdo created sub home directories as ~${SUDO_USER-$LOGNAME}/.subdo/home/$package rather than the current ${BASE_DIR}/${SUDO_USER-$LOGNAME}_${package}. This was originally why I set each sub's primary group to the super's group.

X

X applications run in the way subdo runs them do not have direct access to the GPU. This was reported by Dillon (2015), and it is obvious to me when I play videos through a subdo-ed application. I don't know why it works this way.

SEE ALSO

Manuals

subdo components
subdo_add(8), subdo_delete(8), subdo(5), subdo-shell(1)
privilige separation
doas(1), doas.conf(5), sudo(1), sudoers(5), ssh(1), sshd(8), useradd(8), usermod(8), groupadd(8), setuid(2)
package managers
pkg_add(8), package(5), apt-get(8), dpkg(1)

Other

How to Run a More Secure Browser, DragonFly BSD, https://www.dragonflybsd.org/docs/docs/handbook/RunSecureBrowser/, 2018, Isolate browsers as separate users communicating over ssh.
Matthew Dillon, Running firefox a bit more safely - HOWTO, dragonfly-users, https://marc.info/?l=dragonfly-users&m=143931438715045&w=2, 2015, Isolate browsers as separate users communicating over ssh.
Stuart Henderson, Re: Packages security updates in -stable, openbsd-misc, https://marc.info/?l=openbsd-misc&m=150516561419649&w=2, 2016, Isolate irssi with communication over doas in order to install a newer version than is available in ports.
February 28, 2018 OpenBSD 6.2