Our great sponsors
-
From a comment upthread:
> Also please consider that GNU Make supports so many ancient platforms, like DOS, QDOS, Amiga, Windows 3.1. When I forked GNU Make, the first thing I did was delete all that support for ancient defunct platforms to give me enough room to think about how to approach implementing this feature.
- https://news.ycombinator.com/item?id=32376870
From https://github.com/jart/cosmopolitan#support-vector , supported platforms are Windows, Linux, Mac OS X, FreeBSD, OpenBSD, and NetBSD, on AMD and Intel x86 processors. That's a large list, maybe large enough to become widely accepted, but GNU Make supports ... pretty much everything, ever. Darwin on ARM (probably the most important), NetBSD on MIPS, Solaris on SPARC, FreeBSD on POWER, Haiku, FreeDOS, HURD.
Cosmopolitan is probably portable enough and Landlock is probably portable enough to catch on, but compared to make(1), it's not that portable.
-
> 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.
To be totally clear: the tree of symlinks thing is a fallback, used only when lacking platform support or when sandboxing is explicitly turned off [0]. On Linux, the normal sandboxing strategy is to use namespaces, like most container runtimes. On Mac it apparently uses sandbox-exec (some opaque Apple tool), as was mentioned above. Chroot, being both non-POSIX, requiring root access on many systems, and not providing the necessary facilities is not really a great fit -- which I assume is why it's not used.
There was experimental Windows sandbox support at one point [1] based on how MS does it for BuildXL (their own build tool for giant monorepos) [2]. Unfortunately it doesn't seem to be maintained, and under the hood it's kinda ugly -- it actively rewrites code in-memory to intercept calls to the Win32 APIs [3], which was apparently the cleanest/best way MS could come up with. However, from Bazel's POV it works in a roughly similar way -- you spawn subprocesses under a supervisor, which is in charge of spinning up whatever the target process is with restrictions on time/memory usage/file access.
On the "sandbox in the interpreter" thing: what kind of checks are you envisioning? It seems like putting checks at that level would end up leaving a lot out -- the goal of any build system is to eventually spawn an arbitrary process (Python, gcc, javac, some shell script, etc.) and so even with extensive checks in starlark you'd end up with accidental sandbox breaks all over the place. For pure starlark rules you could e.g. check that there are no inputs from /usr, but even then if gcc does it implicitly, you're SOL. Or am I thinking of the wrong kind of checks?
[0] https://bazel.build/docs/sandboxing#sandboxing-strategies
[1] https://github.com/bazelbuild/bazel/issues/5136#issuecomment...
[2] https://github.com/microsoft/BuildXL/blob/master/Documentati...
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
> 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.
To be totally clear: the tree of symlinks thing is a fallback, used only when lacking platform support or when sandboxing is explicitly turned off [0]. On Linux, the normal sandboxing strategy is to use namespaces, like most container runtimes. On Mac it apparently uses sandbox-exec (some opaque Apple tool), as was mentioned above. Chroot, being both non-POSIX, requiring root access on many systems, and not providing the necessary facilities is not really a great fit -- which I assume is why it's not used.
There was experimental Windows sandbox support at one point [1] based on how MS does it for BuildXL (their own build tool for giant monorepos) [2]. Unfortunately it doesn't seem to be maintained, and under the hood it's kinda ugly -- it actively rewrites code in-memory to intercept calls to the Win32 APIs [3], which was apparently the cleanest/best way MS could come up with. However, from Bazel's POV it works in a roughly similar way -- you spawn subprocesses under a supervisor, which is in charge of spinning up whatever the target process is with restrictions on time/memory usage/file access.
On the "sandbox in the interpreter" thing: what kind of checks are you envisioning? It seems like putting checks at that level would end up leaving a lot out -- the goal of any build system is to eventually spawn an arbitrary process (Python, gcc, javac, some shell script, etc.) and so even with extensive checks in starlark you'd end up with accidental sandbox breaks all over the place. For pure starlark rules you could e.g. check that there are no inputs from /usr, but even then if gcc does it implicitly, you're SOL. Or am I thinking of the wrong kind of checks?
[0] https://bazel.build/docs/sandboxing#sandboxing-strategies
[1] https://github.com/bazelbuild/bazel/issues/5136#issuecomment...
[2] https://github.com/microsoft/BuildXL/blob/master/Documentati...
-
Microsoft Research Detours Package
Detours is a software package for monitoring and instrumenting API calls on Windows. It is distributed in source code form.
> 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.
To be totally clear: the tree of symlinks thing is a fallback, used only when lacking platform support or when sandboxing is explicitly turned off [0]. On Linux, the normal sandboxing strategy is to use namespaces, like most container runtimes. On Mac it apparently uses sandbox-exec (some opaque Apple tool), as was mentioned above. Chroot, being both non-POSIX, requiring root access on many systems, and not providing the necessary facilities is not really a great fit -- which I assume is why it's not used.
There was experimental Windows sandbox support at one point [1] based on how MS does it for BuildXL (their own build tool for giant monorepos) [2]. Unfortunately it doesn't seem to be maintained, and under the hood it's kinda ugly -- it actively rewrites code in-memory to intercept calls to the Win32 APIs [3], which was apparently the cleanest/best way MS could come up with. However, from Bazel's POV it works in a roughly similar way -- you spawn subprocesses under a supervisor, which is in charge of spinning up whatever the target process is with restrictions on time/memory usage/file access.
On the "sandbox in the interpreter" thing: what kind of checks are you envisioning? It seems like putting checks at that level would end up leaving a lot out -- the goal of any build system is to eventually spawn an arbitrary process (Python, gcc, javac, some shell script, etc.) and so even with extensive checks in starlark you'd end up with accidental sandbox breaks all over the place. For pure starlark rules you could e.g. check that there are no inputs from /usr, but even then if gcc does it implicitly, you're SOL. Or am I thinking of the wrong kind of checks?
[0] https://bazel.build/docs/sandboxing#sandboxing-strategies
[1] https://github.com/bazelbuild/bazel/issues/5136#issuecomment...
[2] https://github.com/microsoft/BuildXL/blob/master/Documentati...
-
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/s...
https://github.com/chromium/chromium/tree/main/sandbox/win/s...
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.
-
"If you want to do what "scrappy Google" did these days, then you should use Python + Ninja."
Or, better yet, use a simpler, faster and more portable^1 Ninja written in C.
https://github.com/michaelforney/samurai
1. The "simpler, faster, and more portable", are the author's claims, not mine. I am not the author.
-
This is very cool.
A while back I started an experiment/prototype called "make-audit"; this is a (draft) tool to report when an execution of GNU make reads or changes files in ways that are inconsistent with its Makefile: https://github.com/david-a-wheeler/make-audit It's nowhere ready for serious use, but it can detect the following:
* Error: Target TARGET : unreported prerequisites: SET : The make recipe for creating TARGET is reading from the prerequisites in SET, but the makefile fails to report them as dependencies. You may want to add SET to the prerequisites of TARGET.
* Error: Target TARGET : claimed but unused prerequisites: SET : The make recipe for creating TARGET claims that it depends on SET, but the items in SET were never read. You may want to remove SET from the prerequisites of TARGET.
* Error: Target TARGET : unreported target: SET The make recipe for updating TARGET also modifies the files in SET but this is not reported.
* Error: Target TARGET : unmodified reported target: SET
This depended on Poor Man's File Auditor (pmaudit): https://github.com/boyski/pmaudit
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
This is very cool.
A while back I started an experiment/prototype called "make-audit"; this is a (draft) tool to report when an execution of GNU make reads or changes files in ways that are inconsistent with its Makefile: https://github.com/david-a-wheeler/make-audit It's nowhere ready for serious use, but it can detect the following:
* Error: Target TARGET : unreported prerequisites: SET : The make recipe for creating TARGET is reading from the prerequisites in SET, but the makefile fails to report them as dependencies. You may want to add SET to the prerequisites of TARGET.
* Error: Target TARGET : claimed but unused prerequisites: SET : The make recipe for creating TARGET claims that it depends on SET, but the items in SET were never read. You may want to remove SET from the prerequisites of TARGET.
* Error: Target TARGET : unreported target: SET The make recipe for updating TARGET also modifies the files in SET but this is not reported.
* Error: Target TARGET : unmodified reported target: SET
This depended on Poor Man's File Auditor (pmaudit): https://github.com/boyski/pmaudit
-
oil
Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!
The 3 makefiles I wrote were actually for a medium-size open source project https://www.oilshell.org/ (measured by lines of code)
For two of the Makefiles I needed to enumerate the rules dynamically (inputs weren't fixed, they were "globbed"), and my memory is that this interacted very poorly with other features build variants
Whereas those pattern are extremely simple with Python/Ninja. Just write a loop or a nested loop and generate a build rule each time. Done in 5 minutes whereas GNU make was a constant struggle.
