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

21–30 of 80 posts

Re: Using Landlock to Sandbox GNU Make

#21

Post by chubot »

gravypod wrote: post #17
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…

> What I'd recommend for anyone really, is to just do what Google did. For the first decade and a half of Google's company lifecycle, they got along just fine with GNU Make. Then they switched to the huge scalable thing once they actually reached that inflection point. Hopefully as a community we can build things that are scalable and as-simple-as Make. I think please.build is a step in the right direction but still…

Eh Make is not good for most problems -- see experiences here by dwheeler, me, frankohn:

https://news.ycombinator.com/item?id=32301606

And this other thread I linked there, with feedback from FreeBSD engineers:

https://lobste.rs/s/7svvkz/using_bsd_make#c_bfwcyc

---

Ninja basically gives you the parts of GNU make that are good, without the cruft and slowness. And you can learn it in 20 minutes, unlike GNU make

Re: Using Landlock to Sandbox GNU Make

#23

Post by __float »

ghoward wrote: post #15
__float wrote: post #11

Earlier quoted context omitted.

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.

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.

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.)

Re: Using Landlock to Sandbox GNU Make

#24

Post by [deleted] »

chubot wrote: post #21
gravypod wrote: post #17

Earlier quoted context omitted.

> What I'd recommend for anyone really, is to just do what Google did. For the first decade and a half of Google's company lifecycle, they got along just fine with GNU Make. Then they switched to the huge scalable thing once they actually reached that inflection point. Hopefully as a community we can build things that are scalable and as-simple-as Make. I think please.build is a step in the right direction but still…

Eh Make is not good for most problems -- see experiences here by dwheeler, me, frankohn: https://news.ycombinator.com/item?id=32301606 And this other thread I linked there, with feedback from FreeBSD engineers: https://lobste.rs/s/7svvkz/using_bsd_make#c_bfwcyc --- Ninja basically gives you the parts of GNU make that are good, without the cruft and slowness. And you can learn it in 20 minutes, unlike GNU make

[deleted]

Re: Using Landlock to Sandbox GNU Make

#25

Post by ghoward »

jart wrote: post #18
ghoward wrote: post #16

Earlier quoted context omitted.

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.

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

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.

Re: Using Landlock to Sandbox GNU Make

#26

Post by elteto »

Very interesting and impressive technically but the post took a dive towards the end with the anti-Java rant.

We can celebrate our work without having to stand on a platform made by bashing the work of others.

Re: Using Landlock to Sandbox GNU Make

#27

Post by ghoward »

__float wrote: post #23
ghoward wrote: post #15

Earlier quoted context omitted.

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.

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

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.

Re: Using Landlock to Sandbox GNU Make

#28

Post by tux1968 »

chubot wrote: post #21
gravypod wrote: post #17

Earlier quoted context omitted.

> What I'd recommend for anyone really, is to just do what Google did. For the first decade and a half of Google's company lifecycle, they got along just fine with GNU Make. Then they switched to the huge scalable thing once they actually reached that inflection point. Hopefully as a community we can build things that are scalable and as-simple-as Make. I think please.build is a step in the right direction but still…

Eh Make is not good for most problems -- see experiences here by dwheeler, me, frankohn: https://news.ycombinator.com/item?id=32301606 And this other thread I linked there, with feedback from FreeBSD engineers: https://lobste.rs/s/7svvkz/using_bsd_make#c_bfwcyc --- Ninja basically gives you the parts of GNU make that are good, without the cruft and slowness. And you can learn it in 20 minutes, unlike GNU make

> Ninja basically gives you the parts of GNU make that are good, without the cruft and slowness. And you can learn it in 20 minutes, unlike GNU make

Are you suggesting it's easy to learn how to hand code Ninja files, or do you have a different easy-to-learn tool to generate them, in mind?

Re: Using Landlock to Sandbox GNU Make

#29

Post by dwheeler »

chubot wrote: post #21
gravypod wrote: post #17

Earlier quoted context omitted.

> What I'd recommend for anyone really, is to just do what Google did. For the first decade and a half of Google's company lifecycle, they got along just fine with GNU Make. Then they switched to the huge scalable thing once they actually reached that inflection point. Hopefully as a community we can build things that are scalable and as-simple-as Make. I think please.build is a step in the right direction but still…

Eh Make is not good for most problems -- see experiences here by dwheeler, me, frankohn: https://news.ycombinator.com/item?id=32301606 And this other thread I linked there, with feedback from FreeBSD engineers: https://lobste.rs/s/7svvkz/using_bsd_make#c_bfwcyc --- Ninja basically gives you the parts of GNU make that are good, without the cruft and slowness. And you can learn it in 20 minutes, unlike GNU make

GNU make is great for many things, used correctly. The problem is that POSIX make is extremely impoverished, so sticking to just the POSIX subset is often a bad idea. In many cases using "make" should really mean using "GNU make" so you can use conditionals, automated dependendency generation (via reloads of dependency info), etc.

Re: Using Landlock to Sandbox GNU Make

#30

Post by yjftsjthsd-h »

3836293648 wrote: post #13
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…

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.

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.

Post reply on HN