oss-sec mailing list archives
Re: sandboxing,of upstream programs by distros
From: Mickaël Salaün <mic () digikod net>
Date: Sun, 22 Oct 2023 11:50:12 +0200
On Sun, Oct 22, 2023 at 02:06:49AM +0200, Solar Designer wrote:
Hi Matt, I'm sorry I didn't follow up on this sooner. On Sat, Oct 14, 2023 at 06:39:49PM +1100, Matthew Fernandez wrote:Is there interest/solutions within the Rock Security SIG or other distro's security teams for sandboxing that package upstreams can opt into?For Rocky Linux Security SIG, the only relevant thing mentioned so far was possibly offering an OpenBSD pledge()-alike that other packages could use. However, I am skeptical any actually would, unless we also introduce such uses ourselves and maintain own "override" packages (replacing RHEL rebuild ones or those coming from EPEL, etc.) of such software. Initially, we are going to only create "override' packages for core or very commonly used/exposed components, and to do so only for specific good reasons. So stuff like e.g. ImageMagick/GraphicsMagick coming from EPEL and with most of its dependency libraries coming from AppStream repos, or e.g. GraphViz coming from AppStream, is unlikely to make the cut, at least not initially. Also, continuing these examples, it's probably more realistic to sandbox their command-line tools, whereas the underlying libraries are probably more exposed via language bindings. Would we be introducing creation of child processes into the libraries? That's tricky as it could violate expectations of programs using such libraries. (Yet at Openwall we did a similar thing in pam_tcb, albeit limiting this maybe-unexpected behavior to setups that opted-in to it with the "fork" option in the PAM configuration file. So it's not completely out of consideration.)
The Sandboxed API may be used to transform libraries into sandboxed services, but this might not be the best choice because it would indeed change the set of processes (with the related additional complexity), and it might not be as fine-grained as a CLI sandboxing (because CLI gets the full semantic). See https://github.com/google/sandboxed-api
Speaking of pledge() for Linux, there's this project by Justine Tunney: https://justine.lol/pledge/ https://github.com/jart/cosmopolitan/blob/master/libc/calls/pledge-linux.c This is part of Justine's libc implementation, but a comment says: * This file contains only the minimum amount of Linux-specific code * that's necessary to get a pledge() policy installed. This file is * designed to not use static or tls memory or libc depnedencies, so * it can be transplanted into codebases and injected into programs. Are there already other projects using this? Any distros offering it?
This Pledge implementation is useful to quickly leverage OpenBSD's patched software, but for a Linux fine-grained sandboxing it would be wiser to use the underlying kernel sandboxing feature: Landlock See https://landlock.io/ AFAIK one of the most widely used sandboxing C library leveraging Landlock is Minijail: https://chromium.googlesource.com/chromiumos/platform/minijail Libraries are available for other languages as well: * Rust: https://crates.io/crates/landlock * Go: https://pkg.go.dev/github.com/landlock-lsm/go-landlock/landlock * Haskell: https://hackage.haskell.org/package/landlock * Python: https://github.com/Edward-Knight/landlock
To step this out a bit... we have a large, old code base that was written decades prior to current best practices. It has numerous known memory safety issues and ever-dwindling maintainer capacity. It is also a dependency, either directly or indirectly, of a significant fraction of the world's software. I am guessing this scenario sounds uncomfortably familiar/common to many on this list. We (the maintainers) have discussed sandboxing as a way of mitigating the risk of known bugs. However, one of the problems is that we don't know the complete set of required privileges of our dependencies. The software can be configured with or without various libraries and also has a plugin mechanism for dynamic code loading. Basically if a sandboxing solution like seccomp wants to know our full set of system calls, we ourselves don't know it.With pledge(), you could provide coarse-grained "promises" rather than constrain yourself to individual syscalls. Maybe that would work for you? However, it'd only be reliably used by packages if those introduce a build-time dependency on whatever package provides pledge(). So e.g. if we add a package providing pledge() in Rocky Linux Security SIG repo, that won't be picked up by my example packages above built as part of EPEL (not part of Rocky Linux project) or AppStream (part of the project, but currently unlikely to be overridden in the SIG). OTOH, you could even integrate the pledge-linux.c file in your project, in which case it could become a standard feature used by many Linux distros and extra package repos once they update to your newer version.
FYI, Landlock is gaining new sandboxing features with new kernel versions, so we should be careful to make it easy to update to new features and then avoid (too much) harcoded constants/files but rely on a library instead.
The downstream maintainer packaging the software for, e.g. Rocky, does though. They have a complete picture of which libraries/features are enabled and how locked down the plugin stuff is. So, where I'm going with this, is that if the various packaging ecosystems could (or do) offer sandboxing to upstream, people like us would gladly opt in to it. Of course, these downstream maintainers can already seccomp our software today. But expecting them to reverse engineer our exact needs seems a bit much.I find the above two paragraphs somewhat contradictory - the downstream maintainer packaging the software does have technical ability to figure out the exact set of syscalls the software will use on their distro with current versions of other packages, but OTOH "expecting them to reverse engineer our exact needs seems a bit much." I'd say that figuring out that exact set _is_ this kind of reverse-engineering, and is too much to expect from a typical package maintainer, who is not focusing on just this one package. Besides, the exact set of syscalls may also change as other packages get updated; this is not something guaranteed to stay stable within what's normally considered a stable ABI. So that person would also need to identify and introduce extra explicit package version dependencies, and to do extra package rebuilds to keep those satisfied.
Proper sandboxing features such as Landlock are not tied to syscalls (which might change with library and dependency updates). Being able to integrate some security policy with the packaging would definitely help to widespread sandboxing (but cannot be as fine-grained as built-in sandboxing).
Maybe a coarse-grained pledge() would make this more realistic, or not.
Pledge, and especially the Linux implementation, is already coarse-grained. Mickaël
Current thread:
- sandboxing,of upstream programs by distros Matthew Fernandez (Oct 14)
- Re: sandboxing,of upstream programs by distros Demi Marie Obenour (Oct 14)
- Re: sandboxing,of upstream programs by distros Matthew Fernandez (Oct 14)
- Re: sandboxing,of upstream programs by distros Solar Designer (Oct 21)
- Re: sandboxing,of upstream programs by distros Demi Marie Obenour (Oct 22)
- Re: sandboxing,of upstream programs by distros Bob Friesenhahn (Oct 22)
- Re: sandboxing,of upstream programs by distros Demi Marie Obenour (Oct 22)
- Re: sandboxing,of upstream programs by distros Bob Friesenhahn (Oct 22)
- Re: sandboxing,of upstream programs by distros Demi Marie Obenour (Oct 22)
- Re: sandboxing,of upstream programs by distros Demi Marie Obenour (Oct 14)
- Re: sandboxing,of upstream programs by distros Mickaël Salaün (Oct 22)
- Re: sandboxing,of upstream programs by distros Matthew Fernandez (Oct 22)