On 11/24/24 7:12 PM, Evan Carroll wrote: > A lot of words on that one, > > Not sure if you're the author of the paper. But off the get go, I'm > extremely confused. I wanted to give my critique on the paper instead of > the technology. My experience with "user-space sandboxing" is kernel > user-namespaces. My interface to them is podman. It's not clear what this > "sandbox" offers that podman's rootless mode does not. I believe I'm in the > majority with experience in containerization. But you're grounding this > paper in "two prime examples of sandbox: Gentoo's sandbox and Exherbo's > sydbox" -- things most people have probably never used. This for me raises > the question: when would I want "Gentoo's sandbox and Exherbo's sydbox" > over kernel user-namespaces and podman? > > I don't see that answer immediately and so my desire to continue reading > drops significantly. This is only constructive criticism, maybe I'm not > your desired audience but the title was interesting enough for me to jump > in.
You might want "sydbox", though I wouldn't know. I can definitely tell you that you do not want Gentoo's sandbox, which isn't a security technology at all. It's an LD_PRELOAD mechanism, and thus easily defeated by malicious software, which assumes that it is being used as a "sandbox" for innocent software that is perhaps badly written to run inside, and interjects code on regular file accesses to check whether the software was "expected" to attempt to read or write in that location. On a mismatch, it errors out verbosely and tells you that the relevant software was badly written and tried to, say, install the software to /usr/bin upon running `make DESTDIR=$PWD/rootimage/ install`, which is obviously wrong because the software has a bad Makefile that doesn't respect $DESTDIR. Of course, it can also tell you about more interesting sandbox violations, such as "attempted to download source code from https://crates.io and save it to /home/eschwartz/.cargo" which is another thing that well-meaning software might do but really shouldn't be. You wouldn't imagine in a million years using this as a security boundary. But you might use it to help catch common mistakes when building software. It dates back to 2002, when it was forked from the same codebase that was also incorporated into Debian's "checkinstall" package. ... My understanding is that sydbox is intended to be more of a competitor to bubblewrap, and happens to include profiles which exherbo uses to make it do similar tasks to Gentoo's sandbox, but that sydbox itself is much more powerful and flexible than sandbox. ... By the way, you mention "when would I want [...] over kernel user-namespaces", which I think is a complete and utter misunderstanding of the problem domain. sydbox documents that one of the technologies it uses in its source code is user namespaces. Generally, "user namespaces" isn't a program you use, it's a technique you can make use of in the source code of another program entirely... such as sydbox or at a high level, podman. From looking through the sydbox homepage, and very quickly checking for keywords such as "podman", I got pointed to this link: https://man.exherbolinux.org/syd-oci.1.html It suggests that the relevance of this software to podman is that you can use "sydbox" as an OCI runtime for podman, to replace "crun" or "runc", via: podman run --runtime=syd-oci Take that as you will. Since you're a podman user, but you don't say anything about whether you are a crun user or a runc user, I take it you don't care how you get your namespaces and would be perfectly fine using sydbox too, but won't be changing anything unless podman's own default changes? -- Eli Schwartz
OpenPGP_signature.asc
Description: OpenPGP digital signature
