2 ms·
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: unt
by 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.