6 ms·

Google SAPI: Generate sandboxes for C/C++ libraries automatically

78 points by harporoeder 5y ago

ridiculous_fish 5y ago
It appears this is Linux only? From Getting Started: "Linux kernel with support for UTS, IPC, user, PID and network namespaces"
a-dub 5y ago
while this looks cool, this is also getting out of hand. we need an operating system that doesn't require all this machinery on top in order to achieve basic encapsulation.
- otabdeveloper4 5y ago
  As far as I can tell from 30 seconds of research, this thing just bundles standard Linux syscalls in one package. "This machinery" is just typical Google overengineering, it's not doing anything except acting as middleware. P.S. Yeah, I wish we had a better userspace Linux namespace toolkit instead of Docker.
  - spockz 5y ago
    What about podman?
  - melony 5y ago
    So gVisor for C++?
  - a-dub 5y ago
    i think namespaces are the wrong abstraction. it's a good solution given what exists (posix/linux), but way more hacky than something new with encapsulation of machine code by source being a first class design principle.
    - otabdeveloper4 5y ago
      Wrong for what exactly? I just want to run my apps with a separate TCP port namespace :)
      - a-dub 5y ago
        the whole idea that you have to fork process tables, user tables, network tables and filesystems to achieve encapsulation between applications is a product of the old unix security model not being sufficient for what people are actually using these systems for today. so the popularity of containers (namespaces) and the entire ecosystem of tools like this (dating all the way back to chroots and bsd jails) basically says to me that maybe a fresh approach to security features in an operating system would lead to less complexity than what has needed to be built on top of good ol' unix.
        otabdeveloper4 5y ago
        If I wanted security then namespaces aren't the tool I would use. (And I don't think they were ever intended as a security feature.)
        a-dub 5y ago
        yeah i suppose you're right, point still stands. having to chop up all the kernel tables to run little mini systems just to deploy software correctly, along with choosing from a whole host of bolt on capabilities systems and sandboxing technologies makes it seem like the services provided by base unix for modern computing are looking a bit long in the tooth.
