Sandboxing in Teliva Programming languages assume all code they run is trustworthy. Browsers assume all connections they make over a network are trustworthy. I'm starting to experiment with alternatives to these approaches. Here's one early, extremely caricatured sandboxing model that's already more flexible than both conventional languages and browsers. https://archive.org/details/akkartik-teliva-2021-12-25 Main project page: https://github.com/akkartik/teliva

Are you familiar with object capabilities? An alternative permission model which I think might help make fine grained permissions easier to manage

Oh yes, I'm a fan though not an expert. My previous Mu project used that idea. I'll be working that in here as well.

I ask because I am familiar with Android/Google's permission model where if you want to load or save a single file, you must give broad permissions to all user files. I am not sure if this is the case here. I think the right model is decoupling file selection (done by a trusted computing component, from set of files) and file access - authority is granted by the actual transmission of the selected file to the app (as a capability). i.e: Instead of passing a file string/id into a global namespace, and separately giving permissions into that namespace - there is no globally accessible namespace of files, and you give the open file itself to the app.

Yeah, I don't have capabilities. Yet 🙂 Like I said, I'm not an expert and would appreciate someone going over what I come up with. What I had in https://github.com/akkartik/mu (really https://github.com/akkartik/mu1) was quite hokey. I believe trusted components basically work by preventing automation and hindering discoverability. Is that accurate? One thing I care about is being able to continue using an app without granting all requested privileges. For example, easily creating a fake file system with honeypot data. That feels orthogonal to capabilities. They don't preclude it, but they also don't make it easy by themselves. So I feel like there are some trade-offs to weigh here. But maybe I'm wrong and it's all a solved problem. Pointers most appreciated.

Not sure what you mean about hindering discoverability. Anyway, I don't think it's a solved problem at all. Object capabilities have never made it, at least to the mainstream, as far as I'm aware. But I'm a big fan of the idea. https://www.researchgate.net/publication/220910162_EROS_a_fast_capability_system was a very interesting attempt at object capabilities

Thanks! Let me read (reread) that. I only meant solved technically. Basically I'm wondering how you can build say a file browser.

deno is doing something similar https://deno.land/manual@v1.17.1/getting_started/permissions

This seems apt: https://justinpombrio.net/2021/12/26/preventing-log4j-with-capabilities.html

Yeah, it's interesting! I think we can probably be finer-grained than a giant "Network" capability, too. Probably a capability to connect to specific domains, or maybe all domains but only in specific protocols or only in limited ways.

Oh yes, that is all planned. One challenge with networking is that reads and writes become less obvious. Parsing packets may not be sustainable. But we can certainly track what host we're connecting to.

If you put constraints by restricting access to APIs, and not grant raw packet access - I don't think it would be a difficult problem?

Yeah, that's definitely a possibility 👍🏼 Though it precludes supporting a new protocol like Gemini? Perhaps I need an API to the 'cryptography layer', either https or ssh.

this is similar to the java permissions model https://foojay.io/today/jep-411-what-it-means-for-javas-security-model/

That's a really great article, thanks! I don't understand, though, why specifying that a program can only modify files it created within some directory requires so much hardcode crypto. Thinking about it some more, the difference between permissions and capabilities seems to be: • Permissions are checked based on who you are. • Capabilities are checked based on what you have. Does that seem right? Seems insightful if so, an analogy with authentication mechanisms. If I'm right, then capabilities feel a bit overkill for my use case. I'm quite happy tracking what programs can do in the supervisor (the Teliva runtime). I don't need permissions to exit and reenter the supervisor, creating the need to make them tamper resistant. But this is all unfamiliar territory to me. More comments most appreciated.

re: orthogonality of capabilities/mocking— i want to be able to run Word, extract its lifeless husk, and reanimate it with my own rules/network connections/etc.

I would add that the permission model includes a global namespace + permission checks that you only access the allowed subset of the global namespace. The capability model only allows you to express requests you are allowed to make (no global namespace)

Eyal has got it. Permissions are finer grained and attached to resources. Capabilities are attached to resource categories. Because you can 'flatten', you can model permissions with just capabilities if you are willing to take a cross produce against resources. i.e. the can_read_user_dir_capability Anyway, my broader point was to refute

Programming languages assume all code they run is trustworthy.

with crusty old Java, and it does not work in practice! And my follow up was to show where the SOTA currently is. Maybe programming language is the wrong place to do permissions, maybe something a level above programming language is correct (the networking/API layer/Gateway level) because you can then do organization policies in a language independant way? For Java security model to work, you have to enforce it at an organizational level, and why special case Java? Better to apply permissions policies at hardware/network level, especially in a distributed systems world?