#\ is the weird syntax for character objects in Guile, so #\1 is the character "1". This expression reads a single character from userns-file and checks if it is the character "1".
The root capabilities section is worrying. Instead of trying to exhaustively list every capability that needs to be dropped, shouldn't the code instead just list the capabilities that are allowed, and clear all the others?
This would seem to better guard against accidentally missing existing capabilities, and also protect against newer capabilities that might be added in a future kernel.
I fully agree that whitelisting is safer than blacklisting.
But on the top of the article, the author explicitly recognzied this and explained why they went down that route:
> I wanted specifically to find a minimal set of restrictions to run untrusted code. This isn't how you should approach containers on anything with any exposure: you should restrict everything you can. But I think it's important to know which permissions are categorically unsafe!
I agree, you should iterate over all your existing capabilities and drop those that are not in the white-list. (I have implemented this functionality in one of my projects this way.)
BUT:
Maybe the reason some people do it otherwise, is that capabilities API have only a drop function for the bounding set, and people just don't think they should use it in reverse mode - Sapir-Whorf Hypothesis in operation! ;)
edit: seems like the author have a different reason though
Ditto for the seccomp syscall (and args) blacklist, although I wouldn't describe it as "worrying" considering the disclaimer at the top. Jess Frazelle's contained.af uses a seccomp whitelist[1], which doesn't need to be that long to allow reasonable programs to execute.
This is a very good piece of writing with extensive references and I'll definitely find this useful to share in the future. She documents a ton of tradeoffs she made and resources she chose not to constrain (including the aforementioned syscalls and capabilities), which is important in this type of design and something that I wish I saw more of.
Some people like to read the dead-tree version. Nostalgia, maybe paper is better for the eyes, paper books are generally lighter than the equivalent sized tablets or ebooks, etc.
True, because most of them either add a million diagrams or a million copy-pasted source code snippets. And this happens because people "respect" a thick book when they are looking for a technical book. It's quite silly, actually :)
It's kind of strange, considering that most of the non-fiction books I remember most fondly, are fairly thin. The big tomes tend to largely be forgettable (there are of course exceptions) - I guess often because they go into too much detail that date rather than concisely describing concepts.
It feels good to step through some code just using paper and pencil with all computers off. It's not for everyone, I get that, but some of us love it. I tend to walk away with a much deeper understanding of the code. I don't do it all the time nor do I need to. I reserve this ritual for truly interesting pieces of code.
I ask the same question from my wife! Some people only read on paper. We have two of each book because I read on Kindle and she reads it on the actual physical book.
Other than "active" pages with live charts and other data (which are great!), as well as Control-F (which cannot be understated), I prefer paper books on every possible way.
They're easier on my eyes. They're easy to bookmark forever. You can sort your books in a way that the physical placement of your book itself (the thickness, the colors, whatever) helps you organize or remember important details instead of just getting lost in a pile of ebooks in folders. And the backlights are bad for trying to fall asleep while reading which may sound odd, but I have the _least_ ADD when I'm about to fall asleep and everything calms down so I learn the best.
I use ebooks, but I absolutely prefer the real thing whenever possible.
And I say all of this as someone who has given away all of his DVDs and won't buy BluRays for his movie collection. I'd rather just rip something and dump it to my hard drive. Those little DVD boxes were filling many shelves and I was like "Why? All I do is watch them. And the bloody intro ads treat me like I'm a pirate for buying them."
So my point there is, I'm not just some sentimental person who clings to physical things. I like my physical books because they're better for me.
But, I'm not some zealot who thinks, "Anyone who uses ebooks is wrong/worse/whatever."
I get distracted a lot when I read online. The browser is one click a way. With a book you can sit away from your computer, underline. Diagrams look better. You can focus more.
Printed out works are less distracting, you can also write on them with a pencil or highlight things you like. Also if the page ever disappears / becomes inaccessible you have a backup of it. Not something I do, but I can see the uses. A coworker did it to analyze someone else's code. Also it doesn't drain your eyes as much. I sometimes wish I could have a Kindle that just showed me code (with some syntax highlighting) so I could look at code on an e-reader type of display but never drain my eyes doing so.
> Also if the page ever disappears / becomes inaccessible you have a backup of it.
I get the other parts, but this is the one thing where having it in a computer format would be _more_ practical. :-) I would rather go the opposite way, i.e. scan physical book for the purpose of keeping a backup.
To soak up new code, infrastructure diagrams, etc I’ll print it all all, 3 hole punch it, and put it in a binder to leaf through with a pen or highlighter on the couch.
So much more information is retained I find doing it this way over using Visio or Sublime.
Because viewing things on a LCD is hard on the eyes after a while. E-ink is great, but paper is easier for most.
This is one thing I hate about Apple these days. They once had pdf versions of all the developer documents but now they only have web pages and Xcode. For a company so concerned about users, they sure don’t seem to care about developer’s eye strain.
Not having an easily printable document also means you cant leave one or multiple copies of an important document around the workspace for convenient reference and as a physical reminder or even a prompt for discussion.
The Apple HIG (Human Interface Guidelines) used to be a great document to have printed out and left lying around for reference, and as a starting point for discussion.
Anyways, I find reading on paper so much better than reading E-Ink as well, got a Kindle paperwhite, and it's out of battery somewhere because highlighting and note-taking (I do it a lot while studying) feels so much better with physical copies. Only reason for me to take the Kindle for a walk is when I'm traveling and weight is a concern.
I like to go to the first few commits of some repositories to see how the initial proof of concept was implemented. Docker was one that surprised me. Turns out that the core of it was mounting some folders with union fs and providing an API to track its location and status [1].
She mentions five Linux kernel mechanisms – "namespaces", "capabilities", "cgroups", and "setrlimit". Is any of those what I should use if I want to run an application inside some kind of container that lets me intercept file system calls (for example for the purpose of creating a file on the fly as it is accessed)?
Seccomp with ptrace is the way I'd do this. You can setup the rules to signal the ptracing process to intercept the syscall. I've not done it before but it should be possible. Id also look at doing it in a mount namespace with overlayfs on top of everything the process can see, so that you can manipulate anything you want or need filewise without destroying the original system. Then you can copy out any changed files later if you want to preserve them.
Huh. That is interesting. _ makes me think of a placeholder in Scala. It is a totally valid e-mail address .. makes me want to add it to my own domain and use it as a junk address.
Since others are sharing lightweight container implementations, I'll throw mine in. This one is written in Scheme: http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/lin...
I like to think that there are sufficient code comments and docstrings to help demystify what is going on under the hood with containers.
Very clean and easy to read, thanks for sharing. That code is amazingly illuminating.
Thank you!
I'm reading it and I'm just wondering what this line means
specifically the #\1?
#\ is the weird syntax for character objects in Guile, so #\1 is the character "1". This expression reads a single character from userns-file and checks if it is the character "1".
what language is written in? It looks like lisp, but exceptionally readable.
Scheme, according to the file extension, .scm
Scheme, Guile in particular: https://gnu.org/s/guile
The root capabilities section is worrying. Instead of trying to exhaustively list every capability that needs to be dropped, shouldn't the code instead just list the capabilities that are allowed, and clear all the others?
This would seem to better guard against accidentally missing existing capabilities, and also protect against newer capabilities that might be added in a future kernel.
I fully agree that whitelisting is safer than blacklisting.
But on the top of the article, the author explicitly recognzied this and explained why they went down that route:
> I wanted specifically to find a minimal set of restrictions to run untrusted code. This isn't how you should approach containers on anything with any exposure: you should restrict everything you can. But I think it's important to know which permissions are categorically unsafe!
Fair point. And the article does make a good read, with explanations about why each capability in particular should be disallowed.
That's true.
I agree, you should iterate over all your existing capabilities and drop those that are not in the white-list. (I have implemented this functionality in one of my projects this way.)
BUT:
Maybe the reason some people do it otherwise, is that capabilities API have only a drop function for the bounding set, and people just don't think they should use it in reverse mode - Sapir-Whorf Hypothesis in operation! ;)
edit: seems like the author have a different reason though
Ditto for the seccomp syscall (and args) blacklist, although I wouldn't describe it as "worrying" considering the disclaimer at the top. Jess Frazelle's contained.af uses a seccomp whitelist[1], which doesn't need to be that long to allow reasonable programs to execute.
This is a very good piece of writing with extensive references and I'll definitely find this useful to share in the future. She documents a ton of tradeoffs she made and resources she chose not to constrain (including the aforementioned syscalls and capabilities), which is important in this type of design and something that I wish I saw more of.
[1]: https://github.com/jessfraz/contained.af/blob/master/seccomp...
What a fine piece of literate programming!
I've just printed it out, and it literally contains 100 page of explanation and context for that 500 lines of code. Great work!
Just curious, why print it out?
Some people like to read the dead-tree version. Nostalgia, maybe paper is better for the eyes, paper books are generally lighter than the equivalent sized tablets or ebooks, etc.
Not tech books, they usually weigh a tonne.
True, because most of them either add a million diagrams or a million copy-pasted source code snippets. And this happens because people "respect" a thick book when they are looking for a technical book. It's quite silly, actually :)
Somewhat tangentially related, I would like to know how the parent poster or for that matter printed the document.
somewhat unrelated, I don't use emacs but is there a way to break lines such as
#+caption: [[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....]
in the org mode source? https://blog.lizzie.io/linux-containers-in-500-loc.org
You can export from org to pdf (type C-c C-e l p in emacs). For some fine tuning you can export to tex and then use pdflatex.
Because many of us needed to thrust our work to thick books on the days before ubiquitous Internet. :)
It's kind of strange, considering that most of the non-fiction books I remember most fondly, are fairly thin. The big tomes tend to largely be forgettable (there are of course exceptions) - I guess often because they go into too much detail that date rather than concisely describing concepts.
It feels good to step through some code just using paper and pencil with all computers off. It's not for everyone, I get that, but some of us love it. I tend to walk away with a much deeper understanding of the code. I don't do it all the time nor do I need to. I reserve this ritual for truly interesting pieces of code.
I ask the same question from my wife! Some people only read on paper. We have two of each book because I read on Kindle and she reads it on the actual physical book.
Other than "active" pages with live charts and other data (which are great!), as well as Control-F (which cannot be understated), I prefer paper books on every possible way.
They're easier on my eyes. They're easy to bookmark forever. You can sort your books in a way that the physical placement of your book itself (the thickness, the colors, whatever) helps you organize or remember important details instead of just getting lost in a pile of ebooks in folders. And the backlights are bad for trying to fall asleep while reading which may sound odd, but I have the _least_ ADD when I'm about to fall asleep and everything calms down so I learn the best.
I use ebooks, but I absolutely prefer the real thing whenever possible.
And I say all of this as someone who has given away all of his DVDs and won't buy BluRays for his movie collection. I'd rather just rip something and dump it to my hard drive. Those little DVD boxes were filling many shelves and I was like "Why? All I do is watch them. And the bloody intro ads treat me like I'm a pirate for buying them."
So my point there is, I'm not just some sentimental person who clings to physical things. I like my physical books because they're better for me.
But, I'm not some zealot who thinks, "Anyone who uses ebooks is wrong/worse/whatever."
"They're easy to bookmark forever"
Have you ever dropped a book and lost your page? What a tragedy :)
I get distracted a lot when I read online. The browser is one click a way. With a book you can sit away from your computer, underline. Diagrams look better. You can focus more.
Printed out works are less distracting, you can also write on them with a pencil or highlight things you like. Also if the page ever disappears / becomes inaccessible you have a backup of it. Not something I do, but I can see the uses. A coworker did it to analyze someone else's code. Also it doesn't drain your eyes as much. I sometimes wish I could have a Kindle that just showed me code (with some syntax highlighting) so I could look at code on an e-reader type of display but never drain my eyes doing so.
> Also if the page ever disappears / becomes inaccessible you have a backup of it.
I get the other parts, but this is the one thing where having it in a computer format would be _more_ practical. :-) I would rather go the opposite way, i.e. scan physical book for the purpose of keeping a backup.
To soak up new code, infrastructure diagrams, etc I’ll print it all all, 3 hole punch it, and put it in a binder to leaf through with a pen or highlighter on the couch.
So much more information is retained I find doing it this way over using Visio or Sublime.
Because viewing things on a LCD is hard on the eyes after a while. E-ink is great, but paper is easier for most.
This is one thing I hate about Apple these days. They once had pdf versions of all the developer documents but now they only have web pages and Xcode. For a company so concerned about users, they sure don’t seem to care about developer’s eye strain.
Not having an easily printable document also means you cant leave one or multiple copies of an important document around the workspace for convenient reference and as a physical reminder or even a prompt for discussion.
The Apple HIG (Human Interface Guidelines) used to be a great document to have printed out and left lying around for reference, and as a starting point for discussion.
The battery never dies on a paper copy.
Also, there's no Amazon take backs.
An HTML file on your local disk does not have Amazon take backs either.
A paper copy never survives an accidental home fire.
That said, the owner might not survive as well.
Anyways, I find reading on paper so much better than reading E-Ink as well, got a Kindle paperwhite, and it's out of battery somewhere because highlighting and note-taking (I do it a lot while studying) feels so much better with physical copies. Only reason for me to take the Kindle for a walk is when I'm traveling and weight is a concern.
Yet another lightweight container runtime: bocker, docker reimplemented in about 100 lines of bash: https://github.com/p8952/bocker
Nice post! Plug for another container runtime, but in python: https://github.com/kragniz/omochabako (although it doesn't do networking or cgroups)
Writing this kind of stuff from scratch is good fun, and really helps understand the underlying kernel features.
I like to go to the first few commits of some repositories to see how the initial proof of concept was implemented. Docker was one that surprised me. Turns out that the core of it was mounting some folders with union fs and providing an API to track its location and status [1].
[1] https://github.com/moby/moby/blob/a27b4b8cb8e838d03a99b6d2b3...
Kinda cool how it's all generated from an org-mode file: https://blog.lizzie.io/linux-containers-in-500-loc.org
Really nice example of the power of literate programming in general and of org-mode's support for it in particular.
She mentions five Linux kernel mechanisms – "namespaces", "capabilities", "cgroups", and "setrlimit". Is any of those what I should use if I want to run an application inside some kind of container that lets me intercept file system calls (for example for the purpose of creating a file on the fly as it is accessed)?
Not really. You probably need to use FUSE or similar to pull something like that off.
Seccomp with ptrace is the way I'd do this. You can setup the rules to signal the ptracing process to intercept the syscall. I've not done it before but it should be possible. Id also look at doing it in a mount namespace with overlayfs on top of everything the process can see, so that you can manipulate anything you want or need filewise without destroying the original system. Then you can copy out any changed files later if you want to preserve them.
You should check out DockerSlim [0] then :-) It'll generate a seccomp profile for you and it uses ptrace too.
[0] http://dockersl.im
Is it only me or both firefox and chromium refuse to connect with something like ERR_SSL_PROTOCOL_ERROR?
off-topic, but that's a pretty cool e-mail address she's got :-) I wonder how many clients fail on it.
Huh. That is interesting. _ makes me think of a placeholder in Scala. It is a totally valid e-mail address .. makes me want to add it to my own domain and use it as a junk address.