- liuliu 5y ago
  Not sure how to do that from OS perspective without introducing some kind of module concept (either through shared object or some other ways). The SAPI solution seems pretty straightforward to me. Jail the particular library into a sandboxed process and IPC with it transparently. Compatibility will be tricky (especially for libraries that is more complicated). But the solution itself is straightforward and I can see it work.
  - a-dub 5y ago
    yup. we need an operating system and hardware that sandboxes all code and state that runs on it by source, yet still has fast interfaces between units and avoids overt complexity by bolting facilities for this on top.
  - Findecanor 5y ago
    Check out ELFbac: (http://elfbac.org/ http://elfbac.org/) It extracts "programmer intent" from relations in the ELF format to create memory protection boundaries. It is not exactly sandboxing, but limits what a compromised program module can do.
- pabs3 5y ago
  The Hurd could do this sort of thing natively, just load the translators that you want, including a new rootfs if you want.
- taneq 5y ago
  Exactly. As far as I can tell all modern OSes are built on the assumption that users of a machine need protection from each other, rather than that each user needs protection from the third party code that they run.
  - iggldiggl 5y ago
    > user needs protection from the third party code that they run Unfortunately the above then often crosses the line over into "protecting the user from actually accomplishing useful stuff". The file sandboxing approaches I've seen so for e.g. commonly ignore the existence of file formats that don't consist of a single, atomic file.
- jagrsw 5y ago
  Hi, one of the project's co-authors here (SAPI). I think you might want to take a look at https://fuchsia.dev/ https://fuchsia.dev/ - although I haven't worked with it myself so far, the stated goals might be somewhat in line with what you're proposing here.
stillicidious 5y ago
They couldn't have made the client stub interface more baroque if they tried. It sounded like something that could mimic something approaching the original library interface automatically, pretty disappointed it's basically just another RPC stubs generator If you can stomach the perf tradeoffs, compiling to WASM is much easier than this
- asdfasgasdgasdg 5y ago
  > They couldn't have made the client stub interface more baroque if they tried. I've never used this API but the cross process synchronization stuff seems like a difficult nut to crack. I'm curious which bits you think are unnecessarily baroque. > If you can stomach the perf tradeoffs, compiling to WASM is much easier than this I'm not super familiar with WASM, but it's unclear to me how compiling to that target addresses the problems that are addressed by this system? Does WASM have built-in security policies and sandboxing? Is it easy to call into a WASM-compiled library from your native C/C++ program? How?
  - codetrotter 5y ago
    > Does WASM have built-in security policies and sandboxing? Yes, WebAssembly is sandboxed. https://webassembly.org/docs/security/ https://webassembly.org/docs/security/
- noja 5y ago
  > If you can stomach the perf tradeoffs, compiling to WASM is much easier than this This WASM? https://www.theregister.com/2021/11/04/webassembly_stack_canaries/ https://www.theregister.com/2021/11/04/webassembly_stack_can...
  - feanaro 5y ago
    Those are not sandbox escapes, those are missing intra-program defences which make it easier for a e.g. buffer overflow to be used for program manipulation. That still doesn't allow you to escape the sandbox in itself.
malkia 5y ago
I hope fuchsia's fidl gets ported over for cases like this.
- pjmlp 5y ago
  Why? It is no different from any other RPC IDL.
nly 5y ago
Most of the problems in creating services by wrapping libraries in RPCs, in my experience, come from most libraries not supporting asynchrony, timeouts etc. The zlib example is a bit baffling to be honest. If zlib goes in to an infinite 100% CPU loop, perhaps due to a zip bomb, you're still screwed as far as I can tell A full RPC abstraction also gives you the opportunity to change out the backend implementation that this doesn't.
- AdmVonSchneider 5y ago
  > If zlib goes in to an infinite 100% CPU loop, perhaps due to a zip bomb, you're still screwed as far as I can tell You can set CPU and wall time limits and the sandbox will be killed if it runs for longer. > A full RPC abstraction also gives you the opportunity to change out the backend implementation that this doesn't. Absolutely, but the RPC mechanism in SAPI is an implementation detail and ideally not something you should have to care about. You can of course just use the Sandbox2 part of Sandboxed API and implement an RPC layer yourself.
DSingularity 5y ago
I’ve been looking to use this. One question, is this something we can use with a non-bazel based build system?
- AdmVonSchneider 5y ago
  In case you're using CMake instead, you may want to take a look at the `hello_sapi` example (https://github.com/google/sandboxed-api/blob/main/sandboxed_api/examples/hello_sapi/CMakeLists.txt https://github.com/google/sandboxed-api/blob/main/sandboxed_...). Other build systems will be significantly harder to integrate with.
  - DSingularity 5y ago
    Thanks!
ihnorton 5y ago
When I initially read the description, I thought this could provide a drop-in runtime-linked shared library stub, but looking deeper in the docs and examples it appears there is at least some setup code required on the client side? Can this log the RPC calls around the target C library? Or potentially even replay calls in isolation? The latter could be expensive for non-trivial programs (require saving all synchronized memory state?), but might be more viable with binary diffs of the shared state if the client side doesn't modify the synchronized memory too much.

78 points by harporoeder 5y ago

It appears this is Linux only? From Getting Started: "Linux kernel with support for UTS, IPC, user, PID and network namespaces"

a-dub 5y ago

while this looks cool, this is also getting out of hand. we need an operating system that doesn't require all this machinery on top in order to achieve basic encapsulation.

otabdeveloper4 5y ago
As far as I can tell from 30 seconds of research, this thing just bundles standard Linux syscalls in one package. "This machinery" is just typical Google overengineering, it's not doing anything except acting as middleware. P.S. Yeah, I wish we had a better userspace Linux namespace toolkit instead of Docker.
- spockz 5y ago
  What about podman?
- melony 5y ago
  So gVisor for C++?
- a-dub 5y ago
  i think namespaces are the wrong abstraction. it's a good solution given what exists (posix/linux), but way more hacky than something new with encapsulation of machine code by source being a first class design principle.
  - otabdeveloper4 5y ago
    Wrong for what exactly? I just want to run my apps with a separate TCP port namespace :)
    - a-dub 5y ago
      the whole idea that you have to fork process tables, user tables, network tables and filesystems to achieve encapsulation between applications is a product of the old unix security model not being sufficient for what people are actually using these systems for today. so the popularity of containers (namespaces) and the entire ecosystem of tools like this (dating all the way back to chroots and bsd jails) basically says to me that maybe a fresh approach to security features in an operating system would lead to less complexity than what has needed to be built on top of good ol' unix.
      - otabdeveloper4 5y ago
        If I wanted security then namespaces aren't the tool I would use. (And I don't think they were ever intended as a security feature.)
        a-dub 5y ago
        yeah i suppose you're right, point still stands. having to chop up all the kernel tables to run little mini systems just to deploy software correctly, along with choosing from a whole host of bolt on capabilities systems and sandboxing technologies makes it seem like the services provided by base unix for modern computing are looking a bit long in the tooth.
liuliu 5y ago
Not sure how to do that from OS perspective without introducing some kind of module concept (either through shared object or some other ways). The SAPI solution seems pretty straightforward to me. Jail the particular library into a sandboxed process and IPC with it transparently. Compatibility will be tricky (especially for libraries that is more complicated). But the solution itself is straightforward and I can see it work.
- a-dub 5y ago
  yup. we need an operating system and hardware that sandboxes all code and state that runs on it by source, yet still has fast interfaces between units and avoids overt complexity by bolting facilities for this on top.
