Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Landlock to Sandbox GNU Make

justine.lol

Post reply on HN
Print view View original

61–70 of 80 posts

Re: Using Landlock to Sandbox GNU Make

#61

Post by MaulingMonkey »

__float wrote: post #11
ghoward wrote: post #5

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 wh…

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.

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.

Re: Using Landlock to Sandbox GNU Make

#62

Post by josephcsible »

ghoward wrote: post #57
colatkinson wrote: post #52

Earlier quoted context omitted.

> 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 sa…

Yes, I agree that Bazel and Nix are not much different. Nix seems to be even more sandbox-like than Bazel, and that's good in my opinion. Beyond what they do, I'd like checks that are even more invasive, more cautious about letting the build script do anything. For example, if you're on Linux, a bad actor build script could technically mount the root directory `/` underneath the sandbox area in / /rootdir/` using Lin…

> a bad actor build script could technically mount the root directory `/` underneath the sandbox area in //rootdir/` using Linux's bind mounts feature

How could you do this without already being outside of the sandbox?

Re: Using Landlock to Sandbox GNU Make

#63

Post by 1vuio0pswjnm7 »

chubot wrote: post #20
jart wrote: post #8

Earlier quoted context omitted.

One of the nice things about Bazel that the article didn't get a chance to go into is it uses SHA hashes of files, rather than file timestamps, to determine when an artifact has changed and therefore needs to be updated. It's slightly more costly to compute hashes, but it's necessary if you want to have something like a global cache of build artifacts, since synchronizing time across machines is hard. What I'd recomm…

For the first decade and a half of Google's company lifecycle, they got along just fine with GNU Make ??? Google was started in 1998, and Bazel was created ~2006 as a replacement for Python + GNU Make ("gconfig"). I was on that team, though I only worked on Blaze a tiny bit. The "google3" build migration was sometime around 2003 or 2004. So at most there were 6 years of using Make only, i.e. "google2". Importantly, p…

"If you want to do what "scrappy Google" did these days, then you should use Python + Ninja."

Or, better yet, use a faster^1 and more portable Ninja-compatible build utility written in C99.

https://github.com/michaelforney/samurai

1. YMMV

Re: Using Landlock to Sandbox GNU Make

#64

Post by pabs3 »

jart wrote: post #4
djhaskin987 wrote: post #3

I wonder why there was no mention of simply contributing these 200 lines to GNU make proper instead of forking. Super cool though.

That 200 lines doesn't include our pledge() implementation, which Make assumes is provided by the C library. Right now only Cosmopolitan Libc and OpenBSD have an unveil() implementation. It would take some thought to decide what the best approach would be for incorporating something like that into GNU Make. So I'm waiting on more feedback from the community and the GNU developers. Because upstreaming is totally somet…

The pledge implementation seems like something that would be useful to other things too, so maybe spin it out into a separate library?

Re: Using Landlock to Sandbox GNU Make

#65

Post by spockz »

enriquto wrote: post #54
spockz wrote: post #40

The only thing I’m really missing for my usecase with make is the ability to specify goals/targets other than files. E.g., I want a docker image to be present in the daemon. Basically, calling out to a function. (Probably somebody is going to correct me and say there is something there in the form of conditionals or something..)

> E.g., I want a docker image to be present in the daemon. This sounds more like a limitation of docker than of make. I don't use docker, but how on earth something called a "docker image" is not a file?

Docker images can be stored as a file. And maybe are indeed stored on the file system as individual files as well. But building against a specific cr implementation for this seems too brittle.

Re: Using Landlock to Sandbox GNU Make

#66

Post by mst »

jart wrote: post #8
gray_-_wolf wrote: post #6

This is definitely interesting and cool, however: > Landlock Make can build code five times faster than Bazel, while offering the same advantages in terms of safety. In other words, you get all the benefits of a big corporation build system, in a tiny lightweight binary that any indie developer can love. In terms of safety, maybe almost (bazel can check if the source files changed during the build, this (afaict) can…

One of the nice things about Bazel that the article didn't get a chance to go into is it uses SHA hashes of files, rather than file timestamps, to determine when an artifact has changed and therefore needs to be updated. It's slightly more costly to compute hashes, but it's necessary if you want to have something like a global cache of build artifacts, since synchronizing time across machines is hard. What I'd recomm…

... now I want landlock redo

Re: Using Landlock to Sandbox GNU Make

#67

Post by jchw »

Cloudef wrote: post #60
jchw wrote: post #55

Earlier quoted context omitted.

You can't really use WSL to develop or use native Windows software. WSL is good for when your target is Linux and otherwise not applicable. It's also not Window's problem. It's yours, when you try to develop software and have Windows users.

Mingw exists

This only makes the problem much worse. (Note that I literally reference MSys and Cygwin in my original reply. However, these options are neither ideal for making good Windows binaries nor are they great facsimiles for UNIX. Almost any Makefile needs to be carefully constructed so that MinGW works, especially if you want to support more than just very specific MinGW setups. And there's other downsides I didn't get into, such as licensing problems with winpthreads, and silent dubious behavior like pseudo relocs. I don't recommend using MinGW.)

Re: Using Landlock to Sandbox GNU Make

#68

Post by dwheeler »

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

Re: Using Landlock to Sandbox GNU Make

#69

Post by chubot »

avar wrote: post #44
chubot wrote: post #20

Earlier quoted context omitted.

For the first decade and a half of Google's company lifecycle, they got along just fine with GNU Make ??? Google was started in 1998, and Bazel was created ~2006 as a replacement for Python + GNU Make ("gconfig"). I was on that team, though I only worked on Blaze a tiny bit. The "google3" build migration was sometime around 2003 or 2004. So at most there were 6 years of using Make only, i.e. "google2". Importantly, p…

I wrote 3 substantial GNU makefiles from scratch and regretted it largely because it lacks this split -- it has a very tortured way of doing build "metaprogramming". GNU make definitely still has a lot of rough edges, but parts of your comment seems as though you're making claims about it that haven't been true in a decade or more. For one, you don't need to "write a Lisp in Make", it has Guile built-in now (but prob…

Can you point me to a widely used Makefile that uses Guile in GNU make? AFAIK it's not available on most distros, so people don't use it. It's an optional extension

Re: Using Landlock to Sandbox GNU Make

#70

Post by chubot »

dima55 wrote: post #41
chubot wrote: post #20

Earlier quoted context omitted.

For the first decade and a half of Google's company lifecycle, they got along just fine with GNU Make ??? Google was started in 1998, and Bazel was created ~2006 as a replacement for Python + GNU Make ("gconfig"). I was on that team, though I only worked on Blaze a tiny bit. The "google3" build migration was sometime around 2003 or 2004. So at most there were 6 years of using Make only, i.e. "google2". Importantly, p…

I don't disagree with anything you said, but I think it's important to point out that your experience is unique in that you're talking about build infrastructure for a massive codebase: most of Google's internal stuff, right? In my experience plain GNU Make works great until you start working with massive projects. Similarly, the ninja speed improvement: you just don't see it unless you have a truly massive project,…

The 3 makefiles I wrote were actually for a medium-size open source project https://www.oilshell.org/ (medium measured by lines of code)

I could probably write a blog post about this, but 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 GNU make features build variants

Whereas that pattern is extremely simple with Python/Ninja. Just write a loop or a nested loop and generate a build rule on each iteration. It's done in 5 minutes, whereas GNU make was a constant struggle.

Post reply on HN