0x21

Anonymous OpenSSH Account Creation

Sat, 27 Sep 2025 17:00:00 +0200

At this year’s MRMCD, I had the pleasure of giving a workshop on self-restricting software. In particular, I started with a primer on software privileges, followed by software self-hardening methods without the need for extended permissions. Regular readers of this weblog (just me, I guess) might know what to expect.

Since it was a workshop and not a presentation, there was an interactive part to it. To ease participation, I have decided to prepare everything on a remote machine and just let the participants ssh(1) into it.

This brought me to the problem of how to ease account creation as much as possible. To make things more spicy, there was not just one machine, but two, one running Debian GNU/Linux and the other OpenBSD. After procrastinating on this for a while, I came up with the following solution, only using the OpenSSH daemon sshd(8) and a short shell script. Feeling quite clever about this and even being asked about the “how” after the workshop, I came up with this post.

Skip the how, but actually what?

My aim was to provide an unauthorized and anonymous SSH access with user account creation on the fly. So any workshop participant would ssh(1) into the machine and end up with their own user. Additionally, participants should be able to reuse their user and not always end up with a new one.

In the end, my setup had only one requirement on the participant’s side: an SSH public key.

Stating the obvious, giving strangers an account on a machine might have some implications. However, I put my trust in strangers, gave them a relatively unrestricted user, and was not swatted (at the time of writing).

Demo Time

After this brief description, having a small demonstration might ease understanding.

The first login creates a new user account.

$ ssh mrmcd@mrmcd-test
** Only public key authentication is possible. If you are being asked for a
** password or receive an error such as
**   Permission denied (publickey,keyboard-interactive),
** please configure ssh(1) to send an identity file.
**
** If you have no idea what I am talking about, please execute
**   $ ssh-keygen
** once, use the suggested location and do NOT set a passphrase, and retry.

** Congratulations. You can ignore the banner above!

Welcome, stranger! Take a seat. You are now mute.

For future logins, you may use either your new name or this login service.

Treat each other with kindness and respect, including this machine. Do not cause
harm to others.
                       _
 _____ ___ _____ ___ _| |
|     |  _|     |  _| . |
|_|_|_|_| |_|_|_|___|___|

Self-Restricting Software
Workshop       2025-09-13

OpenBSD Machine.

mute@mrmmcd-test:~>

Any subsequent login will result in the same account.

$ ssh mrmcd@mrmcd-test
** Only public key authentication is possible. If you are being asked for a
** password or receive an error such as
**   Permission denied (publickey,keyboard-interactive),
** please configure ssh(1) to send an identity file.
**
** If you have no idea what I am talking about, please execute
**   $ ssh-keygen
** once, use the suggested location and do NOT set a passphrase, and retry.

** Congratulations. You can ignore the banner above!

Welcome back, mute.
                       _
 _____ ___ _____ ___ _| |
|     |  _|     |  _| . |
|_|_|_|_| |_|_|_|___|___|

Self-Restricting Software
Workshop       2025-09-13

OpenBSD Machine.

mute@mrmmcd-test:~>

Of course, the account can also be used directly by its name, without going through this logic.

$ ssh mute@mrmcd-test
                       _
 _____ ___ _____ ___ _| |
|     |  _|     |  _| . |
|_|_|_|_| |_|_|_|___|___|

Self-Restricting Software
Workshop       2025-09-13

OpenBSD Machine.

mute@mrmmcd-test:~>

Back to the how

While the complete workshop - including slides, demo code, and setup - is available on codeberg.org/oxzi/self-restricting-software, this section will briefly walk you through the relevant parts for anonymous account creation.

In a nutshell, sshd(8) is instructed to allow any public key for a certain user login, but does not provide a shell, and executes a certain script instead. This script checks if the current public key is stored in any user’s passwd(5) gecos field. If there is such a system user, a shell as this user will be invoked. Otherwise, a new user will be created, and this user will be used.

sshd_config

Relying on sshd(8), I found most tricks by simply reading sshd_config(5). Reading man pages is cool, trust me - give it a try.

This one started with a Match rule, allowing conditional configuration. While there is an option to match for an Invalid-User, this would not have allowed to actually create a session, and, on broader questions, many workshop participants would be creative enough to pick the same username. Thus, everything that follows goes into a Match User mrmcd rule, where mrmcd is the username.

Public key authentication usually works by placing the public key in some ~/.ssh/authorized_keys file. However, setting AuthorizedKeysCommand together with AuthorizedKeysCommandUser allows invoking a command which tells which keys are acceptable. This program is expected to return valid public keys in the same authorized_keys format as known from the ~/.ssh/authorized_keys file. To sweeten things up, sshd(8) allows command arguments from tokens, such as %t for “[t]he key or certificate type” or %k for “[t]he base64-encoded key or certificate for authentication”. These two tokens combined already result in the desired format. Now, only a command is missing to echo its argument.. such as echo(1).

Just to be sure, the normal file-based authentication was disabled by setting AuthorizedKeysFile to none.

To ensure that only the mentioned script is executed, a ForceCommand was set. This command cannot be overwritten by the user. As the Match User block deals with a normal system user and the script needs certain privileges to create and switch users, a doas(1) wrapper call was added. The doas.conf(5) should contain a line like this:

permit nopass keepenv mrmcd cmd /usr/local/sbin/demoauth

For Debian, the doas part should be replaced by sudo.

Setting ExposeAuthInfo to yes creates a temporary file with the currently used public keys, referenced in the SSH_USER_AUTH environment variable.

And this was all to do in the sshd_config(5), setting like five options. The result looks like this in the git or as follows.

Match User mrmcd
    AuthorizedKeysCommand /bin/echo %t %k       # /usr/bin/echo on Debian
    AuthorizedKeysCommandUser mrmcd
    AuthorizedKeysFile none

    ForceCommand doas /usr/local/sbin/demoauth  # sudo instead of doas on Debian
    ExposeAuthInfo yes

ForceCommand

After all the explanations above, the /usr/local/sbin/demoauth script itself is quite boring. I will paste it first and explain some details below.

#!/bin/sh

set -eu

# _sha256 creates a SHA256 hash for the 1st parameter.
_sha256() {
  if command -v sha256 > /dev/null 2>&1; then
    h="sha256"
  elif command -v sha256sum > /dev/null 2>&1; then
    h="sha256sum"
  else
    logger -s "Neither sha256 nor sha256sum is available"
    exit 2
  fi

  echo "$1" | "$h" | awk '{ print $1 }'
}

# _usergen creates a new user and either returns the username or exits.
# Expects the Public Key hash as the 1st parameter to be set as the comment.
_usergen() {
  # Try to find a not already used name..
  for _ in $(seq 1 10); do
    user="$(sort -R /usr/local/share/demoauth-dict | head -n 1)"
    if [ -z "$(getent passwd | awk -F : -v user="$user" '$1 == user { print }')" ]; then
      break
    fi
    user=""
  done

  # ..or fall back to a random string.
  if [ -z "$user" ]; then
    user="$(openssl rand -hex 12)"
  fi

  # There might be a race, but then it just fails :3
  if [ "$(uname -s)" = "OpenBSD" ]; then
    useradd -c "$1" -g =uid -m -L demouser "$user"
  else # Debian it is
    useradd -c "$1" -m -s /usr/bin/bash -U "$user"
  fi

  echo "$user"
}


if [ ! -s "$SSH_USER_AUTH" ]; then
  logger -s "SSH_USER_AUTH - $SSH_USER_AUTH - does either not exist or is empty"
  exit 2
fi

PUBKEY="$(awk '/^publickey ssh.*/ { print $2, $3 }' "$SSH_USER_AUTH")"
if [ -z "$PUBKEY" ]; then
  logger -s "SSH_USER_AUTH misses publickey entry"
  exit 2
fi
PUBKEY_ID="demoauth-$(_sha256 "$PUBKEY")"

logger "New connection from '$PUBKEY' with hash '$PUBKEY_ID'"

echo
echo "** Congratulations. You can ignore the banner above!"
echo

USER="$(getent passwd | awk -F : -v comment="$PUBKEY_ID" '$5 == comment { print $1 }')"
if [ -n "$USER" ]; then
  logger "Known Public Key resolves to $USER"

  echo "Welcome back, $USER."
else
  USER="$(_usergen "$PUBKEY_ID")"
  logger "Unknown Public Key, created $USER"

  mkdir -p "/home/${USER}/.ssh"
  chmod 0700 "/home/${USER}/.ssh"
  echo "$PUBKEY" > "/home/${USER}/.ssh/authorized_keys"
  chmod 0600 "/home/${USER}/.ssh/authorized_keys"
  chown -R "$USER:$USER" "/home/${USER}/.ssh"

  echo "Welcome, stranger! Take a seat. You are now $USER."
  echo
  echo "For future logins, you may use either your new name or this login service."
  echo
  echo "Treat each other with kindness and respect, including this machine. Do not cause"
  echo "harm to others."
fi

cat /etc/motd

su -l "$USER"

Being a POSIX shell script, it should be quite portable. Unless I am missing something, it should only require coreutils and does not use any nonstandard arguments outside of the OS-switching cases. In other words, all this works on a base OpenBSD setup and a normal Debian installation after adding OpenSSH.

The _sha256 function was needed to abstract the different SHA256 utilities from OpenBSD and Debian away into one simple function to call.

Actually, a hash function became required, as I decided not to blindly paste user-provided public keys (hoping only public keys are possible) into the gecos field, but to hash them first and add a known prefix. Doing so somehow felt safer.

The _usergen function receives such a prefixed hash as an argument and returns a user name. As a side effect, the user was created. A username is picked from the /usr/local/share/demoauth-dict wordlist, containing one potential username per line. If the script fails to pick an unused username from the list, openssl(1) is used to create a random string.

After a preflight check to ensure that a public key can be extracted from the SSH_USER_AUTH file, passwd is queried for a user with this hash using getent(1) and awk(1). Unless such a user was found, a new one will be created using the _usergen function. This new user gets its ~/.ssh/authorized_keys file populated, allowing SSH logins outside of this hack.

In the end, su(1) invokes a login for the user account, letting the SSH session result in a shell as this very user. That’s all, folks!

Present with Go Modules

Wed, 13 Aug 2025 13:30:00 +0200

There are a few quite interesting utilities in the Go Tools collection, golang.org/x/tools. One of these is the slide presentation software present.

$ go install golang.org/x/tools/cmd/present@latest

If you have watched any Go presentations in the past, there is quite a chance you have already seen present in action. For example, many of Rob Pike’s talks are using present, e.g., his talk on lexical scanning.

present renders Markdown-ish files to either slides or articles - such as for the Go blog - to be displayed in a web browser. Although the feature set is limited, one killer feature is the ability to execute code directly from the slides. The golang.org/x/tools/present package describes the anatomy of a .slide input file and all available commands.

`.play` Some Code

The mentioned code execution killer feature is named .play and allows not only embedding code, but actually executing this code. For example, the following line in a .slide file would display the content of some demo.go file, make the text box editable, and allow the code to be executed.

.play -edit demo.go

Earlier this year, I have used this for my “Privilege Separation In Go” talk at FOSDEM. At around the 02:00 mark in the linked talk, you can see me altered the code to demonstrate the privileges with which the code usually runs.

Later in the talk, I showed multiple Go libraries that I used directly within present. This, however, was quite a hassle since present - being an older, not so official Go tool - still relies on the $GOPATH. Since time was not on my side, I have ended up filling the $GOPATH manually. And all this over six years after Go 1.11, deep in the age of Go Modules.

Since I was planning to work with external libraries in present again, I settled to patch it in this regard. Just to find out that it can already do this.

`.play` Me A Go Module

The .play command works not only on Go code, but also on the txtar archive format, which I just learned about today (actually, it was yesterday - I am now finishing this post). In a nutshell, it is a plain text format concatenating multiple text files, each being introduced by a -- FILENAME -- marker, with FILENAME being the actual file name. There may also be a comment before the first file’s marker.

The .played file will be parsed as a txtar archive. If the file is an ordinary Go source code file, there will be no marker and everything is part of the leading comment. A non-empty comment will then be treated as a prog.go file. However, if the input contains txtar entries, each one will be created. Additionally, if a go.mod file is included in the txtar input, the Go code will be built as a Go Module.

In practice, this looks like the following. For example’s sake, I am using the SHA-3 TupleHash library I wrote a while back.

$ go mod init demo
go: creating new go.mod: module demo

$ cat main.go
package main

import (
        "fmt"

        "codeberg.org/oxzi/go-tuplehash"
)

func main() {
        fields := [][]byte{[]byte("foo"), []byte(""), []byte("bar")}
        h := tuplehash.NewTupleHash128(nil, 32)
        for _, field := range fields {
                _, _ = h.Write(field)
        }
        fmt.Printf("%x\n", h.Sum(nil))
}