- Findecanor 5y ago
  Check out ELFbac: (http://elfbac.org/ http://elfbac.org/) It extracts "programmer intent" from relations in the ELF format to create memory protection boundaries. It is not exactly sandboxing, but limits what a compromised program module can do.
pabs3 5y ago
The Hurd could do this sort of thing natively, just load the translators that you want, including a new rootfs if you want.
taneq 5y ago
Exactly. As far as I can tell all modern OSes are built on the assumption that users of a machine need protection from each other, rather than that each user needs protection from the third party code that they run.
- iggldiggl 5y ago
  > user needs protection from the third party code that they run Unfortunately the above then often crosses the line over into "protecting the user from actually accomplishing useful stuff". The file sandboxing approaches I've seen so for e.g. commonly ignore the existence of file formats that don't consist of a single, atomic file.
jagrsw 5y ago
Hi, one of the project's co-authors here (SAPI). I think you might want to take a look at https://fuchsia.dev/ https://fuchsia.dev/ - although I haven't worked with it myself so far, the stated goals might be somewhat in line with what you're proposing here.

stillicidious 5y ago

They couldn't have made the client stub interface more baroque if they tried. It sounded like something that could mimic something approaching the original library interface automatically, pretty disappointed it's basically just another RPC stubs generator If you can stomach the perf tradeoffs, compiling to WASM is much easier than this

asdfasgasdgasdg 5y ago
> They couldn't have made the client stub interface more baroque if they tried. I've never used this API but the cross process synchronization stuff seems like a difficult nut to crack. I'm curious which bits you think are unnecessarily baroque. > If you can stomach the perf tradeoffs, compiling to WASM is much easier than this I'm not super familiar with WASM, but it's unclear to me how compiling to that target addresses the problems that are addressed by this system? Does WASM have built-in security policies and sandboxing? Is it easy to call into a WASM-compiled library from your native C/C++ program? How?
- codetrotter 5y ago
  > Does WASM have built-in security policies and sandboxing? Yes, WebAssembly is sandboxed. https://webassembly.org/docs/security/ https://webassembly.org/docs/security/
noja 5y ago
> If you can stomach the perf tradeoffs, compiling to WASM is much easier than this This WASM? https://www.theregister.com/2021/11/04/webassembly_stack_canaries/ https://www.theregister.com/2021/11/04/webassembly_stack_can...
- feanaro 5y ago
  Those are not sandbox escapes, those are missing intra-program defences which make it easier for a e.g. buffer overflow to be used for program manipulation. That still doesn't allow you to escape the sandbox in itself.

malkia 5y ago

I hope fuchsia's fidl gets ported over for cases like this.

pjmlp 5y ago
Why? It is no different from any other RPC IDL.

nly 5y ago

Most of the problems in creating services by wrapping libraries in RPCs, in my experience, come from most libraries not supporting asynchrony, timeouts etc. The zlib example is a bit baffling to be honest. If zlib goes in to an infinite 100% CPU loop, perhaps due to a zip bomb, you're still screwed as far as I can tell A full RPC abstraction also gives you the opportunity to change out the backend implementation that this doesn't.

AdmVonSchneider 5y ago
> If zlib goes in to an infinite 100% CPU loop, perhaps due to a zip bomb, you're still screwed as far as I can tell You can set CPU and wall time limits and the sandbox will be killed if it runs for longer. > A full RPC abstraction also gives you the opportunity to change out the backend implementation that this doesn't. Absolutely, but the RPC mechanism in SAPI is an implementation detail and ideally not something you should have to care about. You can of course just use the Sandbox2 part of Sandboxed API and implement an RPC layer yourself.

DSingularity 5y ago

I’ve been looking to use this. One question, is this something we can use with a non-bazel based build system?

AdmVonSchneider 5y ago
In case you're using CMake instead, you may want to take a look at the `hello_sapi` example (https://github.com/google/sandboxed-api/blob/main/sandboxed_api/examples/hello_sapi/CMakeLists.txt https://github.com/google/sandboxed-api/blob/main/sandboxed_...). Other build systems will be significantly harder to integrate with.
- DSingularity 5y ago
  Thanks!

ihnorton 5y ago

When I initially read the description, I thought this could provide a drop-in runtime-linked shared library stub, but looking deeper in the docs and examples it appears there is at least some setup code required on the client side? Can this log the RPC calls around the target C library? Or potentially even replay calls in isolation? The latter could be expensive for non-trivial programs (require saving all synchronized memory state?), but might be more viable with binary diffs of the shared state if the client side doesn't modify the synchronized memory too much.