Jupiter Broadcasting

Sandboxing Cohabitation | BSD Now 170

chris

RSS Feeds:

MP3 Feed | OGG Feed | iTunes Feed | Video Feed | HD Vid Feed | HD Torrent Feed

Become a supporter on Patreon:

– Show Notes: –

Headlines

EuroBSDcon 2016 Presentation Slides

Cohabiting FreeBSD and Gentoo Linux on a Common ZFS Volume

HardenedBSD introduces Safestack into base

pledge(2)… or, how I learned to love web application sandboxing

I use application-level sandboxing a lot because I make mistakes a lot; and when writing web applications, the price of making mistakes is very dear.

In the early 2000s, that meant using systrace(4) on OpenBSD and NetBSD. Then it was seccomp(2) (followed by libseccomp(3)) on Linux. Then there was capsicum(4) on FreeBSD and sandbox_init(3) on Mac OS X.

All of these systems are invoked differently; and for the most part, whenever it came time to interface with one of them, I longed for sweet release from the nightmare. Please, try reading seccomp(2). To the end. Aligning web application logic and security policy would require an arduous (and usually trial-and-error or worse, copy-and-paste) process. If there was any process at all — if the burden of writing a policy didn’t cause me to abandon sandboxing at the start.

And then there was pledge(2).

This document is about pledge(2) and why you should use it and love it. “

Let’s play a drinking game. The challenge is to stay out of the hospital.

1.Navigate to seccomp(2).
2. Read it to the end.
3. Drink every time you don’t understand.

For capsicum(4), the challenge is no less difficult. To see these in action, navigate no further than OpenSSH, which interfaces with these sandboxes: sandbox-seccomp-filter.c or sandbox-capsicum.c. (For a history lesson, you can even see sandbox-systrace.c.) Keep in mind that these do little more than restrict resources to open descriptors and the usual necessities of memory, signals, timing, etc. Keep that in mind and be horrified. “

News Roundup

Unix history repository, now on GitHub

The history and evolution of the Unix operating system is made available as a revision management repository, covering the period from its inception in 1970 as a 2.5 thousand line kernel and 26 commands, to 2016 as a widely-used 27 million line system. The 1.1GB repository contains about half a million commits and more than two thousand merges. The repository employs Git system for its storage and is hosted on GitHub. It has been created by synthesizing with custom software 24 snapshots of systems developed at Bell Labs, the University of California at Berkeley, and the 386BSD team, two legacy repositories, and the modern repository of the open source FreeBSD system. In total, about one thousand individual contributors are identified, the early ones through primary research. The data set can be used for empirical research in software engineering, information systems, and software archaeology.

Yandex commits improvements to FreeBSD network stack

The brief history of Unix socket multiplexing – select(2) system call

In mid-1960’s time sharing was still a recent invention. Compared to a previous paradigm – batch-processing – time sharing was truly revolutionary. It greatly reduced the time wasted between writing a program and getting its result. Batch-processing meant hours and hours of waiting often to only see a program error. See this film to better understand the problems of 1960’s programmers: “The trials and tribulations of batch processing”.

These days when a program was executed, it could “stall” (block) only on a couple of things1:

  • wait for CPU
  • wait for disk I/O
  • wait for user input (waiting for a shell command) or console (printing data too fast)“

This all changed in 1983 with the release of 4.2BSD. This revision introduced an early implementation of a TCP/IP stack and most importantly – the BSD Sockets API.
Although today we take the BSD sockets API for granted, it wasn’t obvious it was the right API. STREAMS were a competing API design on System V Revision 3.

Select was introduced to allow applications to multiplex their I/O.

Consider a simple application like a remote login. It has descriptors for reading from and writing to the terminal and a descriptor for the (bidirectional) socket. It needs to read from the terminal keyboard and write those characters to the socket. It also needs to read from the socket and write to the terminal. Reading from a descriptor that has nothing queued causes the application to block until data arrives. The application does not know whether to read from the terminal or the socket and if it guesses wrong will incorrectly block. So select was added to let it find out which descriptor had data ready to read. If neither, select blocks until data arrives on one descriptor and then awakens telling which descriptor has data to read.

[…] Non-blocking was added at the same time as select. But using non-blocking when reading descriptors does not work well. Do you go into an infinite loop trying to read each of your input descriptors? If not, do you pause after each pass and if so for how long to remain responsive to input? Select is just far more efficient.

Select also lets you create a single inetd daemon rather than having to have a separate daemon for every service.

In this discussion I was afraid to phrase the core question. Were Unix processes intended to be CSP-style processes? Are file descriptors a CSP-derived “channels”? Is select equivalent to ALT statement?

I think: no. Even if there are design similarities, they are accidental. The file-descriptor abstractions were developed well before the original CSP paper.

It seems that an operating socket API’s evolved totally disconnected from the userspace CSP-alike programming paradigms. It’s a pity though. It would be interesting to see an operating system coherent with the programming paradigms of the user land programs.

How to start CLion on FreeBSD?

Beastie Bits

Feedback/Questions