We need effect based languages now. It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles. If anyone from epic is reading this please give us a timeline for open sorucing the Verse compiler.

In the mean time I think it's possible to hack Cargo and run all build scripts in a microVM. The blast radius will be limited to malicious code in the binary instead of uploading all your CI secrets and deleting the whole hard drive.

▲

jmull an hour ago | parent | next [-]

I think this is an attractive chimera, but will never be popular and will only be used much in specific domains.

The thing is, trust is a massive optimization. If you believe code from X is competently made and not malicious, you can accept that code without any additional overhead. (Building trust is a significant effort, but trust begets trust, so there's a resonable path from starting small to scaling.)

It's not that these mechanisms that require less trust (none of them eliminate it, BTW, when you examine them) can't work. It's that they'll inevitably be outcompeted by trust-based systems (in most domains).

E.g., compare the effort of creating a new, full featured, general purpose language, promoting it, building and maintaining all the tooling and documentation around it to support it, etc to the effort of creating and maintaining a curated package repository of trusted packages (and/or adding trusted code to extend the standard library) for existing language X.

(It's not clear to me you could provide enough value from a new language focused on effects that you could convince any but a few from adopting it at all, even if it dropped from the sky fully formed with all tools, docs, etc. in place from day one.)

▲

vaylian 2 hours ago | parent | prev | next [-]

> It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles.

It's not the only way. You can sandbox processes. I think sandboxing is the much more reasonable approach, because in the end of the day, there are still closed-source software products where you can't demand that the manufacturers use certain language safety features.

▲

kevincox 2 hours ago | parent | next [-]

Sandboxing the process only works well when the malware requires more capabilities than the software itself.

So if your software needs to make HTTP requests and read the filesystem then the malware will be able to make HTTP requests and read the filesystem, which is enough for a ton of malware. Sure, maybe you can limit the directories it can access a bit and possibly some sort of network filtering, but it isn't a silver bullet.

Capability security in-language would make a huge difference, because the more granular you "sandbox" the less likely it is that the compromised component has the access it wants. For example if the HTTP client library is compromised maybe it can't access the filesystem so can't steal your cookies. Or maybe like in this case no permissions were needed at all and despite the process having enough capabilities for malware this malware can at worst return bad values and try to chain this to an exploit which is far more difficult than just running it itself.

	▲	cpuguy83 an hour ago \| parent [-]
		The problem isn't the language here, it's cargo executing build.rs from dependencies which necessarily allows arbitrary code execution.

▲

throwaway894345 2 hours ago | parent | prev [-]

I don’t even understand what a capability based language is, but presumably closed source software wouldn’t apply here? Is it common for closed source software to give the source code to customers to build?

	▲	bluGill 2 hours ago \| parent [-]
		> Is it common for closed source software to give the source code to customers to build? Yes, somewhat common. I work in embedded, and where a supplier gives us the ability to build their code it is a lot easier for us to deal with the next time we need a new build from them.

▲

rrook an hour ago | parent | prev | next [-]

Some shameless self promo - I'm working on one!

https://hale-lang.org/proof/

▲

insanitybit 2 hours ago | parent | prev | next [-]

https://github.com/insanitybit/witchy

This is why I'm building this language. It's capabilities based. Build scripts can't just do whatever the hell they want to, everything is auditable, and it layers its sandboxing.

It's for fun and anyone looking should understand that this is AI driven building with human driven design, but the goal is to demonstrate.

▲

rtfeldman 2 hours ago | parent | prev | next [-]

I think the only language that's used in production where malicious dependencies can't do arbitrary effects is https://roc-lang.org - but it's a pre-0.1.0 language and as such its production usage is extremely minimal for now.

▲

prpl 2 hours ago | parent | prev | next [-]

I have been working on a cross platform way of sandboxing without a VM:

https://github.com/brianv0/formwork

▲

jooops1 an hour ago | parent | prev | next [-]

Can you explain how an effect based language helps here? Also to note filesystem access can allow network access on many systems and also the other way around.

▲

throwaway894345 2 hours ago | parent | prev | next [-]

Why does every build have the ability to run arbitrary code by default in the first place? That seems like something you should opt into only under very specific scenarios and even then it should probably be built around a WASM sandbox or microVM (as the parent suggested).

▲

bluGill 2 hours ago | parent [-]

Because many many builds end up doing something just a little weird that the build system cannot handle by default. Ideally the build system would be fully property/dependency based and so it wouldn't have to run arbitrary code. In the real world everybody has something weird about their build that the build system cannot make work.

This is partially because for nearly every project the build system is something they need and don't care about. When they need something weird they hack just enough to make it work and never ask "how should the build system change so that this was a property instead of running code", and thus build systems are slow to improve. In a number of cases the build system did have a way to do that thing, but the person didn't know about it.

There are also a lot of code generators out there. I have yet to see a large project which didn't have their own code generator for something specific to their project (protobuf is an example from Google that has escaped and become useful elsewhere, but there are many others that are specific to one project. Yacc is from the 1970s, and stands for "yet another compiler compiler" - implying the idea was already common 50 years ago). You cannot have/use these useful tools without running arbitrary code.

▲

skydhash 2 hours ago | parent [-]

I don't mind code execution as even make has shell scripting embedded, same thing with meson. My issue is with network access to download random stuff without it being declared somewhere and signed.

I'm using OpenBSD and the ports system set up two users `_pbuild` and `_pfetch` for building packages. The first one is for building and the sample `pf.conf` (firewall) forbid it from accessing the network. The second does fetch the files , but it's declarative with every files listed and signed. Even for languages like go and rust.

Fetching files while building is the bad idea there.

	▲	bluGill 2 hours ago \| parent [-]
		Good point. Many build systems also want to be a package manager, but the two are and should be separate. If you have a simple problem it makes things easy to combine them into one. However they need to be separate anyway, both for security and also to make other weird situations easier.

▲

burnt-resistor 2 hours ago | parent | prev | next [-]

More than that, we need capability-based languages. No capability passed to it, no permission.

▲

kibwen 2 hours ago | parent [-]

First we need capability-based OSes, like we should have had decades ago if worse-is-better hadn't stuck us with Unix. I don't need to care whether or not a program was written in a capability-aware language if the OS fundamentally takes care of that for me.

	▲	grommz an hour ago \| parent \| next [-]
		HarmonyOS is a capability based OS. I don't know why anyone in China is still using Rust. The biggest social engineering hack was for the Rust team to convince developers that it is a safe language.
	▲	ptx 2 hours ago \| parent \| prev [-]
		FreeBSD does this with Capsicum: https://wiki.freebsd.org/Capsicum

▲

quotemstr 2 hours ago | parent | prev [-]

MicroVM this, effects that --- can we discuss security without needing to invoke bay area buzzwords?

The idea is "least privilege", and we desperately need it in computing. The precise technical mechanism we use to achieve it is less important than committing to the idea that a dependency doesn't run with full privilege of its host program and an install script doesn't run with full privilege of the programmer.

The original Linux seccomp is old enough to drink. It's always been possible to do things like expand macros in a no-IO environment. Nobody's bothered to do it over the past two decades. Why would anyone bother in the next two decades?

▲

insanitybit 2 hours ago | parent [-]

The technical mechanism is exactly the issue to figure out, there's a reason why projects don't have this and it's because different implementations have different tradeoffs.

▲

quotemstr 2 hours ago | parent [-]

No, the reason people haven't been doing this -- and we've had technologies for ages -- is that it's a huge pain in the ass, a "tax", that it's hard to get developers inside a company to pay, much less participants in open source ecosystems.

Look at how snap, flatpak, etc. provoke people to just turn off security rather than deal with breakages.

A new language won't help because the problem is social, not technical.

FFS, you can't even get people to use filesystems via intermediate objects in today's languages. People think your language is broken if you don't have an ambient open(). You don't need a new language to enforce capability discipline. You need to whack people repeatedly with a cluebat until their laziness and brain damage abate.

▲

insanitybit 2 hours ago | parent [-]

You can't simultaneously say that we've had the tech for years and also say that it doesn't work. We have not had the tech for years. x-plat sandboxing is extremely difficult, especially in a way that's performant.

Sandboxing almost always involves having a dedicated, privileged service, due to how operating systems have designed things. It requires platform specific code.

This is a technical problem and a social problem, there's zero reason to believe it's just one.

▲

quotemstr 2 hours ago | parent [-]

The technology works fine if you use it in a disciplined way. The problem is that people don't! You're necessarily going to break programs if you put them in restricted environments. That's not the same as the restriction technology not working properly.

> Sandboxing almost always involves having a dedicated, privileged service, due to how operating systems have designed things.

Or just invoking bwrap. Or sandbox-execute. There's no performance overhead. Complexity is minimal. Just read current Codex source code. It's not so bad. People have been making these sandbox tools for AI agents for years. Just need to apply sandboxing to all domains.

You want some kind of silver bullet that makes code "safe" without anyone having to change anything? To prompt for nothing? To use no IPC portal? That's not happening.

The people saying we need a new language or something are half right. We don't need a new language. A pure library solution is fine! But people do need to do work to make an ecosystem based on capabilities and least privilege to work. And we need to tell people who refuse to do this work to go to hell.

A new language is neither necessary nor sufficient. What we need is new set of balls.

▲

insanitybit 2 hours ago | parent [-]

> The technology works fine if you use it in a disciplined way.

Then obviously we have to discuss the implementation!

> Or just invoking bwrap. Or sandbox-execute. There's no performance overhead. Complexity is minimal. Just read current Codex source code. It's not so bad. People have been making these sandbox tools for AI agents for years. Just need to apply sandboxing to all domains.

Tools like bwrap literally could not have existed until very recently without also requiring suid/ privileges, and even today unprivileged user namespaces are not universally enabled. This is why the implementation matters. No, unprivileged sandboxing has not been around for years, especially not x-plat. bwrap is a perfect example of what I'm talking about, great reference - it either requires root or it requires unprivileged user namespaces and it's not x-plat. Great.

> You want some kind of silver bullet that makes code "safe" without anyone having to change anything? To prompt for nothing? To use no IPC portal? That's not happening.

I have no idea why you think I've said this, I'm pointing out that the implementation and technology matters deeply.

> The people saying we need a new language or something are half right. We don't need a new language. A pure library solution is fine! But people do need to do work to make an ecosystem based on capabilities and least privilege to work. And we need to tell people who refuse to do this work to go to hell.

Again, you can't say "this technology has existed for years! You can do it in a library!" and then say "but they don't!". You misunderstand the complexity and assert that it's merely a matter of will. It is both.

▲

quotemstr 2 hours ago | parent [-]

Browsers have been sandboxing their tabs since 2008. Don't sit there and tell me that bwrap, sandboxing, whatever is some kind of recent innovation with uneven distro support.

And yes, bwrap needs root or namespaces. So what? So does sudo. Setuid binaries are as old as time.

You know what's also been around and doesn't require root? Landlock. Have you heard of it? Has anyone? There's a huge PR and visibility gap in this space. We don't have to invent some new thing. We have to get people to learn about what we already have and use it.

"Oh, the technology works, but it need setup! Oh, my distro doesn't enable it! Oh, it doesn't work out of the box with my code!"

This is a social problem. It's not a technology problem. It's people not wanting to do the work, not understanding what already exists, dismissing solutions based on non-problems (like bwrap needing privileges on some systems), and in general adopting an attitude of "no", not a can-do problem solving stance.

And we're supposed to solve this problem with let another precious little effects language or another fucking MicroVM environment? FFS.

We need unprivileged sandboxing!"

"Use bwrap"

"Nooo, that needs setuid root or file caps!!!1!1"

"So the problem is that bwrap is part of the TCB?"

"Yes. We need sandboxing that relies only on unprivileged code like the Linux kernel"

... the fuck?

You can't solve a social problem with technology.

	▲	insanitybit an hour ago \| parent [-]
		> Browsers have been sandboxing their tabs since 2008. Yes, it's an amazing feat that has cost billions and led to major features like seccomp v2, ptrace sandboxing, etc. Do you know the history of browser sandboxing? It's pretty complex, a major technical feat. > Don't sit there and tell me that bwrap, sandboxing, whatever is some kind of recent innovation with uneven distro support. I can tell you that unprivileged sandboxing is not only new, it's ongoing and nascent work and not commonplace at all. > And yes, bwrap needs root or namespaces. So what? So does sudo. Setuid binaries are as old as time. These are massive footguns and issues for deploying code... You don't get that? Again, implementations have tradeoffs. > You know what's also been around and doesn't require root? Landlock. lol it is SO NEW what the fuck dude? > Have you heard of it? Has anyone? Yes, I use it! > "Oh, the technology works, but it need setup! Oh, my distro doesn't enable it! Oh, it doesn't work out of the box with my code!" > This is a social problem. Yeah these sound like social problems if you have literally no idea what you're talking about lmfao. IT's BOTH. Your ignorance is blatant and your position is dead in the water.