subdo

File List
Login

Files of check-in [908af0ed00] in the top-level directory


subdo

Separates privileges for each program.

Presentation summary slide (uv/summary.pdf, discussed later in this page) rendered as an image file

(introduction video)

Each program gets its own user, and communication is through doas, sudo, or ssh. An example subdo permissions graph, built from the file subdo.dot

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.

It presently supports these user management backends,

and these package formats/managers.

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

Things subdo uses

Known vulnerabilities

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.

SSH communication

Virtual machines

Desired features

Porting

Design