5 ms·

Good work, but I'm afraid that this will not really catch on because it's not that portable. I also think that Bazel has the same problem; most of the sandboxin

Good work, but I'm afraid that this will not really catch on because it's not that portable. I also think that Bazel has the same problem; most of the sandboxing works only on Linux. Until something like this works on Windows, it won't get wide adoption. And it is possible to do something like this on Windows. And personally, I would want to avoid the use of GNU make. Nevertheless, this is a step forward for those who have to use GNU make.

__float 4y ago
Bazel uses "sandbox-exec" on macOS, and has a more generic POSIX compatible sandbox if you can't use the Linux sandboxing tool too. > And it _is_ possible to do something like this on Windows. Are you able to point to any open source examples of this? Bazel supports Windows, and I'm sure they'd love to be able to support sandboxing on Windows as well.
- ghoward 4y ago
  It can be done on Windows, but not how Bazel would want to do it. Basically, the sandbox has to be in the interpreter. And I guess I should be clear that it still won't be be as good as on Linux. By the way, what's this "POSIX compatible sandbox"? chroot? That's not POSIX compatible.
  - __float 4y ago
    What interpreter? Why do you assert that it's "not how Bazel would want to do it"? No, it's not chroot -- it uses a tree of symlinks, created specifically for each process being run, that assumes the process isn't trying to escape the 'sandbox' too much. At the end of the day, a _strong_ sandbox is going to require some OS-specific support, and this could be seen as a kind of graceful degradation when there's not a better OS-provided sandboxing tool. (As an aside, your comments seem rather combative and I don't really understand why; we can discuss the merits of this tool without declaring it'll never catch on and won't _do enough_ for your standards.)
    - ghoward 4y ago
      Why do my comments seem combative? All I said was basically good job, but it will unfortunately not be used much. Why is that combative? With regards to chroot, I stand corrected. I knew it was a tree of symlinks, but I thought it was also more than that because symlinks alone don't seem like a sandbox. Honestly, Cosmopolitan's system appears to be more of a sandbox than that. I agree that a strong sandbox is going to require OS-specific support as of right now. I do have ideas for implementing sandboxes without it, but it requires putting the sandbox into the interpreter. And I could be completely wrong that the interpreter would do a good enough job. And this is what I mean by interpreter: Bazel has a language. I think it's called Starlark. To make that language useful, it needs some interpreter. That intepreter might just be reading the language and building a dependency tree, but my point is that it could do more, including checks. Perhaps my assertion that Bazel would not want to do it that way is not fair, but I said that because Bazel's method of sandboxing is different, and I suspect that they would not want to refactor their Starlark interpreter. That's all. They certainly could, and I would encourage them to. So I could be wrong, and I would eat my words in that case.
      - mastax 4y ago
        > but my point is that it could do more, including checks. Could you explain more how you see this working? For example: the build system is running a build step. It has determined the inputs and the outputs for that build step. It is going to execute a subprocess for that build step (say, GCC). It wants to ensure that GCC doesn't accidentally depend on files other than thaie that the build system knows about. How can that functionality be implemented with checks in the build system interpreter? I suppose it could run the process with something strace-like and monitor which files it accesses but isn't that just a way of implementing a sandbox? I'm not sure what you mean exactly.
        gavinhoward 4y ago
        The best way to do this is best described in the thesis that Eelco Dolstra wrote describing Nix. I suggest you read that. tl;dr: Clear the environment, know where all of the system headers are, control the build environment of the dependencies. Basically, knowing dependencies means controlling them. But to expand on that, an interpreter could do some basic checking like: * Does the command reference a path that the build system doesn't know about? * Does the build system know where the executable is for the command, and is it well-known? Things like that. It won't be perfect, but it would be better. And it can get better with time.
- MaulingMonkey 4y ago
  Chromium's sandboxing code, design documents, etc. are a good read for one of the most widely deployed and battle tested windows sandboxes, and is presumably BSD 3-Clause "New"/"Revised" Licensed like the rest of Chromium: https://github.com/chromium/chromium/blob/main/docs/design/sandbox.md https://github.com/chromium/chromium/blob/main/docs/design/s... https://github.com/chromium/chromium/tree/main/sandbox/win/src https://github.com/chromium/chromium/tree/main/sandbox/win/s... https://github.com/chromium/chromium/tree/main/sandbox https://github.com/chromium/chromium/tree/main/sandbox Chromium's unveil equivalent on windows is to: 1. Have an "unsandboxed" broker/parent process that implements unveil-like logic for whitelisting files. 2. Have the sandboxed child process run under a heavily restricted access token that blocks "all" file I/O (except, null security FAT32 mounts are sadly still accessible). 3. Intercept/patch Win32 API calls to request whitelisted things via IPC with the broker process that would otherwise be blocked by the restricted access token. Bazel/Make are in slightly trickier situations, in that they run third party binaries - which might require shenannigans involving injecting DLLs, or creating patched EXEs, to do the intercepting/patching of `CreateFile` etc.
3836293648 4y ago
It is portable. That's the whole point of cosmopolitan binaries. Sure, there's probably a bunch of ugly hacks in cosmopolitan libc, but it works.
- ghoward 4y ago
  Does Cosmopolitan's Landlocking work on anything besides Linux? By definition, that cannot be the case because Landlock is a Linux thing. Cosmopolitan is portable, yes, but this sandboxing is not.
  - jart 4y ago
    The Landlock Make binary runs on OpenBSD too, where it also supports sandboxing. But those are the only two platforms right now where it's fully-featured. As I mentioned in the article, the next logical step is to add FreeBSD support using jails. The other platforms, I'm not so sure about. Might have to do something like run the binary in a blinkenlights emulator to intercept the system calls of programs we didn't build ourselves. But it's kind of a moot point, since every platform supports spinning up a Linux thing that lets you build code. On Windows you have WSL. On Mac you have Docker. So I don't know why people are egging on with the portability angle. I mean, just having unveil() on Linux in addition to OpenBSD is HUGE! We've been waiting decades for this, and now it's finally here, thanks to Landlock!
    - ghoward 4y ago
      After having used unveil() in OpenBSD, I don't really agree that it's huge. Not until it's everywhere. In fact, that's the reason I'm egging on portability: until it's everywhere, it doesn't really matter, and all the world is not a Linux or an OpenBSD. And while WSL and Docker might exist on those platforms, they are still hobbled. They're both VM's, not native. Oh, and the other reason that unveil() is not huge is because it's voluntary for programs that use them. That's why using pledge() and unveil() for regular programs is not huge and never was. Sure, it can help you identify missing dependencies. That's great, sure. Your work here is good because any GNU Makefile can be sandboxed. That's good. That is actually not voluntary for build scripts because they won't usually unveil() things. That is a step forward, which is why I said that in my first comment. But the real problem in build systems is making sure that build scripts and the software they build cannot do anything bad to machines. Look at all the protest malware with the Russia situation, as well as other instances of supply chain attacks. Using pledge() and unveil() can help with the build scripts problem, but not the actual software. Unless you patch yourself, which you can do, but that's manual, and people aren't going to bother. And then there are the limits: on OpenBSD, they tell you not to unveil() just the paths passed on the command-line, at least last I checked. That's kind of dumb. I hope Cosmopolitan on Linux does not have that issue because that's a big limitation. It means, for example, that my `bc` cannot use unveil() until after it processes the files given to it by the user, i.e., only when it starts reading from stdin. If that were not the case, I could have called unveil() as soon as all command-line arguments were processed. Anyway, the point is that yes, this is a step forward, for Linux, but we need an automated way of checking for supply chain attacks in software, not just builds.

__float 4y ago

Bazel uses "sandbox-exec" on macOS, and has a more generic POSIX compatible sandbox if you can't use the Linux sandboxing tool too. > And it _is_ possible to do something like this on Windows. Are you able to point to any open source examples of this? Bazel supports Windows, and I'm sure they'd love to be able to support sandboxing on Windows as well.

ghoward 4y ago
It can be done on Windows, but not how Bazel would want to do it. Basically, the sandbox has to be in the interpreter. And I guess I should be clear that it still won't be be as good as on Linux. By the way, what's this "POSIX compatible sandbox"? chroot? That's not POSIX compatible.
- __float 4y ago
  What interpreter? Why do you assert that it's "not how Bazel would want to do it"? No, it's not chroot -- it uses a tree of symlinks, created specifically for each process being run, that assumes the process isn't trying to escape the 'sandbox' too much. At the end of the day, a _strong_ sandbox is going to require some OS-specific support, and this could be seen as a kind of graceful degradation when there's not a better OS-provided sandboxing tool. (As an aside, your comments seem rather combative and I don't really understand why; we can discuss the merits of this tool without declaring it'll never catch on and won't _do enough_ for your standards.)
  - ghoward 4y ago
    Why do my comments seem combative? All I said was basically good job, but it will unfortunately not be used much. Why is that combative? With regards to chroot, I stand corrected. I knew it was a tree of symlinks, but I thought it was also more than that because symlinks alone don't seem like a sandbox. Honestly, Cosmopolitan's system appears to be more of a sandbox than that. I agree that a strong sandbox is going to require OS-specific support as of right now. I do have ideas for implementing sandboxes without it, but it requires putting the sandbox into the interpreter. And I could be completely wrong that the interpreter would do a good enough job. And this is what I mean by interpreter: Bazel has a language. I think it's called Starlark. To make that language useful, it needs some interpreter. That intepreter might just be reading the language and building a dependency tree, but my point is that it could do more, including checks. Perhaps my assertion that Bazel would not want to do it that way is not fair, but I said that because Bazel's method of sandboxing is different, and I suspect that they would not want to refactor their Starlark interpreter. That's all. They certainly could, and I would encourage them to. So I could be wrong, and I would eat my words in that case.
    - mastax 4y ago
      > but my point is that it could do more, including checks. Could you explain more how you see this working? For example: the build system is running a build step. It has determined the inputs and the outputs for that build step. It is going to execute a subprocess for that build step (say, GCC). It wants to ensure that GCC doesn't accidentally depend on files other than thaie that the build system knows about. How can that functionality be implemented with checks in the build system interpreter? I suppose it could run the process with something strace-like and monitor which files it accesses but isn't that just a way of implementing a sandbox? I'm not sure what you mean exactly.
      - gavinhoward 4y ago
        The best way to do this is best described in the thesis that Eelco Dolstra wrote describing Nix. I suggest you read that. tl;dr: Clear the environment, know where all of the system headers are, control the build environment of the dependencies. Basically, knowing dependencies means controlling them. But to expand on that, an interpreter could do some basic checking like: * Does the command reference a path that the build system doesn't know about? * Does the build system know where the executable is for the command, and is it well-known? Things like that. It won't be perfect, but it would be better. And it can get better with time.
MaulingMonkey 4y ago
Chromium's sandboxing code, design documents, etc. are a good read for one of the most widely deployed and battle tested windows sandboxes, and is presumably BSD 3-Clause "New"/"Revised" Licensed like the rest of Chromium: https://github.com/chromium/chromium/blob/main/docs/design/sandbox.md https://github.com/chromium/chromium/blob/main/docs/design/s... https://github.com/chromium/chromium/tree/main/sandbox/win/src https://github.com/chromium/chromium/tree/main/sandbox/win/s... https://github.com/chromium/chromium/tree/main/sandbox https://github.com/chromium/chromium/tree/main/sandbox Chromium's unveil equivalent on windows is to: 1. Have an "unsandboxed" broker/parent process that implements unveil-like logic for whitelisting files. 2. Have the sandboxed child process run under a heavily restricted access token that blocks "all" file I/O (except, null security FAT32 mounts are sadly still accessible). 3. Intercept/patch Win32 API calls to request whitelisted things via IPC with the broker process that would otherwise be blocked by the restricted access token. Bazel/Make are in slightly trickier situations, in that they run third party binaries - which might require shenannigans involving injecting DLLs, or creating patched EXEs, to do the intercepting/patching of `CreateFile` etc.

3836293648 4y ago

It is portable. That's the whole point of cosmopolitan binaries. Sure, there's probably a bunch of ugly hacks in cosmopolitan libc, but it works.

ghoward 4y ago
Does Cosmopolitan's Landlocking work on anything besides Linux? By definition, that cannot be the case because Landlock is a Linux thing. Cosmopolitan is portable, yes, but this sandboxing is not.
- jart 4y ago
  The Landlock Make binary runs on OpenBSD too, where it also supports sandboxing. But those are the only two platforms right now where it's fully-featured. As I mentioned in the article, the next logical step is to add FreeBSD support using jails. The other platforms, I'm not so sure about. Might have to do something like run the binary in a blinkenlights emulator to intercept the system calls of programs we didn't build ourselves. But it's kind of a moot point, since every platform supports spinning up a Linux thing that lets you build code. On Windows you have WSL. On Mac you have Docker. So I don't know why people are egging on with the portability angle. I mean, just having unveil() on Linux in addition to OpenBSD is HUGE! We've been waiting decades for this, and now it's finally here, thanks to Landlock!
  - ghoward 4y ago
    After having used unveil() in OpenBSD, I don't really agree that it's huge. Not until it's everywhere. In fact, that's the reason I'm egging on portability: until it's everywhere, it doesn't really matter, and all the world is not a Linux or an OpenBSD. And while WSL and Docker might exist on those platforms, they are still hobbled. They're both VM's, not native. Oh, and the other reason that unveil() is not huge is because it's voluntary for programs that use them. That's why using pledge() and unveil() for regular programs is not huge and never was. Sure, it can help you identify missing dependencies. That's great, sure. Your work here is good because any GNU Makefile can be sandboxed. That's good. That is actually not voluntary for build scripts because they won't usually unveil() things. That is a step forward, which is why I said that in my first comment. But the real problem in build systems is making sure that build scripts and the software they build cannot do anything bad to machines. Look at all the protest malware with the Russia situation, as well as other instances of supply chain attacks. Using pledge() and unveil() can help with the build scripts problem, but not the actual software. Unless you patch yourself, which you can do, but that's manual, and people aren't going to bother. And then there are the limits: on OpenBSD, they tell you not to unveil() just the paths passed on the command-line, at least last I checked. That's kind of dumb. I hope Cosmopolitan on Linux does not have that issue because that's a big limitation. It means, for example, that my `bc` cannot use unveil() until after it processes the files given to it by the user, i.e., only when it starts reading from stdin. If that were not the case, I could have called unveil() as soon as all command-line arguments were processed. Anyway, the point is that yes, this is a step forward, for Linux, but we need an automated way of checking for supply chain attacks in software, not just builds.