-
src
Read-only git conversion of OpenBSD's official CVS src repository. Pull requests not accepted - send diffs to the tech@ mailing list.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
The OP talks a lot about solving this problem through either capabilities or effect type systems, but the approach to this problem that I think is most interesting is OpenBSD's pledge() and unveil(). The way those functions work is that, when they're called at runtime, they pre-commit the program to only thereafter have access to certain system calls or filesystem locations. Any system calls that violate pledges or attempt to access veiled filesystem paths will result in system call failures (e.g. in C, syscalls would return -1 or whatever the failure result is for each function's API). This is enforced at the operating system level on a per-process basis. Effectively, it's like each process defines its own sandboxing boundaries and the OS enforces them. As an example, OpenBSD's sleep implementation first pledges it won't use anything besides I/O syscalls, then does its business. If there were some bug in the code that allowed an attacker to execute arbitrary instructions (e.g. a buffer overflow), it still couldn't do anything dangerous like modifying the filesystem or setting the process's userid to root.