linux

Last time we built a proof-of-concept of a tool which could run a process in linux with guardrails around syscalls based on what shared object they originated from. This time we'll fill in some of the missing functionality to be able to run more programs.

I once read a blog post about the capabilities model in WASM, and specifically the idea that you can, when calling another module, give that module some subset of the capabilities you have. The idea being that if I'm, say, calling a function in a compression library, that function doesn't need to be able to talk on the network^[1]. I was looking for a project to do to get back into OS-level programming (my job for the past few years has been very much the opposite of that) and thought it would be fun to try to implement something similar with binaries in Linux. The first part of that project is what this post is about.

If you just want to see the code, it's on github!

This is the second post in a series. See the previous one here.

Things are looking grim. We do not have much to work with. But there is still hope!

One thing you may have noticed if you're following along in the simulator is that once everything gets blown away, you still have your ssh connection, and you can still try to run commands. Most of them will reply with a command not found message, but at least something is still alive to print that!

How does that happen if we deleted everything?

My beautiful binaries! (With apologies to Eric Rosen)

Yesterday a friend came to me with a problem. While managing some backups, he accidentally deleted /bin, /boot, /dev, /tmp, /srv, /usr, and /opt from the filesystem itself instead of the backups.

This left an interesting problem: without the binaries from /bin and /usr, it was impossible to do almost everything you normally do. Picture the situation. You do not have a head or a tail, let alone an entire cat! No chmod, certainly nothing fancy like curl or sshd. If you listen closely though, you might hear an echo...