$ go get codeberg.org/oxzi/go-tuplehash
[ . . . ]
$ go build

$ cp main.go demo.txtar
$ for f in go.{mod,sum}; do echo "-- $f --"; cat "$f"; done >> demo.txtar

This can be demonstrated with a simple .slide file as follows. The /^func main/,/^}/ part behind the .play calls reduces the printed output to the main function for aesthetic reasons.

# External Module Test

## Go File - Fails

.play main.go /^func main/,/^}/

## Go File from txtar - Works

.play demo.txtar /^func main/,/^}/

First, present fails due to missing packages - as expected.

The second example based on txtar works and produces a hopefully valid output.

`.play` Me Any Script

While poking through the playground socket code, I made another unexpected discovery: shebang support! If the code starts with a shebang (#!), then it will not be compiled as a Go application, but executed by the shebang interpreter. Therefore, present can be used to run almost any code.

Let’s demonstrate this with an even simpler example of the following .slide:

# Shebang Test

## Python

.play -edit demo.py

And demo.py looking like this:

#!/usr/bin/env python3

import this

present executing a Python script running the PEP 20 easter egg.

Swimming Upstream Is Hard

First and foremost, a random blog post should not be the place to document implementation behavior. Documentation should be, well, in the docs. I have created a pull request, so let’s see how it turns out.

Google’s contribution maze for Go typically guides one through their Gerrit code review tool. Last time I have used it was roughly two years ago and, of course, it requires a Google account. And this was also the last time I have used my Google account, which still has a @googlemail.com address instead of @gmail.com. What’s my age again?

When I tried to log in to this account, Google blocked the login because it thought there was something suspicious about me. As so called “options” to unblock the account, I should either use the same device or a similar location as last time - I have moved roughly 300km. That’s all, no other options.

No Gerrit for me today. This is just another downsides of big tech FOSS projects.

It’s Not A Bug, It’s A Feature

When people ask me what I like about Go, I usually mention its well documented API. As being part of the /x/ namespace, the Go Tools are not so official, but once I became accustomed to the high quality documentation, their lack stood out. And in this case, it misses two very special cases of executing code.

Taking a look at the txtar extraction logic is also a bit scary. Yes sir, I would like you to extract ../../../../../etc/passwd. This has only no further security implications as arbitrary user-supplied code will be executed next.

Thus, do not let present run wild and only execute trusted .slides.

Speaking of undocumented behavior, I tried the same thing in the Go Playground and was quite surprised that the txtar trick worked there as well. Unlike the other code, the Go Playground has some input sanitation in place. Unfortunately, there seems to be no shebang support.

Go Module in the Go Playground as txtar encoded input.

All The Negativity?

The last two sections turned out quite bitter, and I failed to find a way to change that. However, I wanted to end on a positive note and emphasize one more time that I really enjoy working with present. It is a fantastic tool, especially for presentations with code. Use it!

Multi-OS Privilege Dropping in Go

Mon, 17 Mar 2025 22:30:00 +0100

After I started writing about techniques to let software drop privileges, I realized that there is way more to say than I first anticipated. To be able to finish the previous posts, I made many compromises and skipped some topics.

This became especially clear to me after finishing my last post on Privilege Separation in Go, which became very Linux-leaning. While I introduced common POSIX APIs and both Linux and OpenBSD APIs in the earlier Dropping Privileges in Go, only the Linux parts made it into the subsequent post.

The result was a post about architectural changes in software design to achieve privilege separation, but with examples only targeting Linux. Those examples were not portable, something I usually try to avoid. This post tries to make up for that and demonstrates how to write Go code with multiple OS-specific parts for different target platforms.

Non-Portable Code

But what exactly is non-portable code? Let’s start with a very trivial example, calling OpenBSD’s unveil(2) via golang.org/x/sys/unix.

package main

import "golang.org/x/sys/unix"

func main() {
	if err := unix.Unveil(".", "r"); err != nil {
		panic(err)
	}
	if err := unix.UnveilBlock(); err != nil {
		panic(err)
	}
}

The problem is that the two functions unix.Unveil and unix.UnveilBlock are only defined for OpenBSD. When building this program for other operating systems by setting the GOOS environment variable, it will fail.

$ GOOS=openbsd go build
$ GOOS=linux go build
# non-portable-example
./main.go:6:17: undefined: unix.Unveil
./main.go:9:17: undefined: unix.UnveilBlock

If there is code in the codebase that is restricted to certain operating systems, calling it will either fail, or the code will fail to compile, as just demonstrated.

Go Build Constraints

Go comes with an easy way to do conditional builds, including or excluding some files for certain targets. These are the so called build constraints.

They can be used by adding a build tag at the top of the Go file. A simple build tag restricting the file to OpenBSD looks like this.

//go:build openbsd

If only a few OS-restricted functions are involved, a new function that mimicks the original’s signature can be introduced. For the supporting OS, this function wraps the original function. Otherwise, it is either a no-op or raises an error, depending on the use case.

This pattern can be applied to the unveil(2) example above. In an unveil_openbsd.go file, the original functions are being wrapped. The same functions are then implemented in unveil_fallback.go, with an empty function body. In the end, the main.go file now calls the mimicking functions instead of the originals.

// unveil_openbsd.go
//go:build openbsd

package main

import "golang.org/x/sys/unix"

func Unveil(path, permissions string) error {
	return unix.Unveil(path, permissions)
}

func UnveilBlock() error {
	return unix.UnveilBlock()
}

// unveil_fallback.go
//go:build !openbsd

package main

func Unveil(_, _ string) error {
	return nil
}

func UnveilBlock() error {
	return nil
}

// main.go

package main

func main() {
	if err := Unveil(".", "r"); err != nil {
		panic(err)
	}
	if err := UnveilBlock(); err != nil {
		panic(err)
	}
}

Building this modified version will work with the restriction enabled on OpenBSD, while still working unrestricted on any other operating system.

Abstraction Layer

This approach only scales so far. If there are multiple OS-dependent functions and the goal is to support multiple operating systems, this pattern will result in a lot of unnecessary stub functions that will eventually be forgotten.

There is an infamous theorem that any problem in software “engineering” can be solved by introducing another level of indirection. It is said that some even try to apply this to the problem of too much indirection itself.

Nevertheless, abstraction may save us here.

Instead of creating multiple shadow functions, a single function is introduced, having a lookup map to be populated by OS-specific implementations for all possible restrictions.

// Restriction defines an OS-specific restriction type.
type Restriction int

const (
	_ Restriction = iota

	// RestrictLinuxLandlock sets a Landlock LSM filter on Linux.
	//
	// The Restrict() function expects (multiple) landlock.Rule arguments.
	RestrictLinuxLandlock

	// RestrictOpenBSDUnveil sets and blocks unveil(2) on OpenBSD.
	//
	// The Restrict() function expects (multiple) string pairs like
	// ".", "r", "tmp", "rwc". After calling unveil(2) for each pair of path and
	// permission, unveil will be locked.
	RestrictOpenBSDUnveil
)

// restrictionFns is the internal map to be populated for each operating system.
var restrictionFns = make(map[Restriction]func(...any) error)

// Restrict operating system specific permissions.
//
// Based on the Restriction kind, the variadic function arguments differ. They
// are described at their definition.
//
// Note, unknown or unsupported Restrictions will be ignored and do NOT result
// in an error. One may call RestrictOpenBSDUnveil on a Linux without any error.
func Restrict(kind Restriction, args ...any) error {
	fn, ok := restrictionFns[kind]
	if !ok {
		return nil
	}
	return fn(args...)
}

The package-private restrictionFns map can be filled with multiple init functions, like the following.

//go:build linux

package main

import (
	"fmt"

	"github.com/landlock-lsm/go-landlock/landlock"
)

func init() {
	restrictionFns[RestrictLinuxLandlock] = func(args ...any) error {
		rules := make([]landlock.Rule, len(args))
		for i, arg := range args {
			rule, ok := arg.(landlock.Rule)
			if !ok {
				return fmt.Errorf("landlock parameter %d is not a landlock.Rule but %T", i, arg)
			}
			rules[i] = rule
		}

		return landlock.V5.BestEffort().Restrict(rules...)
	}
}

//go:build openbsd

package main

import (
	"fmt"

	"golang.org/x/sys/unix"
)

func init() {
	restrictionFns[RestrictOpenBSDUnveil] = func(args ...any) error {
		if len(args) == 0 || len(args)%2 != 0 {
			return fmt.Errorf("unveil expects two parameters or a multiple of two")
		}

		for i := 0; i < len(args); i += 2 {
			path, ok := args[i].(string)
			if !ok {
				return fmt.Errorf("unveil expects first parameter to be a string, not %T", args[i])
			}

			flags, ok := args[i+1].(string)
			if !ok {
				return fmt.Errorf("unveil expects second parameter to be a string, not %T", args[i+1])
			}

			if err := unix.Unveil(path, flags); err != nil {
				return fmt.Errorf("cannot unveil(%q, %q): %w", path, flags, err)
			}
		}

		return unix.UnveilBlock()
	}
}

Eventually, an external caller can use this as follows.

func main() {
	if err := Restrict(
		RestrictLinuxLandlock,
		landlock.RODirs("/proc", "."),
		landlock.RWDirs("/tmp"),
	); err != nil {
		log.Fatalf("cannot filter Landlock LSM: %v", err)
	}

	if err := Restrict(
		RestrictOpenBSDUnveil,
		".", "r",
		"/tmp", "rwc",
	); err != nil {
		log.Fatalf("cannot unveil(2): %v", err)
	}

	home, err := os.UserHomeDir()
	if err != nil {
		log.Fatalf("cannot obtain home dir: %v", err)
	}

	for _, dir := range []string{".", filepath.Join(home, ".ssh")} {
		_, err := os.ReadDir(dir)
		if err != nil {
			log.Printf("cannot read dir %s: %v", dir, err)
		} else {
			log.Printf("can read dir %s", dir)
		}
	}

	tmpF, err := os.Create("/tmp/08-multi-os-demo")
	if err != nil {
		log.Fatalf("cannot create temp file: %v", err)
	}
	if _, err := fmt.Fprint(tmpF, "hello world"); err != nil {
		log.Fatalf("cannot write temp file: %v", err)
	}
	if err := tmpF.Close(); err != nil {
		log.Fatalf("cannot close temp file: %v", err)
	}
	log.Print("created temp file")
}

Running the code produces the expected outcome.

2025/03/17 21:18:20 can read dir .
2025/03/17 21:18:20 cannot read dir /home/alvar/.ssh: open /home/alvar/.ssh: no such file or directory
2025/03/17 21:18:20 created temp file

Did Someone Say Abstraction Layer?!

While the calls to other operating systems are now harmless no-ops, there is still a distinction within the code. This looks like a textbook example for abstraction. For moar abstraction.

The existing structure already allows adding Restriction types independent of any operating system. It was just the implementation so far that made them OS-dependent. So another entry in the const-and-not-enum list may follow:

	// RestrictFileSystemAccess is an OS-independent abstraction to limit
	// directories to be accessed.
	//
	// The Restrict() function expects two string arrays, one listing directories
	// for reading, writing and executing and a second one for reading and
	// executing only.
	RestrictFileSystemAccess

Its implementation can be built on top of RestrictLinuxLandlock and RestrictOpenBSDUnveil. Both share the same type checking boilerplate and then call the underlying layer.

// Addition to the _linux.go implementation.

func init() {
	restrictionFns[RestrictLinuxLandlock] = func(args ...any) error { /* ... */ }

	restrictionFns[RestrictFileSystemAccess] = func(args ...any) error {
		if len(args) != 2 {
			return fmt.Errorf("RestrictFileSystemAccess expects two string arrays, not %T", args)
		}
		rwDirs, okRwDirs := args[0].([]string)
		roDirs, okRoDirs := args[1].([]string)
		if !okRwDirs || !okRoDirs {
			return fmt.Errorf("RestrictFileSystemAccess expects two string arrays, not %T and %T", args[0], args[1])
		}

		return restrictionFns[RestrictLinuxLandlock](
			landlock.RWDirs(rwDirs...),
			landlock.RODirs(append(roDirs, "/proc")...))
	}
}

// Addition to the _openbsd.go implementation.

func init() {
	restrictionFns[RestrictOpenBSDUnveil] = func(args ...any) error { /* ... */ }

	restrictionFns[RestrictFileSystemAccess] = func(args ...any) error {
		if len(args) != 2 {
			return fmt.Errorf("RestrictFileSystemAccess expects two string arrays, not %T", args)
		}
		rwDirs, okRwDirs := args[0].([]string)
		roDirs, okRoDirs := args[1].([]string)
		if !okRwDirs || !okRoDirs {
			return fmt.Errorf("RestrictFileSystemAccess expects two string arrays, not %T and %T", args[0], args[1])
		}

		rules := make([]any, 0, 2*len(rwDirs)+2*len(roDirs))
		for _, rwDir := range rwDirs {
			rules = append(rules, rwDir, "rwxc")
		}
		for _, roDir := range roDirs {
			rules = append(rules, roDir, "rx")
		}

		return restrictionFns[RestrictOpenBSDUnveil](rules...)
	}
}

Finally, the two OS-specific Restriction(...) calls in the main function can be unified.

	if err := Restrict(
		RestrictFileSystemAccess,
		[]string{"/tmp"},
		[]string{"."},
	); err != nil {
		log.Fatalf("cannot restrict file system access: %v", err)
	}

While this was not even my initial intent, this example of abstraction and unification shows both the advantages and disadvantages of the general idea.

On the plus side, a caller does not need to know any details about either Landlock LSM or unveil(2). Under the hood, implementations for any other operating system can be added or replaced, and hopefully it will just work.

The trade-off is that the nuances of each implementation will be lost. For example, unveil(2) explicitly allows or denies execution for each path, Landlock LSM does not. Thus, the generalized API is reduced to the least common denominator of always allowing file execution, even if not necessary.

What To Use?

It is hard to say how many layers of abstraction to stack on another.

If the software only targets one operating system, nothing here matters - just let compilation fail on other platforms. Depending on the size of the software and the importance of portability, some level of abstraction will prove useful. Personally, I would mostly not attempt the last example of a unified API, since its generalized nature prevents access to specifics.

But again, it depends. And there are even other ways, using other technologies that were totally out of scope for this post.

For example, in the recent Go version 1.24, os.Root was added. This is a Go API allowing to restrict file system calls going through it to be bound to a specific directory, described in more detail in Damien Neil’s “Traversal-resistant file APIs”. While it does not restrict the whole process, it is easy to use without having to deal with the effects of the restriction in other places. These features are not mutually exclusive, of course.

What to use now? Still depends.

However, if you just want the code shown in this post, look no further: codeberg.org/oxzi/go-privsep-showcase.

Privilege Separation in Go

Fri, 21 Feb 2025 09:00:00 +0100

Almost three weeks ago, I gave a talk on privilege separation in the Go programming language at FOSDEM 2025. In my talk, I was foolish enough to announce two blog posts, one I had already written and this one. After a few evenings where I found the time to work on this post, it is finally done.

The previous Dropping Privileges in Go post dealt with the privileges a computer program has. Usually, these privileges are derived from the executing user. If your user can read emails, a program executed by this user can do so as well. Then I showed certain techniques for giving up privileges on POSIX-like operating systems.

But is just limiting all privileges enough? Unfortunately, no, because there may be software projects dealing with both sensitive data as well as having dangerous code blocks. Consider an Internet-facing application that handles user credentials over a spooky committee-born protocol, perhaps even being parsed by a library notorious for security opportunities.

It is possible to split this application apart: Resulting in one restricted part having to deal with authentication, one even more restricted part handling the dangerous parser, and some communication in between. And, honestly, that is the gist of privilege separation. But since this has been a very superficial introduction, more details, specific to POSIX-leaning operating systems and the Go programming language, will follow.

Changes In Software Architecture

It might be a good idea to do some preliminary thinking before you start, to identify both the parts into which you want to divide the software, and the permissions that will be required throughout the life of those parts.

For example, a web application that manages its state in a SQLite database requires both network permissions (opening a port for incoming HTTP connections) and file system permissions (SQLite database). One could implement two subprocesses for each task and would end up with the supervising monitor process, a web server subprocesses (network permissions), and a SQLite subprocesses (file system permissions).

Taking the example from this theoretical level to the POSIX concepts introduced in my previous post, the supervising monitor process could launch two subprocesses, each running under unique user and group IDs. The network-facing subprocesses could be chrooted to an empty directory, while the database subprocess resides within a chroot containing the SQLite file. Alternatively, more modern but OS-specific features can be used to limit each process.

But, to address the second part of the initial issue, do our subprocesses really need those privileges throughout their lifetimes? The answer is very often “no”, especially if the software is designed to perform privileged operations first. An architectural goal might be to start with the most privileged operations, then drop those privileges, and continue this cycle until the main task can be performed, which might also be the most dangerous, e.g., parsing user input.

The example web server may only require the permissions to listen on a port at the beginning. After that, the subprocess should be fine with the file descriptor it already has.

Go Runtime

Nothing Go-specific has been stated so far. There are some elementary differences from C, such as Go having a runtime while C does not.

But there are low-level packages and functions in Go’s standard library that provide access to OS-specific features. Most prominent is the frozen syscall package, which was replaced by golang.org/x/sys/unix for maintenance reasons and to break it free from the Go 1 compatibility promise. So it is quite easy to port C-style privilege separation to Go, if one can adapt a bit.

Creating And Supervising Children

Even if Go has not quite reached C’s maturity, it has gone through over a decade of changes since Go version one. Starting processes is one of the rare situations where one can actually see them. While the syscall package had a ForkExec function, it did not made it into the golang.org/s/sys/unix package.

But wait, a quick interjection first. In C, fork(2) and exec(3) are two independent system calls. Using fork(2) creates a new process, and functions from the exec(3) family - like execve(2) - replace the current process with another process or, in simpler terms, start another process from an executable file in the current process. In Go’s syscall.ForkExec, these two low-level functions have been merged together to provide a more higher-level interface. This was most likely done to make it harder to break the Go runtime.

In addition to merging multiple functions into one, syscall.ForkExec also supports a wide range of specific attributes via syscall.SysProcAttr. These attributes includes user and group switching, chrooting and even cgroup support (v1, I’d guess). Unfortunately, this code was frozen ten years ago and SysProcAttr lacks documentation. Thus, I would advise taking a look at its implementation, but not to use it. One demotivating example might be the internal forkAndExecInChild1 function.

What to use instead? The os package has a Process type and the os/exec package provides an even more abstract interface. From now on, I will stick to os/exec and will do all privilege dropping by myself, even if os/exec still supports syscall.SysProcAttr.

For starters, a short demo to fork itself and select the child operation mode via a command line argument flag should do the trick. A bit glue code can be written around os/exec, resulting in the forkChild function shown in the demo below.

package main

import (
	"bufio"
	"flag"
	"fmt"
	"log"
	"os"
	"os/exec"
	"time"
)

// forkChild forks off a subprocess with -fork-child flag.
//
// The extraFiles are additional file descriptors for communication.
func forkChild(childName string, extraFiles []*os.File) (*os.Process, error) {
	// pipe(2) to communicate child's output back to parent
	logParent, logChild, err := os.Pipe()
	if err != nil {
		return nil, err
	}

	// For the moment, just print the child's output
	go func() {
		scanner := bufio.NewScanner(logParent)
		for scanner.Scan() {
			log.Printf("[%s] %s", childName, scanner.Text())
		}
		if err := scanner.Err(); err != nil {
			log.Printf("Child output scanner failed: %v", err)
		}
	}()

	cmd := &exec.Cmd{
		Path: os.Args[0],
		Args: append(os.Args, "-fork-child", childName),

		Env: []string{}, // don't inherit parent's env

		Stdin:      nil,
		Stdout:     logChild,
		Stderr:     logChild,
		ExtraFiles: extraFiles,
	}
	if err := cmd.Start(); err != nil {
		return nil, err
	}

	return cmd.Process, nil
}
func main() {
	var flagForkChild string
	flag.StringVar(&flagForkChild, "fork-child", "", "")
	flag.Parse()

	switch flagForkChild {
	case "":
		// Parent code
		childProc, err := forkChild("demo", nil)
		if err != nil {
			log.Fatalf("Cannot fork child: %v", err)
		}
		log.Printf("Started child process, wait for it to finish")

		childProcState, _ := childProc.Wait()
		log.Printf("Child exited: %d", childProcState.ExitCode())

	case "demo":
		// Child code
		for i := range 3 {
			fmt.Printf("hello world, %d\n", i)
			time.Sleep(time.Second)
		}
		fmt.Println("bye")

	default:
		panic("This example has only one child")
	}
}

While this example is quite trivial, it demonstrates how the parent process can .Wait() for children and even inspect the exit code. Using this information, the parent can monitor its children and raise an alarm, restart children or crash the whole execution if a child exits prematurely. In a more concrete example, where each child should run as long as the parent, the code waits for the first child to die or for a wild SIGINT to appear, to clean up all child processes.

Inter-Process Communication

This first example was nice and all, but a bit useless. So far, no communication between the processes - main/parent and demo - is possible. This can be solved by creating a bidirectional communication channel between two processes, e.g., via socketpair(2).

A socketpair(2) is similar to a pipe(2), but it is bidirectional (both ends can read and write) and supports certain features usually reserved to Unix domain sockets. Using the already mentioned golang.org/x/sys/unix package allows creating a trivial helper function.

// socketpair is a helper function wrapped around socketpair(2).
func socketpair() (parent, child *os.File, err error) {
	fds, err := unix.Socketpair(
		unix.AF_UNIX,
		unix.SOCK_STREAM|unix.SOCK_NONBLOCK,
		0)
	if err != nil {
		return
	}

	parent = os.NewFile(uintptr(fds[0]), "")
	child = os.NewFile(uintptr(fds[1]), "")
	return
}

The previously introduced forkChild function came with an extraFiles parameter, effectively setting exec.Cmd{ExtraFiles: extraFiles}. These extra files are then passed as file descriptors to the newly created process following the standard streams stdin, stdout and stderr with file descriptors 0, 1 and 2 respectively.

Linking socketpair and forkChild’s extraFiles allows passing a bidirectional socket as file descriptor 3 to the child.

Let’s follow this idea and modify the demo part to implement a simple string-based API that supports both the hello and bye commands returning a useful message back to the sender.

case "demo":
	// Child code
	cmdFd := os.NewFile(3, "")
	cmdScanner := bufio.NewScanner(cmdFd)
	for cmdScanner.Scan() {
		switch cmd := cmdScanner.Text(); cmd {
		case "hello":
			_, _ = fmt.Fprintln(cmdFd, "hello again")

		case "bye":
			_, _ = fmt.Fprintln(cmdFd, "ciao")
			return
		}
	}

This code starts by opening the third file descriptor as an os.File, using it both for a line-wise reader and as a writer for the output. The counterpart can be altered accordingly.

case "":
	// Parent code
	childCommParent, childCommChild, err := socketpair()
	if err != nil {
		log.Fatalf("socketpair: %v", err)
	}

	childProc, err := forkChild("demo", []*os.File{childCommChild})
	if err != nil {
		log.Fatalf("Cannot fork child: %v", err)
	}
	log.Printf("Started child process, wait for it to finish")

	cmdScanner := bufio.NewScanner(childCommParent)
	for _, cmd := range []string{"hello", "hello", "bye"} {
		_, _ = fmt.Fprintln(childCommParent, cmd)
		log.Printf("Send %q command to child", cmd)
		_ = cmdScanner.Scan()
		log.Printf("Received from child: %q", cmdScanner.Text())
	}

	childProcState, _ := childProc.Wait()
	log.Printf("Child exited: %d", childProcState.ExitCode())

In this example, the socketpair(2) is first created using our previously defined helper function. The child part of the socketpair is then passed to the newly created child process, while the parent part is then used for communication. As an example, hello is called twice, followed by a bye call, expecting the child to finish afterwards.

Running this demo will look as follows. The RPC API works!

2025/02/12 22:05:45 Started child process, wait for it to finish
2025/02/12 22:05:45 Send "hello" command to child
2025/02/12 22:05:45 Received from child: "hello again"
2025/02/12 22:05:45 Send "hello" command to child
2025/02/12 22:05:45 Received from child: "hello again"
2025/02/12 22:05:45 Send "bye" command to child
2025/02/12 22:05:45 Received from child: "ciao"
2025/02/12 22:05:45 Child exited: 0

This RPC is quite simple, even for demonstration purposes. So it should be replaced by something more powerful that one would expect to find in real-world applications.

Dropping Privileges

Wait, before we get serious about RPCs, we should first introduce dropping privileges. Otherwise, doing everything that follows would be useless.

The motivation for this post started with a mental image of a program being split into several subprograms, each running only with the necessary privileges. The first part - breaking down a program - has already been addressed. Now it is time to drop privileges.

Luckily, this section will be rather short, since I felt that I have wrote more than enough on this topic in my earlier Dropping Privileges in Go post. I will assume that it was read or at least skimmed.

Looking at the demonstration program, there is a main thread that starts the child before communicating with it, and the child itself just handling some IO. For this example, I am going to use my syscallset-go library to restrict system calls via Seccomp BPF. While this only works on Linux, there are mechanisms for other operating systems, as mentioned in my previous post, e.g., pledge(2) on OpenBSD.

The main program first needs the privileges to create a socketpair(2) and launch the other program. After that, it still communicates over the created file descriptor and monitors the other process. So there are two places where privileges can be dropped: initially and after launching the process. Please take a look at this altered main part, where the two highlighted syscallset.LimitTo blocks drop privileges.

case "":
	// Parent code
	if err := syscallset.LimitTo("@system-service"); err != nil {
		log.Fatalf("seccomp-bpf: %v", err)
	}

	childCommParent, childCommChild, err := socketpair()
	if err != nil {
		log.Fatalf("socketpair: %v", err)
	}

	childProc, err := forkChild("demo", []*os.File{childCommChild})
	if err != nil {
		log.Fatalf("Cannot fork child: %v", err)
	}
	log.Printf("Started child process, wait for it to finish")

	if err := syscallset.LimitTo("@basic-io @io-event @process"); err != nil {
		log.Fatalf("seccomp-bpf: %v", err)
	}

	cmdScanner := bufio.NewScanner(childCommParent)
	for _, cmd := range []string{"hello", "hello", "bye"} {
		_, _ = fmt.Fprintln(childCommParent, cmd)
		log.Printf("Send %q command to child", cmd)
		_ = cmdScanner.Scan()
		log.Printf("Received from child: %q", cmdScanner.Text())
	}

	childProcState, _ := childProc.Wait()
	log.Printf("Child exited: %d", childProcState.ExitCode())

Same must be done for the demo program, where the only privileged task is opening the file descriptor 3 for communication. Afterwards, this process only needs to do IO for its simple RPC task.

case "demo":
	// Child code
	if err := syscallset.LimitTo("@system-service"); err != nil {
		log.Fatalf("seccomp-bpf: %v", err)
	}

	cmdFd := os.NewFile(3, "")

	if err := syscallset.LimitTo("@basic-io @io-event"); err != nil {
		log.Fatalf("seccomp-bpf: %v", err)
	}

	cmdScanner := bufio.NewScanner(cmdFd)
	for cmdScanner.Scan() {
		switch cmd := cmdScanner.Text(); cmd {
		case "hello":
			_, _ = fmt.Fprintln(cmdFd, "hello again")

		case "bye":
			_, _ = fmt.Fprintln(cmdFd, "ciao")
			return
		}
	}

Let’s take a moment to reflect on what was accomplished so far. Splitting up the process and applying different system call filters resulted in a first privilege separated demo. This was actually a lot less code than one might expect.

Using A Real RPC

After reminding ourselves of how to drop privileges, we will move on to a larger example using this technique while also using a more mature RPC. Since I find gRPC too powerful for this task, I will stick to Go’s net/rpc package, despite its shortcomings and feature-frozen state.

While the previous examples were very demo-like, the following one should be a bit more realistic. When finished, a child process should serve a simplified interface to a SQLite database, allowing only certain requests, while the main process should also drop privileges and serve the database’s content through a web server. To give it a realistic spin, let’s call this a web blog (or blog, as the cool kids say).

The skeleton with the forkChild method and the -fork-child command line argument based main method remains. However, the database needs some code, especially some that can be used by net/rpc. The following should work, creating a Database type and two RPC methods, ListPosts and GetPost.

// Database is a wrapper type around *sql.DB.
type Database struct {
	db *sql.DB
}

// OpenDatabase opens or creates a new SQLite database at the given file.
//
// If the database should be created, it will be populated with the posts table
// and two example entries.
func OpenDatabase(file string) (*Database, error) {
	_, fileInfoErr := os.Stat(file)
	requiresSetup := errors.Is(fileInfoErr, os.ErrNotExist)

	db, err := sql.Open("sqlite3", file)
	if err != nil {
		return nil, err
	}

	if requiresSetup {
		if _, err := db.Exec(`
			CREATE TABLE posts (id INTEGER NOT NULL PRIMARY KEY, text TEXT);
			INSERT INTO posts(id, text) VALUES (0, 'hello world!');
			INSERT INTO posts(id, text) VALUES (1, 'second post, wow');
		`); err != nil {
			return nil, fmt.Errorf("cannot prepare database: %w", err)
		}
	}

	return &Database{db: db}, nil
}

// ListPosts returns all post ids as an array of integers.
//
// This method follows the net/rpc method specification.
func (db *Database) ListPosts(_ *int, ids *[]int) error {
	rows, err := db.db.Query("SELECT id FROM posts")
	if err != nil {
		return err
	}

	*ids = make([]int, 0, 128)
	for rows.Next() {
		var id int
		if err := rows.Scan(&id); err != nil {
			return err
		}
		*ids = append(*ids, id)
	}
	return rows.Err()
}

// GetPost returns a post's text for the id.
//
// This method follows the net/rpc method specification.
func (db *Database) GetPost(id *int, text *string) error {
	return db.db.QueryRow("SELECT text FROM posts WHERE id = ?", &id).Scan(text)
}

Without further ado, create a database main entry using this Database type. In this case, the child will not be named demo, since it now serves a real purpose.

case "database":
	// SQLite database child for posts
	if err := syscallset.LimitTo("@system-service"); err != nil {
		log.Fatalf("seccomp-bpf: %v", err)
	}

	rpcFd := os.NewFile(3, "")

	db, err := OpenDatabase("posts.sqlite")
	if err != nil {
		log.Fatalf("Cannot open SQLite database: %v", err)
	}

	if err := landlock.V5.BestEffort().RestrictPaths(
		landlock.RODirs("/proc"),
		landlock.RWFiles("posts.sqlite"),
	); err != nil {
		log.Fatalf("landlock: %v", err)
	}
	if err := syscallset.LimitTo("@basic-io @io-event @file-system"); err != nil {
		log.Fatalf("seccomp-bpf: %v", err)
	}

	rpcServer := rpc.NewServer()
	rpcServer.Register(db)
	rpcServer.ServeConn(rpcFd)

This code starts by dropping some privileges to prohibit the juicy syscalls. Then it opens the already known file descriptor 3 next to the SQLite database located at posts.sqlite.

Since no more files need to be accessed at this point, the privileges are being dropped again. Starting with Landlock LSM, only allowing read-only access to Linux’ /proc required by some Go internals and read-write access to the posts.sqlite database file. Next comes a stricter system call filter.

Finally, the net/rpc is started on the third file descriptor serving the Database. This will block until the connection is closed, which effectively means the child has finished.

The main part now needs to follow. As initially outlined, it should start by forking off the database child, then drop its own privileges, and finally serving a web server. Since there are two RPC methods Database.ListPosts and Database.GetPost, they can be queried from the main code and used to build the web frontend for this blog.

case "":
	// Parent: Starts children, drops to HTTP server
	if err := syscallset.LimitTo("@system-service"); err != nil {
		log.Fatalf("seccomp-bpf: %v", err)
	}

	databaseCommParent, databaseCommChild, err := socketpair()
	if err != nil {
		log.Fatalf("socketpair: %v", err)
	}

	_, err = forkChild("database", []*os.File{databaseCommChild})
	if err != nil {
		log.Fatalf("Cannot fork database child: %v", err)
	}

	httpLn, err := net.Listen("tcp", ":8080")
	if err != nil {
		log.Fatalf("cannot listen: %v", err)
	}

	if err := landlock.V5.BestEffort().RestrictPaths(
		landlock.RODirs("/proc"),
	); err != nil {
		log.Fatalf("landlock: %v", err)
	}
	if err := syscallset.LimitTo("@basic-io @io-event @network-io @file-system"); err != nil {
		log.Fatalf("seccomp-bpf: %v", err)
	}

	rpcClient := rpc.NewClient(databaseCommParent)

	httpMux := http.NewServeMux()
	httpMux.HandleFunc("GET /", func(w http.ResponseWriter, r *http.Request) {
		w.Header().Add("Content-Type", "text/html")

		var ids []int
		err = rpcClient.Call("Database.ListPosts", 0, &ids)
		if err != nil {
			http.Error(w, "cannot list posts: "+err.Error(), http.StatusInternalServerError)
			return
		}

		_, _ = fmt.Fprint(w, `<ul>`)
		for _, id := range ids {
			_, _ = fmt.Fprintf(w, `<li><a href="/post/%d">Post %d</a></li>`, id, id)
		}
		_, _ = fmt.Fprint(w, `</ul>`)
	})
	httpMux.HandleFunc("GET /post/{id}", func(w http.ResponseWriter, r *http.Request) {
		w.Header().Add("Content-Type", "text/html")

		id, err := strconv.Atoi(r.PathValue("id"))
		if err != nil {
			http.Error(w, "cannot parse ID: "+err.Error(), http.StatusInternalServerError)
			return
		}

		var text string
		err = rpcClient.Call("Database.GetPost", &id, &text)
		if err != nil {
			http.Error(w, "cannot fetch post: "+err.Error(), http.StatusInternalServerError)
			return
		}

		_, _ = fmt.Fprintf(w, `<h1>Post %d</h1><p>%s</p>`, id, html.EscapeString(text))
	})

	httpd := http.Server{Handler: httpMux}
	log.Fatal(httpd.Serve(httpLn))

Like the child, the main part started by dropping system calls to the reasonable @system-service group. Then it creates the socketpair(2) and launches the child, as done in the previous examples. Another privileged operation follows, opening a TCP port to listen on :8080.

At this point, privileges can be dropped further, again using Landlock LSM and Seccomp BPF. Following, an RPC client connection is established against the parent’s side of the socketpair(2) and the web server’s endpoints are defined. All known posts should be listed on /, which can be requested from the RPC client via the Database.ListPosts method. More details will then be available on /post/{id} using the Database.GetPost RPC method.

In the end, a http.Server has been created and is being served on the previously created TCP listener. Incoming requests are served and result in an RPC call to the child process that is allowed to access the database.

Passing Around File Descriptors

While this RPC works well for these constraints, what about file access? Think about an RPC API that needs to access lots of files and pass the contents from one process to another. Reading the whole file, encoding it, sending it, receiving it and decoding it does not sound very efficient. Fortunately, there is a way to actually share file descriptors between processes for POSIX.

One process can open a file, pass the file descriptor to the other process, and close the file again, while the other process can now read the file, even though it would not have no access to it. The art of passing file descriptors is a bit more obscure and beautifully explained in chapter 17.4 Passing File Descriptors of the definitive book Advanced Programming in the Unix Environment. If you are interested in the details, please check it out - PDFs are available online.

The following works as our socketpair(2) call created a pair of AF_UNIX sockets, effectively being Unix domain sockets In addition to exchanging streaming data over a Unix domain socket, it is also possible to pass specific messages. But let’s start with the code, which may look a bit cryptic on its own.

// unixConnFromFile converts a file (FD) into an Unix domain socket.
func unixConnFromFile(f *os.File) (*net.UnixConn, error) {
	fConn, err := net.FileConn(f)
	if err != nil {
		return nil, err
	}

	conn, ok := fConn.(*net.UnixConn)
	if !ok {
		return nil, fmt.Errorf("cannot use (%T, %T) as *net.UnixConn", f, conn)
	}
	return conn, nil
}

// sendFd sends an open File (its FD) over an Unix domain socket.
func sendFd(f *os.File, conn *net.UnixConn) error {
	oob := unix.UnixRights(int(f.Fd()))
	_, _, err := conn.WriteMsgUnix(nil, oob, nil)
	return err
}

// recvFd receives a File (its FD) from an Unix domain socket.
func recvFd(conn *net.UnixConn) (*os.File, error) {
	oob := make([]byte, 128)
	_, oobn, _, _, err := conn.ReadMsgUnix(nil, oob)
	if err != nil {
		return nil, err
	}

	cmsgs, err := unix.ParseSocketControlMessage(oob[0:oobn])
	if err != nil {
		return nil, err
	} else if len(cmsgs) != 1 {
		return nil, fmt.Errorf("ParseSocketControlMessage: wrong length %d", len(cmsgs))
	}

	fds, err := unix.ParseUnixRights(&cmsgs[0])
	if err != nil {
		return nil, err
	} else if len(fds) != 1 {
		return nil, fmt.Errorf("ParseUnixRights: wrong length %d", len(fds))
	}

	return os.NewFile(uintptr(fds[0]), ""), nil
}

Starting with the unixConnFromFile function, which creates a *net.UnixConn based on a generic *os.File. This allows converting one end of the socketpair(2) to a Unix domain socket without losing Go’s type safety.

Then, the sendFd function encodes the file descriptor to be sent into a socket control message and sends it over the virtual wire. On the other side, the recvFd function waits for such a control message, unpacks it and returns a new *os.File to be used.

To give a little background, each process has its own file descriptor table, each entry is represented in the kernel’s file table, which is eventually mapped to a vnode entry. Thus, one process’ file descriptor 42 and another’s file descriptor 23 could actually be the same file. Same applies here, sending a file descriptor will most likely result in a different file descriptor number at the receiving end. However, the kernel will take care that this little stunt works.

Again, please consult Stevens’ Advanced Programming in the Unix Environment for more details or take a look at the implementation in the golang.org/x/sys/unix package. Or just accept that it works and move on.

Let’s extend the previous example and add another child process that serves pictures for each blog post to be shown. This child will need file system access to a directory of images, sending them over to the main process via file descriptor passing, as just introduced.

First, implement the new child.

case "img":
	// File storage child to send pictures for posts back as a file descriptor
	if err := syscallset.LimitTo("@system-service"); err != nil {
		log.Fatalf("seccomp-bpf: %v", err)
	}

	rpcFd := os.NewFile(3, "")

	rpcSock, err := unixConnFromFile(rpcFd)
	if err != nil {
		log.Fatalf("cannot create Unix Domain Socket: %v", err)
	}

	imgDir, err := filepath.Abs("./cmd/07-05-fork-exec-rpc/imgs/")
	if err != nil {
		log.Fatalf("cannot abs: %v", err)
	}

	if err := landlock.V5.BestEffort().RestrictPaths(
		landlock.RODirs("/proc", imgDir),
	); err != nil {
		log.Fatalf("landlock: %v", err)
	}
	if err := syscallset.LimitTo("@basic-io @io-event @file-system @network-io"); err != nil {
		log.Fatalf("seccomp-bpf: %v", err)
	}

	rpcScanner := bufio.NewScanner(rpcFd)
	for rpcScanner.Scan() {
		file, err := filepath.Abs(imgDir + "/" + rpcScanner.Text() + ".png")
		if err != nil {
			log.Printf("cannot abs: %v", err)
			continue
		}
		if dir := filepath.Dir(file); dir != imgDir {
			log.Printf("file directory %q mismatches, expected %q", dir, imgDir)
			continue
		}

		f, err := os.Open(file)
		if err != nil {
			log.Printf("cannot open: %v", err)
			continue
		}

		if err := sendFd(f, rpcSock); err != nil {
			log.Printf("cannot send file descriptor: %v", err)
		}
		_ = f.Close()
	}

I hope you are not bored reading this kind of code. It gets pretty repetitive, I know. But please bear with me and follow me through the img child.

The first part should be quite familiar by now: forbidding some syscalls and opening file descriptor 3. But now the third file descriptor is also converted to a Unix domain socket for later use. Landlock LSM restricts directory access to the directory containing the pictures, and a stricter Seccomp BPF filter follows.

After that, a simple string-based RPC is being used again, which reads what files to open line by line. Besides a simple prefix check, the Landlock LSM filter denies everything outside the allowed directory. If the file can be opened, its file descriptor will be send back to the main process.

A few small changes are required in the main process. They are highlighted and explained below.

case "":
	// Parent: Starts children, drops to HTTP server
	if err := syscallset.LimitTo("@system-service"); err != nil {
		log.Fatalf("seccomp-bpf: %v", err)
	}

	databaseCommParent, databaseCommChild, err := socketpair()
	if err != nil {
		log.Fatalf("socketpair: %v", err)
	}
	imgCommParent, imgCommChild, err := socketpair()
	if err != nil {
		log.Fatalf("socketpair: %v", err)
	}

	imgCommSock, err := unixConnFromFile(imgCommParent)
	if err != nil {
		log.Fatalf("cannot create Unix Domain Socket: %v", err)
	}

	_, err = forkChild("database", []*os.File{databaseCommChild})
	if err != nil {
		log.Fatalf("Cannot fork database child: %v", err)
	}
	_, err = forkChild("img", []*os.File{imgCommChild})
	if err != nil {
		log.Fatalf("Cannot fork img child: %v", err)
	}

	httpLn, err := net.Listen("tcp", ":8080")
	if err != nil {
		log.Fatalf("cannot listen: %v", err)
	}

	if err := landlock.V5.BestEffort().RestrictPaths(
		landlock.RODirs("/proc"),
	); err != nil {
		log.Fatalf("landlock: %v", err)
	}
	if err := syscallset.LimitTo("@basic-io @io-event @network-io @file-system"); err != nil {
		log.Fatalf("seccomp-bpf: %v", err)
	}

	rpcClient := rpc.NewClient(databaseCommParent)

	httpMux := http.NewServeMux()
	httpMux.HandleFunc("GET /", func(w http.ResponseWriter, r *http.Request) {
        // Same as before.
	})
	httpMux.HandleFunc("GET /post/{id}", func(w http.ResponseWriter, r *http.Request) {
		w.Header().Add("Content-Type", "text/html")

		id, err := strconv.Atoi(r.PathValue("id"))
		if err != nil {
			http.Error(w, "cannot parse ID: "+err.Error(), http.StatusInternalServerError)
			return
		}

		var text string
		err = rpcClient.Call("Database.GetPost", &id, &text)
		if err != nil {
			http.Error(w, "cannot fetch post: "+err.Error(), http.StatusInternalServerError)
			return
		}

		_, _ = fmt.Fprintln(imgCommParent, id)
		imgFd, err := recvFd(imgCommSock)
		if err != nil {
			http.Error(w, "cannot fetch img: "+err.Error(), http.StatusInternalServerError)
		}
		defer imgFd.Close()

		_, _ = fmt.Fprintf(w, `<h1>Post %d</h1><p>%s</p>`, id, html.EscapeString(text))
		_, _ = fmt.Fprint(w, `<img src="data:image/png;base64,`)

		encoder := base64.NewEncoder(base64.StdEncoding, w)
		io.Copy(encoder, imgFd)
		encoder.Close()

		_, _ = fmt.Fprint(w, `" />`)
	})

	httpd := http.Server{Handler: httpMux}
	log.Fatal(httpd.Serve(httpLn))

The first changes are to create another socketpair(2) and fork off the second child. Except for also creating a unixConnFromFile, they are analogous to the startup code for the first child process.

The interesting part happens inside the HTTP handler for /post/{id}. If the SQLite database knows of a post for the id, that id is written to the parent’s socketpair(2) end to be read the by the img child’s RPC loop. The code then waits to receive a file descriptor over the Unix domain socket created on the same connection. After receiving the file descriptor, its content is copied into a base64 encoder and written as an encoded image back to the web response.

This example now has two subprocesses, each running with differently restricted privileges. An RPC mechanism in between allows inter-process communication, including the passing of file descriptors. At this point, it is safe to say that privilege separation has been achieved.

What’s Next?

This post was the logical successor to Dropping Privileges in Go. While the first one described how to drop various privileges, this one focused on architectural changes to drop privileges more granularly. Adding privilege separation to the toolbox of software architectures makes it possible to build more robust software under the assumption that the software will be pwned some day.

The examples shown here and more are available in a public git repository at codeberg.org/oxzi/go-privsep-showcase. Before creating these explicit examples, I have toyed with these technologies in a “research project” of mine, called gosh. Please feel free to take a look at it for more inspirations.

There are still some related topics I plan to write about, but I would not go so far and create any announcements. Stay tuned.

Dropping Privileges in Go

Sat, 01 Feb 2025 01:30:00 +0100

Computer programs may do lots of things, both intended and unintended. What they can do is limited by their privileges. Since most operating systems execute programs as a certain user, the program has all the user’s precious privileges.

To take a concrete example, if a user has an SSH private key laying around and runs, e.g., a chat program, then this program is able to read the private key even though it has nothing to do with it. Assuming that this chat is exploitable, then an attacker might instruct the chat through a crafted message to exfiltrate the private key.

Maybe not the issue’s core, but the damage is rooted in the fact that a program was able to access a resource that it should not be able to access in the first place. As writing secure software is out of scope, the private key could have been saved if the principle of least privilege would have been enforced by some means. It says, in a nutshell, that each component, i.e., the chat software, should only have the necessary privileges and nothing more. Many roads might lead to this state, e.g., not using the same user for private key interactions and chatting or sandboxing the chat application.

When developing software, the developer should know what their tool should be able to do. Thus, they are able to carve out the allowed territories, denying everything else with the help of system features. As a metaphor, think of a werewolf chaining themself up before full moon.

In case you are asking yourself right now why you should do this to your code as it will never fail, then especially you should do this. For most applications out there, the question is not if they can be broken, but more when they will be broken. Since I wrote many bugs throughout the years and saw exploits unable to grasp, I am trying to self-chain all my future werewolves.

Changes In Software Architecture

The idea of self-restricting software is that given up privileges cannot be gotten back. For example, once the program denied itself file system access, no more files can be opened.

The software starts as a certain user, sometimes the root user, e.g., to use an restricted network port. Thus, after starting to listen on this port, this privilege can be dropped, e.g., by switching to an unprivileged user while keeping the file descriptor. The software continues accepting connections on the prior bound port, but cannot start listening on other restricted ports.

This limitation must be taken into account when planning the software. Instead of being able to access all resources when necessary, they must be acquired in the beginning phase before self-restricting. To introduce another questionable metaphor, think about a funnel or an upside down cone: Your program starts with all these privileges, dropping it along as it goes until it continues with just the bare minimum.

Good Old Chroot And User-Switch

Let’s start with the classic approach of chrooting and user/group changing. I called it classical, because this variant goes back to the early 1990s and it works on any POSIX-like operating system (think BSDs, Linux and friends).

Unfortunately, this approach has the annoyance that the necessary system calls are reserved for the root user. While in most cases this is not a problem for daemons, this would be a blocker for end user applications, like GUIs. Instead of suggesting some SUID file flag madness, secure alternatives for rootless scenarios will follow.

`chroot(2)`

First things first: chroot(2) changes the process’ root directory to the supplied one. For example, / becomes /var/empty and accessing /etc/passwd would actually try to open /var/empty/etc/passwd. To activate the chroot(2), the process needs to chdir(2) into it.

Unless further actions are taken, an attacker can break out of a chroot. Actually, chrooting is not a security feature, but can be used to build one - as this post attempts. Nevertheless, please be aware of the limitations.

A chroot directly impacts the process. If it should not interact with any files, chrooting to /var/empty or some just created empty directory makes sense. If there is one directory, one can consider chrooting to this directory. If, however, files from different locations must be accessed, a strict chroot can be a burden. This is a decision one has to take on a case by case basis.

After importing golang.org/x/sys/unix, the following snippet is enough to chroot(2) the process to /var/empty, which is a “[g]eneric chroot(2) directory”, according to OpenBSD’s hier(2).

if err := unix.Chroot("/var/empty"); err != nil {
    log.Fatalf("chroot: %v", err)
}
if err := unix.Chdir("/"); err != nil {
    log.Fatalf("chdir: %v", err)
}

`setuid(2)` or `setresuid(2)`

The process may now be chrooted to an empty directory, but otherwise still runs as root. To give up root privileges, let the process switch user rights to an unprivileged user without qualities.

Throughout the ages, multiple syscalls for user switching have emerged, starting at setuid(2). While not strictly being part of POSIX, the setresuid(2) syscall is available on most operating systems. It allows setting the real, effective and saved user ID, where there are fine differences between them. These may differ when developing or using a SUID application, having the real user ID of your user and the effective user ID of the root user. In this case, however, we just want to drop all privileges to our unqualified user, setting all three user IDs to the same user.

The same applies to groups with setresgid(2). In addition, as a process may have multiple groups, this list can be shortened via setgroups(2). Doing so results in only the group privileges of the given groups applies, not all other user groups.

For the example, create an unprivileged worker user. On a Linux, this can be done as the following:

$ sudo useradd \
    --home-dir /var/empty \
    --system \
    --shell /run/current-system/sw/bin/nologin \
    --user-group \
    demoworker
$ id demoworker
uid=992(demoworker) gid=987(demoworker) groups=987(demoworker)

Continue with the following short code block:

// Prior chroot code

uid, gid := 992, 987
if err := unix.Setgroups([]int{gid}); err != nil {
    log.Fatalf("setgroups: %v", err)
}
if err := unix.Setresgid(gid, gid, gid); err != nil {
    log.Fatalf("setresgid: %v", err)
}
if err := unix.Setresuid(uid, uid, uid); err != nil {
    log.Fatalf("setresuid: %v", err)
}

While this snippet works as a demonstration, having to actually configure the user and group ID is a bit too much. Thus, let the code do the lookup by writing a short helper function around os/user.

One word of caution regarding the os/user package: It caches the current user and one cannot simply invalidate this cache. Thus, after using the following helper function user.Current() will always return whatever executed this function first.

// uidGidForUserGroup fetches an UID and GID for the given user and group.
func uidGidForUserGroup(username, groupname string) (uid, gid int, err error) {
	userStruct, err := user.Lookup(username)
	if err != nil {
		return
	}
	userId, err := strconv.ParseInt(userStruct.Uid, 10, 64)
	if err != nil {
		return
	}
	groupStruct, err := user.LookupGroup(groupname)
	if err != nil {
		return
	}
	groupId, err := strconv.ParseInt(groupStruct.Gid, 10, 64)
	if err != nil {
		return
	}

	uid, gid = int(userId), int(groupId)
	return
}

When using this function, a word of caution is necessary as this might be the first situation where the chroot can shoot us in the foot. The lookup requires the /etc/passwd and /etc/group files to be accessible. Thus, when already be chrooted to /var/empty, this will obviously fail:

open /etc/passwd: no such file or directory

First, do the lookup, then chroot(2), and finally perform the user/group switching.

// Start with root privileges, do necessary lookups.
uid, gid, err := uidGidForUserGroup("demoworker", "demoworker")
if err != nil {
    log.Fatalf("user/group lookup: %v", err)
}

// Drop into chroot
if err := unix.Chroot("/var/empty"); err != nil {
    log.Fatalf("chroot: %v", err)
}
if err := unix.Chdir("/"); err != nil {
    log.Fatalf("chdir: %v", err)
}

// Switch to an unprivileged user unable to escape chroot
if err := unix.Setgroups([]int{gid}); err != nil {
    log.Fatalf("setgroups: %v", err)
}
if err := unix.Setresgid(gid, gid, gid); err != nil {
    log.Fatalf("setresgid: %v", err)
}
if err := unix.Setresuid(uid, uid, uid); err != nil {
    log.Fatalf("setresuid: %v", err)
}

// Application code follows

Limiting Resources The POSIX Way

After chrooting and dropping root user privileges, the code may no longer access privileged system APIs or some files, but can still run cycles. For example, a parser may be vulnerable to a billion laughs attack, resulting in either 100% CPU load or even memory exhaustion.

One good old POSIX way to limit different kinds of resources is setrlimit(2). Depending on the targeting operating system, different resources are defined.

Both horror scenarios from the example can be addressed either via RLIMIT_CPU for CPU time or via RLIMIT_DATA for data.

`RLIMIT_CPU`

The CPU time or process time is the amount of actively consumed CPU cycles of a single process. If the process calculates something nonstop, this counter raises. However, if the process waits for certain events, the counter idles as well.

As an example, idle for a bit and then burn CPU cycles by useless hash computations while limiting the CPU time to one second.

if err := unix.Setrlimit(
    unix.RLIMIT_CPU,
    &unix.Rlimit{Max: 1},
); err != nil {
    log.Fatal("setrlimit: %v", err)
}

log.Println("CPU time != execution time, hanging low")
time.Sleep(5 * time.Second)
log.Println("STRESS!")

buff := make([]byte, 32)
for i := uint64(1); ; i++ {
    _, _ = rand.Read(buff)
    _ = sha256.Sum256(buff)

    if i%100_000 == 0 {
        log.Printf("Run %d", i)
    }
}

Putting this example into a main function shows how the process gets aborted after consuming too much CPU time.

2025/01/26 20:17:18 CPU time != execution time, hanging low
2025/01/26 20:17:23 STRESS!
2025/01/26 20:17:23 Run 100000
[ . . . ]
2025/01/26 20:17:24 Run 800000
[1]    190379 killed     ./02-01-setrlimit-cpu

`RLIMIT_DATA`

This second example limits the maximum data segments to 10MiB or, in other words, restricts the amount of available memory to 10MiB.

The code will allocate memory within an infinite loop, resulting an out of memory situation. However, due to the setrlimit(2) call, the process gets aborted.

if err := unix.Setrlimit(
    unix.RLIMIT_DATA,
    &unix.Rlimit{Max: 10 * 1024 * 1024},
); err != nil {
    log.Fatal("setrlimit: %v", err)
}

var blobs [][]byte
for i := uint64(1); ; i++ {
    buff := make([]byte, 1024)
    _, _ = rand.Read(buff)
    blobs = append(blobs, buff)

    if i%1_000 == 0 {
        log.Printf("Allocated %dK", i)
    }
}

And this will be aborted due to its memory hunger.

2025/01/26 20:17:44 Allocated 1000K
2025/01/26 20:17:44 Allocated 2000K
fatal error: runtime: out of memory
[ . . . ]

Good Hard Limits?

These two examples set hard limits, resulting in eventually aborting the process. Especially RLIMIT_CPU, being an increasing counter, will be reached.

Thus, what are good values? Depends, of course.

Just to be sure, if deciding to set any limits, make them high enough to not be reached anyhow during normal operation. If something goes south, they are still there as a safety net.

And what about soft limits? That is an exercise left for the reader.

Doubling Down With OS-specific Features

Everything so far should work on most POSIX-like operating systems. As an advantage, using these patterns in your program may work on platforms you did not even know existed.

But there are also OS-specific mechanisms allowing to drop privileges, even when not starting as the root but with an usual user. Since my personal experience is limited to Linux and OpenBSD, I will address some of their features. With OpenBSD having simpler APIs to use, I will start there.

Restricting Syscalls On OpenBSD

The operating system’s kernel verifies if the user privileges are sufficient to access some resource. For example, when trying to open(2) a file, the operating system may deny this. This check happens within open(2). But what if the program itself cannot even use open(2) since the developer knows that it never must open a file in the first place. Welcome to system call filtering, allowing a program to restrict what syscalls are being used later on.

If there is a thing like having a favorite system call, mine might be OpenBSD’s pledge(2). It provides a simple string-based API to restrict the available system calls based on space separated keywords, called promises.

These promises are names of syscall groups, e.g., rpath for read-only system calls regarding the file system. By adding exec to the list, executing other programs will be allowed, starting them with their own promise, given in the second parameter.

int pledge(const char *promises, const char *execpromises);

After a pledge(2) was made, it cannot be undone, only be tightened. Tightening means calling pledge(2) another time with a shorter promises list. In case of violating the syscall promise, the process gets either killed or, if error is part of the promise, the denied system call returns an error.

As being a system call, it is available for Go in golang.org/x/sys/unix.

Unfortunately, the web Go Packages thingy only renders the docs for some selected platforms, not including OpenBSD. Thus, I took the liberty to paste the docs below. By the way, setting the GOOS or GOARCH environment variable also works for go doc, e.g., GOOS=openbsd go doc -all golang.org/x/sys/unix works on a Linux.

func Pledge(promises, execpromises string) error
    Pledge implements the pledge syscall.

    This changes both the promises and execpromises; use PledgePromises or
    PledgeExecpromises to only change the promises or execpromises respectively.

    For more information see pledge(2).

func PledgeExecpromises(execpromises string) error
    PledgeExecpromises implements the pledge syscall.

    This changes the execpromises and leaves the promises untouched.

    For more information see pledge(2).

func PledgePromises(promises string) error
    PledgePromises implements the pledge syscall.

    This changes the promises and leaves the execpromises untouched.

    For more information see pledge(2).

Now, there are three Go functions for pledge(2): One to set both parameters and one to set only the first or second one. Let’s create an example for a simple program working with an input file, making a promise just allowing to read the file and making another tighter one after it was read. Use your imagination what the program should do, e.g., it can convert an image to another format and printing it out to stdout.

// Start with limited privileges
if err := unix.PledgePromises("stdio rpath error"); err != nil {
    log.Fatalf("pledge: %v", err)
}

// Read input file
f, err := os.Open("input")
if err != nil {
    log.Fatalf("cannot open input: %v", err)
}
inputFile, err := io.ReadAll(f)
if err != nil {
    log.Fatalf("cannot read input: %v", err)
}
if err := f.Close(); err != nil {
    log.Fatalf("cannot close input: %v", err)
}

// Drop further, reading files is no loner necessary
if err := unix.PledgePromises("stdio error"); err != nil {
    log.Fatalf("pledge: %v", err)
}

// Do some computation based on the input

As the example shows, using pledge(2) is both easy and boring. That might be the reason why most programs being shipped with OpenBSD are pledged and there are lots of patches for ported software. Only one command results in dropping so much privileges. Impressive.

Restricting File System Access On OpenBSD

This post opened with the constructed example of a pwned chat program used to exfiltrate the user’s SSH private key. What if a program could make a promise which file system path are needed, denying every other access? OpenBSD’s unveil(2) addresses this, similar as pledge(2) does for system calls.

Multiple unveil(2) calls are creating an allow-list to unveiled paths the program is allowed to access. Each call adds a path and the kind of permission: read, write, exec and/or create. After a finalizing call of two empty parameters, this will be enforced.

Thus, if the chat program would use unveil(2) for relevant directories - definitely not containing ~/.ssh -, this exploit would have been mitigated.

int unveil(const char *path, const char *permissions);

This system call is available for Go in golang.org/x/sys/unix as well.

func Unveil(path string, flags string) error
    Unveil implements the unveil syscall. For more information see unveil(2).
    Note that the special case of blocking further unveil calls is handled by
    UnveilBlock.

func UnveilBlock() error
    UnveilBlock blocks future unveil calls. For more information see unveil(2).

Thus, in Go multiple unix.Unveil(...) calls might be issued with a closing unix.UnveilBlock().

Continuing with the chat program example, a program can be written to allow read/write/create access to some Download directory to store cringy memes. All other file system requests should be denied.

// Restrict read/write/create file system access to the ./Download directory.
// This does not include exec!
if err := unix.Unveil("Download", "rwc"); err != nil {
    log.Fatalf("unveil: %v", err)
}
if err := unix.UnveilBlock(); err != nil {
    log.Fatalf("unveil: %v", err)
}

// Buggy application starts here: allowing path traversal
userInput := "../.ssh/id_ed25519"

f, err := os.Open("Download/" + userInput)
if err != nil {
    log.Fatalf("cannot open file: %v", err)
}
defer f.Close()

privateKey, err := io.ReadAll(f)
if err != nil {
    log.Fatalf("cannot read: %v", err)
}
log.Printf("looks familiar?\n%s", privateKey)

Taking this code for a test drive shows how a good old path traversal attack was mitigated, even if the file exists.

$ ./04-openbsd-unveil
2025/01/26 22:11:57 cannot open file: open Download/../.ssh/id_ed25519: no such file or directory
$ ls -l Download/../.ssh/id_ed25519
-rw-------  1 user  user  420 Jan 26 22:10 Download/../.ssh/id_ed25519

Great success!

Restricting Syscalls On Linux

Let’s switch operating systems and focus on the Linux kernel for a while.

The similar named section about system call filtering on OpenBSD started with a few sentences about how system calls are the gateway between programs and the kernel to access resources. Same applies to Linux, and almost any operating system out there. Denying unnecessary syscalls directly implies restricting privileges.

Linux comes with a very powerful tool, Seccomp BPF, allowing each process to supply a program to the kernel, deciding which system calls are being allowed. This program is an Berkeley Packet Filter (BPF), receiving both the syscall number and (some) arguments. Thus, it is even possible to allow or deny only certain parameters of a syscall.

Obviously, this great flexibility has its ups and downs. While there are situations where one might want to create a very specific filter, a quick-and-dirty one might be more common. At least in my experience as an unwashed userland developer, I mostly prefer a more rough filter, especially in Go where mostly not interacting with system calls directly.

But where to start? When wanting to get the pure Seccomp BPF experience in Go, there is the github.com/elastic/go-seccomp-bpf package, written in pure Go without any cgo. It allows developing fine-grained filters on a system call basis, as introduced above.

When I first used it, I had no real clue where to start with writing a filter for my Go program. Starting with an all denying filter and using Linux’ auditd(8) I made progress in getting hopefully all necessary syscalls. But then I had to realize that updating Go or any of my dependencies may result in other code (d’oh!) and therefore other system calls. Another constraint is that there are slightly differences between the available system calls of different architectures.

Thus, I started to play around with a more wider filter list and eventually “borrowed” the sets available in systemd’s SystemCallFilter. Administrators may know this feature already, allowing to restrict the available system calls for each service under systemd’s control through a list of system calls, quite familiar to pledge(2). After a while I built myself a small library exactly for this use case, github.com/oxzi/syscallset-go.

From a developer’s perspective, it serves a simple string-based API to build yourself a list of allowed system calls through groups. Honestly, I just shipped systemd’s code to Go and made it fly using the aforesaid go-seccomp-bpf library. But it works.

// Start with limited privileges
if err := syscallset.LimitTo("@system-service"); err != nil {
    log.Fatalf("seccomp: %v", err)
}

// Read input file
f, err := os.Open("input")
if err != nil {
    log.Fatalf("cannot open input: %v", err)
}
inputFile, err := io.ReadAll(f)
if err != nil {
    log.Fatalf("cannot read input: %v", err)
}
if err := f.Close(); err != nil {
    log.Fatalf("cannot close input: %v", err)
}

// Drop further, reading files is no loner necessary
if err := syscallset.LimitTo("@basic-io"); err != nil {
    log.Fatalf("seccomp: %v", err)
}

// Do some computation based on the input

The not dozed off reader might recognize this code, as it is almost identical to the demo code used for pledge(2) above. However, there are a few small differences. First and most obvious, the filters differ. There are also no meta-filters on OpenBSD like the used @system-service, containing lots of commonly used system calls. Furthermore, OpenBSD’s pledge(2) had the handy error group, allowing forbidden system calls to fail, when set. Otherwise, the kernel would kill the process. This behavior also applies here, were each misstep will directly be punished by process execution.

Restricting File System Access On Linux… And Network Access As Well

For symmetry sake, Linux’ answer to unveil(2) must follow. And it does, but it is also way more. Please welcome Landlock LSM.

While Landlock started to address the same issues as unveil(2) - limiting file system access -, it recently grow to also allow certain network isolations. But let the code speak for us, using the github.com/landlock-lsm/go-landlock library.

Restricting Paths

// Restrict file system access to the ./Download directory.
if err := landlock.V5.BestEffort().RestrictPaths(
    landlock.RWDirs("Download"),
); err != nil {
    log.Fatalf("landlock: %v", err)
}

// Buggy application starts here: allowing path traversal
userInput := "../.ssh/id_ed25519"

f, err := os.Open("Download/" + userInput)
if err != nil {
    log.Fatalf("cannot open file: %v", err)
}
defer f.Close()

privateKey, err := io.ReadAll(f)
if err != nil {
    log.Fatalf("cannot read: %v", err)
}
log.Printf("looks familiar?\n%s", privateKey)

This code might also look familiar, because it is an adapted version of the earlier unveil(2) example.

One thing worth mentioning might be the V5.BestEffort() part. Landlock itself is versioned, growing with Linux releases in features. But to build a Go program compatible with older targets, the BestEffort part falls back to what the targeted kernel supports. In case this is not desired, directly use V5.RestrictPaths - or whatever version is the latest when reading.

Restricting Network

At the moment, the possibilities to restrict network connections is still a bit limited in Landlock, but therefore has a simple API. In case you are looking for a full-fledged network limitation suite on Linux, maybe take a look at cgroup eBPF-based network filtering.

So, what is definitely possible? The application is able to limit both inbound and outbound TCP traffic based on ports. Or, in simpler words, one can allow certain TCP ports.

// Restrict outbound TCP connections to port 443.
if err := landlock.V5.BestEffort().RestrictNet(
    landlock.ConnectTCP(443),
); err != nil {
    log.Fatalf("landlock: %v", err)
}

// HTTP should fail, while HTTPS should work.
for _, proto := range []string{"http", "https"} {
    _, err := http.Get(proto + "://pkg.go.dev/")
    log.Printf("%q worked: %t\t%v", proto, err == nil, err)
}

This little example only allows outgoing TCP connections to port 443, as the failing HTTP (port 80) connection shows. Of course, this is no secure way to restrict your application to only use HTTPS.

./06-02-linux-landlock-tcp
2025/01/27 21:35:32 "http" worked: false        Get "http://pkg.go.dev/": dial tcp [2600:1901:0:f535::]:80: connect: permission denied
2025/01/27 21:35:32 "https" worked: true        <nil>

And finally, there is also landlock.BindTCP as a rule option, restricting the TCP ports to be bound to. This may be especially useful when fearing that an attacker launches a shell.

Is This All? Are We Finished?

Have I now covered all possible options for an application to self-restrict its privileges? Obviously not. I have not even started covering Linux’ cgroups, itself allowing a wide range of restrictions. And then there are even other operating systems, like FreeBSD with its capsicum(4).

My main goal for this post was to show that there are quite simple APIs to restrict limiting privileges. OpenBSD itself comes with simple APIs and for Linux there are the two shown Go libraries making these big, very configurable features also usable as a one-liner.

Then there is setrlimit(2), which one might wanna use or might wanna ignore. And of course the root-restricted chroot(2)/setresuid(2) dance.

Thus, you as a developer have a choice. As shown, it is quite easy adding some of the introduced mechanisms to protect your software against future mischief. I would urge you to give it a try, limiting the attack surface of your program.

The examples used in this post and more are available in the following git repository, https://codeberg.org/oxzi/go-privsep-showcase. May it be useful.

Relaxed RSS with sfeed

Fri, 01 Nov 2024 18:00:00 +0100

While the golden age of huge platforms offering RSS feeds may be over, lots of webpages still have feeds, especially niche blogs. Over the years, I have tried many RSS readers, but have always given up because they did not work for me. However, by switching to the more obsucre sfeed, I found a workflow that worked (and flowed) for me.

Why RSS and what for?

But before getting into it, I think I need to clarify what I use RSS for. And just to say it once, this post does not distinguishes between RSS and Atom, as the difference is a technicality. To stay on that technical level just for a moment, RSS is only a file format to describe feeds. Major news outlets use it to announce multiple news items per hour, some social media sites allow each post to be read via RSS, code forges publish releases or even commits via RSS, and it is the secret ingredient in the podcasting sauce.

The bottom line is that RSS may be out of sight, but it is still everywhere. But if one is going to subscribe to everything, one might end up with hundreds or thousands of posts in no time. This would be, for me at least, an information overload, resulting in stop reading. Besides, for daily news, I just go to one or several of the big news sites anyway.

So I mainly subscribe to smaller private blogs or niche news sites with a few articles per month. Supplemented by a careful selection of meta-aggregators and mailing list archives, both further filtered. At the moment, there must be round about 130 feeds. This number is growing slowly but steadily as I find something new more often than I decide to drop a source. Depending on the day of the week, this results in about twenty posts each day.

User Experience Matters

In my experience, most RSS readers follow an inbox architecture that expects me to interact with each new post (or to give up and mark them all as read). So even after pre-filtering, the inbox would fill up quickly. While this inbox concept works well for things which are actually important, like the one in a hundred email you need to respond to, it makes reading feeds uncomfortably stressful, like working against an ever-growing to-do list. This is an information overload and a FOMO scenario all over again.

Using sfeed and some degree of customization, I was able to built myself a private news feed. This feed is generated daily and is then completely static, there is no unread counter and if I skip some days, I can read back, but no software bullies me into it.

In particular, there are two (or three) ways how I consume my feeds. First, there is a custom web feed that shows the last 256 entries, grouped and ordered by date - called the bytefeed. This has become one of the first pages I open in the morning, usually before checking to see if anything of world importance has happened. From there, I can follow each aggregated feed to my archive, listing all known feeds, also as a webpage.

Exemplary output of sfeed-bytefeed, in dark and non-dark mode.

Furthermore, the previous day’s posts are also sent to a private IRC channel. This may seem a bit quirky, but personally I am an excessive IRC user, not only for communication, but also as a message broker. Using my favorite IRC client WeeChat, I am able to receive both monitoring and news events both in WeeChat itself and on my smartphone.

00:31 -- Notice(xdf) -> #feeds: HTB: Editorial                                                         https://0xdf.gitlab.io/2024/10/19/htb-editorial.html
00:31 -- Notice(analognow) -> #feeds: unpatchable fourth wall breaking sentience                             https://analognowhere.com/_/ghtmnt
00:31 -- Notice(analognow) -> #feeds: illegal book fair                                                      https://analognowhere.com/_/rnituc
00:31 -- Notice(dragasitn) -> #feeds: Outdated Infrastructure and the Cloud Illusion                         https://it-notes.dragas.net/2024/10/19/outdated-infrastructure-and-the-cloud-illusion/
00:31 -- Notice(fsfeplane) -> #feeds: TSDgeos' blog: KDE Gear 24.12 release schedule                         https://tsdgeos.blogspot.com/2024/10/kde-gear-2412-release-schedule.html
00:31 -- Notice(grumpyweb) -> #feeds: nikitonsky is being grumpy                                             https://grumpy.website/1582
[...]

As initially stated, the user experience of a tool matters a lot. While this particular UX may not be appealing to some (or most), it does a pretty decent job for me: Getting daily news digests without having to work through them or actively interact with an “app”.

sfeed?

So far I have only talked about my fear of software and my obsessions with workflows. But what exactly is sfeed?

In a nutshell, sfeed is a collection of small tools to convert RSS feeds into a TAB-separated value (TSV) file and then to present these TSVs in another human or machine-friendly way. These tools are written either in C or as portable POSIX shell scripts, so they can be used on most operating systems. Everything comes with a well-written man page and an exhausting README.

While this may sound boring at first, sfeed’s simple architecture makes it easy to build a custom RSS reader. Representing feeds as a TSV instead of some weird XML allows writing filters or further output generators in almost any script language, like awk.

While sfeed is not restricted to be used only on servers, I configured a pipeline like the following to be run nightly via cron on a small VM:

Call sfeed_update to refresh all RSS feeds configured.
Create two HTML files served by httpd: the feed archive via sfeed_html and the bytefeed shown above via a custom sfeed_bytefeed script.
Send day’s posts to the IRC via my custom sfeed_irc script.

All this is being triggered from one small script, being configured as a cron job. Afterwards, everything is static until the next iteration starts.

How the sfeed sausage is made

To get started, the essential sfeed tools are required. Several package managers provide a sfeed package. Otherwise, compiling sfeed yourself should be a walk in a park due to the minimal dependencies.

In an attempt to make it all less abstract, I will add commands usable on OpenBSD. A certain degree of cognitive flexibility is assumed.

user@openbsd:~> doas pkg_add sfeed

While most of the sfeed tools come with a pledge(2) promise by default, sanity and reason recommend creating a custom user.

user@openbsd:~> doas useradd -g =uid -m -s /sbin/nologin _rss

After switching to this unprivileged _rss user, building on the sfeed example configuration is a good starting point. One can either find an example installed by your package manager or upstream.

_rss@openbsd:~> mkdir ~/.sfeed
_rss@openbsd:~> cp \
    /usr/local/share/examples/sfeed/sfeedrc.example \
    ~/.sfeed/sfeedrc

A quick look at the .sfeed/sfeedrc file along with skimming sfeedrc(5) should explain the basics. In a nutshell, the feeds function contains multiple feed function calls, representing the remote RSS feeds to be fetched. How the fetching is done can be overridden by a custom fetch function. In particular, a custom filter function allows manipulating the fetched data, but more on that later.

To demonstrate this further, let’s start with this very minimal .sfeed/sfeedrc and fetch the feeds via sfeed_update(1).

_rss@openbsd:~> cat .sfeed/sfeedrc
feeds() {
        feed "undeadly" "https://undeadly.org/cgi?action=rss"
        feed "xkcd" "https://xkcd.com/rss.xml"
}

_rss@openbsd:~> sfeed_update
[20:25:48] xkcd                                               OK
[20:25:48] undeadly                                           OK

Each feed is stored in its own file, represented by the feed name, within ~/.sfeed/feeds. So you might end up with something like this. As mentioned above, sfeed works on TSV, and these files are already in the TAB-separated format described in sfeed(1). For example, one can extract the titles of each XKCD.

_rss@openbsd:~> ls -l .sfeed/feeds/
-rw-r--r--  1 _rss  _rss    13727 Oct 27 20:25 undeadly
-rw-r--r--  1 _rss  _rss     1740 Oct 27 20:25 xkcd

_rss@openbsd:~> awk -F '\t' '{ print $2 }' .sfeed/feeds/xkcd
Sandwich Helix
RNAWorld
Temperature Scales
Experimental Astrophysics

But in most cases there is no need to manually inspect a feed file. There is a sfeed tool for that! sfeed_plain(1) gives a nice terminal listing while sfeed_html(1) creates an HTML rendered output. This works both for single or multiple feeds.

_rss@openbsd:~> sfeed_plain .sfeed/feeds/xkcd
  2024-10-25 06:00  xkcd             Sandwich Helix                                                         https://xkcd.com/3003/
  2024-10-23 06:00  xkcd             RNAWorld                                                               https://xkcd.com/3002/
  2024-10-21 06:00  xkcd             Temperature Scales                                                     https://xkcd.com/3001/
  2024-10-18 06:00  xkcd             Experimental Astrophysics                                              https://xkcd.com/3000/

_rss@openbsd:~> sfeed_html .sfeed/feeds/*
<!DOCTYPE HTML>
<html>
[. . .]

Custom Scripts

While sfeed comes with a multitude of tools to build your RSS reader with, it is a very hackable ecosystem, as both mentioned and demonstrated. To build my RSS reader, the following tools have emerged over time. Some of them were C programs derived from sfeed_plain, but to celebrate this year’s awktober, they were rewritten in awk.

For this blog post, I have cleaned up my local clone of the sfeed repository and moved them to sfeed-contrib. There are two types of script in this repo: custom sfeed formatter like sfeed_bytefeed and helper scripts, especially for automation.

_rss@openbsd:~> git clone https://codeberg.org/oxzi/sfeed-contrib.git
_rss@openbsd:~> ls -l sfeed-contrib/
total 32
drwxr-xr-x  2 _rss  _rss   512 Oct 26 22:35 LICENSES
-rw-r--r--  1 _rss  _rss  1995 Oct 26 22:35 README.md
-rwxr-xr-x  1 _rss  _rss  1858 Oct 26 22:35 sfeed_bytefeed
-rwxr-xr-x  1 _rss  _rss   307 Oct 26 22:35 sfeed_edit
-rwxr-xr-x  1 _rss  _rss  1405 Oct 26 22:35 sfeed_irc
-rwxr-xr-x  1 _rss  _rss  1104 Oct 26 22:35 sfeed_run
-rwxr-xr-x  1 _rss  _rss   192 Oct 26 22:35 sfeed_test
-rw-r--r--  1 _rss  _rss  1169 Oct 26 22:35 style.css

Both sfeed_bytefeed and sfeed_irc have already been roughly explained above, but I am going to repeat myself. They take sfeed feed files as parameters and create an HTML feed of the last 256 entries or post the posts of the day to an IRC channel, respectively. The style.css file is a customization of the upstream stylesheet to support both sfeed_html and sfeed_bytefeed.

The entire workflow of updating feeds and utilizing formatters was glued together in sfeed_run. This script does exactly that, after some preflight checks for the configuration expected in the .sfeed/sfeedrc. In order to share this script (command listing would be the better word) with the world, some potentially sensitive values have been moved elsewhere. Thus, sfeed_run expects sfeedpath to be set according to sfeedrc(5), sfeedwwwroot to point to a directory where the _rss user has write access to dump the HTML files and a gzipped version, and sfeedirchost and sfeedircport to point to an open IRC server.

_rss@openbsd:~> head -n 4 .sfeed/sfeedrc
sfeedpath="$HOME/.sfeed/feeds"
sfeedwwwroot="/var/www/htdocs/rss.example.internal"
sfeedirchost="irc.example.internal"
sfeedircport="6667"

Since sfeed_run executes the whole pipeline, it is run as a nightly cron job. As some feeds may fail, the output - sfeed_run only prints errors - is be sent to another user who may log in from time to time.

_rss@openbsd:~> crontab -l
MAILTO=user
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

30 0 * * * /home/_rss/sfeed-contrib/sfeed_run

Configuring sfeed

While a .sfeed/sfeedrc file may look as short as posted as the example above, it can grow over time. However, the most common changes are updated feed entries in the feeds function.

To verify if a URL to some feed works, I built the little sfeed_test helper script. It sources the .sfeed/sfeedrc file and uses the fetch function to retrieve the remote content. For information on fetch, consult sfeedrc(5). In the example above, no such function was defined, resulting in curl to be used. In my setup, I a use OpenBSD’s ftp(1) command, which is also present in the example configuration of the OpenBSD port.

_rss@openbsd:~> grep -A 2 '^fetch' .sfeed/sfeedrc
fetch() {
        ftp -M -V -w 15 -o - "$2"
}

This allows a simple test like the following, where the latest posts will be shown, formatted with sfeed_plain(1).

_rss@openbsd:~> ./sfeed-contrib/sfeed_test 'https://lobste.rs/t/openbsd.rss'
  2024-10-13 11:14  OpenBSD is Hard to Show Off                                            https://atthis.link/blog/2024/16379.html
  2024-10-07 22:35  OpenBSD 7.6                                                            https://www.openbsd.org/76.html
  2024-10-04 15:20  I Solve Problems                                                       https://it-notes.dragas.net/2024/10/03/i-solve-problems-eurobsdcon/
[. . .]

Thus, after verifying that the URL to a new feed entry actually works, I use sfeed_edit to edit the .sfeed/sfeedrc file. Again, this script is mostly a wrapper around opening the configuration file with vim. This script’s magic is keeping track of configuration file changes via rcs(1) - yes, the Revision Control System, that single-file CVS thingy. If changes have been detected, one must commit them and sfeed_run is executed, otherwise, nothing happens.

The rcs(1) part is mostly there because I personally like to put my configurations into some version control system. Doing so gives me backups, at least to a some extent, and a wonderful history via rlog(1).

Filtering and Transforming

Initially mentioned, I prefer to filter some feeds. Fortunately, sfeed supports this via sfeedrc(5)’s filter function, which is described as follows.

filter(name, url)
        Filter sfeed(5) data from stdin and write it to stdout, its
        arguments are:

        name    Feed name.
        url     URL of the feed.

Thus, this function is called on every feed, receiving all incoming TSV data on stdin and continuing with the TSV data sent back to stdout. This architecture allows stream-based filtering, even chaining multiple filters. However, since the output is in the domain of this function, it also allows rewriting of feeds, e.g., to enrich titles.

Helpful filters, at least for me, were to remove posts on mixed announcement and discussion mailing lists, to show only the original post. When subscribing to meta-aggregators, it was useful to prefix the title with the origin, based on the URL. In the past, I have subscribed to a YouTube channel where I was only interested in certain videos, allowing to drop others based on the title.

Since these are just some ideas of what is possible, maybe posting a stripped down version of my current filter will make it more concrete.

# filter(name, url)
filter() {
  case "$1" in
  "freifunk community news")
    # Prefix title with domain
    awk '
      BEGIN { FS=OFS="\t" }
      match($3, /:\/\/[a-z0-9.-]+\//) {
        $2 = "[" substr($3, RSTART+3, RLENGTH-4) "] " $2
        print $0
      }
    ' ;;

  "oss-sec")
    # Drop replies; first posts only.
    awk -F '\t' '$2 !~ /^Re: /' ;;

  *)
    cat ;;
  esac |\
  # Use URL as title if title is missing.
  awk 'BEGIN { FS=OFS="\t" } { sub(/^$/, $3, $2); print $0 }' |\
  # Prefix YouTube links with [VIDEO].
  awk 'BEGIN { FS=OFS="\t" } $3 ~ /https:\/\/www.youtube/ { $2 = "[VIDEO] " $2} //'
}

But why?

Right now, this blog post clocks in at over 2k words. That is a lot of text to describe how to use an RSS reader. Why even bother?

As I said at the beginning, good software should not get in your way. Not only should it work, but it should work for you, without forcing you to bend to its design. This is not limited to RSS readers, of course.

However, in the RSS domain, sfeed has done the trick for me. So I just wanted to say “thank you” for this wonderful piece of software. I also wanted to showcase how to get started with it and how easy it is to extend it. If the normal RSS reader workflow does not work for you, I would encourage you to give sfeed a shot.

The One Euro OpenBSD Server

Sun, 22 Sep 2024 22:30:00 +0200

For quite some time I have been on the lookout for a cheap, small virtual server for one or two toy projects. My unspoken requirements were the ability to install OpenBSD, having IPv6, and that the hoster is not completely shady.

While lowering the bar for “cheap”, picking all three seems to become quite difficult. Unfortunately, since most hosters use some Linux QEMU/KVM stack nowadays, OpenBSD’s installability was almost always the least problematic.

Without further ado, except, of course, stating that I have not received any money from this hoster for this post, I will name them once and then only describe technical details, hopefully transferable to other hosting scenarios.

The hoster is STRATO, one of the bigger and older ones in Germany, and they offer so called “Budget Linux V-Servers”, where the cheapest, VC 1-1, comes with 1 vCore, 1G RAM, 10G storage, and one IPv4 plus one IPv6 address for one Euro per month.

This may sound weak by today’s standards, but it is enough for me. Maybe a little more storage would be nice, but for one Euro I cannot complain (or even buy a bread roll anymore).

Install OpenBSD From Linux

Most hoster offer a selection of (sometimes outdated) GNU/Linux distributions, but a BSD option is uncommon. This, however, is no problem as one can utilize a Linux - I prefer Debian - to install OpenBSD.

The used technique is not novel and I have read variants in various places, noticeable this older misc@ mailing list post.

Start by booting the (still Linux) VM and download the bsd.rd file of the latest OpenBSD release.

root@debian:~# wget -O /openbsd.rd \
  https://cdn.openbsd.org/pub/OpenBSD/7.5/amd64/bsd.rd

Then take a look at the partitions and find out which partition of which “disk” contains /openbsd.rd.

root@debian:~# fdisk -l
[snip]

Device      Start      End  Sectors  Size Type
/dev/vda1  262144 20971486 20709343  9.9G Linux root (x86-64)
/dev/vda14   2048     8191     6144    3M BIOS boot
/dev/vda15   8192   262143   253952  124M EFI System

For me, there is only one disk and the entire Linux file system resides on the first partition.

This information is enough to create a new GRUB boot record, stating that on

the first disk (zero-based) - hd0 -
the first partition (one-based now, of course) - hd0,1-
contains a file named /openbsd.rd.

With this information, a boot entry like the following can be appended to /etc/grub.d/40_custom.

root@debian:~# tail -n4 /etc/grub.d/40_custom
menuentry "OpenBSD" {
  set root=(hd0,1)
  kopenbsd /openbsd.rd
}

Since a human being will be using GRUB later, the GRUB_TIMEOUT should be a reasonable number. For me, a later overwrite in /etc/default/grub.d/15_timeout.cfg set this variable to zero. As the last file wins, make sure it contains GRUB_TIMEOUT=10.

root@debian:~# vi /etc/default/grub{,.d/*}

Finalize the setup on the Linux side by updating GRUB based on the changes just made.

root@debian:~# update-grub

Install From GRUB

Now is the perfect moment to launch the hoster’s web-based VNC console. When it is up and running - showing the Debian login - type a final reboot in your session and wait for the VNC console to show GRUB. If it shows up, select “OpenBSD” and proceed.

For me, the installation wizard just worked and I mostly went with the suggestions.

The only limitation - perhaps due to an incorrect keyboard layout - was the unavailability of the “Shift” modifier key, but only for special characters. So I was unable to get a list of all mirror servers, just went with the first one by typing 1.

Finishing Touch on OpenBSD

After the installation succeeded, reboot into your freshly installed OpenBSD. Congratulations!

There are a few things one might want to do first, like, e.g., installing patches via syspatch or configuring sshd to only accept public key-based logins via PasswordAuthentication no. But this is out of this post’s scope.

However, at least for my specific hosting situation, one tweak to the network configuration was necessary. On OpenBSD (at least for now, being at 7.5), the dynamic address configuration supports DHCP for IPv4 and SLAAC for IPv6. My hoster, however, stated that DHCPv6 is necessary for the IPv6 configuration. Not wanting to install another DHCP client just for that, I searched the web for older documentation and found a configuration without the need for DHCPv6.

Setting the IPv6 address shown in the hoster’s web interface with a prefix length of 128 - being one address, not a block - and using fe80::1 as the gateway was enough to make it work. Interestingly, a very similar setup was necessary for another machine at a totally different hoster.

user@openbsd:~> doas cat /etc/hostname.vio0
inet autoconf
inet6 2001:db8::1 128  # Put your IPv6 address here!
!route add -inet6 default fe80::1%vio0

Outlook

The new server is running smoothly so far. I have not experienced any hiccups, network issues or the like. Since one of its first tasks is hosting this blog, find out how it works in the future.

0x21

Anonymous OpenSSH Account Creation

Skip the how, but actually what?

Demo Time

Back to the how

sshd_config

ForceCommand

Present with Go Modules

.play Some Code

.play Me A Go Module

First, present fails due to missing packages - as expected.

The second example based on txtar works and produces a hopefully valid output.

.play Me Any Script

present executing a Python script running the PEP 20 easter egg.

Swimming Upstream Is Hard

It’s Not A Bug, It’s A Feature

Go Module in the Go Playground as txtar encoded input.

All The Negativity?

Multi-OS Privilege Dropping in Go

Non-Portable Code

Go Build Constraints

Abstraction Layer

Did Someone Say Abstraction Layer?!

What To Use?

Privilege Separation in Go

Changes In Software Architecture

Go Runtime

Creating And Supervising Children

Inter-Process Communication

Dropping Privileges

Using A Real RPC

Passing Around File Descriptors

What’s Next?

Dropping Privileges in Go

Changes In Software Architecture

Good Old Chroot And User-Switch

chroot(2)

setuid(2) or setresuid(2)

Limiting Resources The POSIX Way

RLIMIT_CPU

RLIMIT_DATA

Good Hard Limits?

Doubling Down With OS-specific Features

Restricting Syscalls On OpenBSD

Restricting File System Access On OpenBSD

Restricting Syscalls On Linux

Restricting File System Access On Linux… And Network Access As Well

Restricting Paths

Restricting Network

Is This All? Are We Finished?

Relaxed RSS with sfeed

Why RSS and what for?

User Experience Matters

Exemplary output of sfeed-bytefeed, in dark and non-dark mode.

sfeed?

How the sfeed sausage is made

Custom Scripts

Configuring sfeed

Filtering and Transforming

But why?

The One Euro OpenBSD Server

Install OpenBSD From Linux

Install From GRUB

Finishing Touch on OpenBSD

Outlook

`.play` Some Code

`.play` Me A Go Module

`.play` Me Any Script

`chroot(2)`

`setuid(2)` or `setresuid(2)`

`RLIMIT_CPU`

`RLIMIT_DATA`