IRC channel logs
2024-12-02.log
back to list of logs
<dthompson>fr33domlover: hey! to answer your question from a few days ago: sounds like you're talking about program or language ocaps. since guile allows full access to its POSIX API, there's nothing goblins can do about enforcing ocaps for things like file handles or sockets. we need a safe execution environment for that. our codename for this project is "oaken" <dthompson>imagine a safe scheme where some untrusted "guest" code is given capabilities in the form of imports from its host and can use nothing else. <msavoritias>+1 also for some ocap way in guile directly. I have been doing some research around trying to make some kind of secure applications leveraging guile and spritely things, but isolating these things is one of my main worries atm <sneek>msavoritias, you have 1 message! <sneek>msavoritias, cwebber says: thank you! we're very excited we finally got the new design up too :) <msavoritias>the best option i could come up with atm is just creating a lot of isolated modules and using #:pure and ocapn between them (with spritely features) but of course that is not going that far compared to ocap in there <msavoritias>that plus idk if its a goal but guix not having isolated packages with some kind of permission model like flatpak is its biggest weakness. and one of these things that I want to be part of addressing at some point. (although currently I am busy with other stuff :P) <dthompson>the best option available in guile right now is (ice-9 sandbox) but it's not enough. <dthompson>and do note that webassembly is a safe execution environment <msavoritias>yeah. I am thinking to compile my guile app in hoot as an additional security measure <dthompson>the tl;dr is that there are many layers of ocaps. the kind we can do confidently right now are network-level ocaps. <msavoritias>the sandbox came up because there needs to be an xml parser. and the security issues with that are known <dthompson>basically I wouldn't run any untrusted code in the same process as the rest of your code right now <msavoritias>so probably i would have to split things into different libraries completely. like rust does <msavoritias>the network level ocaps are on point tho :D and very useful to implement a pubsub access model over the network <dthompson>also I don't think xml parsers are inherently vulnerable, it's just that a bunch of well used xml libraries written in C are <dthompson>without significant changes to guile we can't run untrusted *bytecode*, but it would be possible to run untrusted source by implementing a new language that is scheme with a special module system + some stuff like stack space limits <msavoritias>right. my worry personally is that if I accept something* (xml currently) over the network I dont want that to be able to escape the current object it was recieved in. hence the whole module thing <msavoritias>plus i have "unsafe" containers that include xhtml and such in there. which is a whole other problem. (in group chats for examples) which is why i came to facets and guile sandbox and the likes <civodul>i’ve come to think that language-level isolation is necessarily insufficient <civodul>(ice-9 sandbox) doesn’t let you do much <dthompson>civodul: we can do much better than (ice-9 sandbox) <dthompson>webassembly is the gold standard right now, imo <dthompson>I'd be curious to hear more of your thoughts, though, civodul <dthompson>we saw a demo by folks at Agoric in which they used a safe js environment (endo) to embed a trading card game into a chat app and the game was ocap-secure <civodul>dthompson: webassembly is good because there’s not a direct POSIX interface, so little or not ambient authority <dthompson>and this demo is an adaptation of a spritely mockup! <civodul>in Guile-on-POSIX, you definitely need more than what (ice-9 sandbox) provides <msavoritias>maybe webassembly is the way to go and we just need to build tighter integration with that /shrug <dthompson>civodul: sure, but no one is going to be ocap secure programming in such an environment <dthompson>I envision a safe-scheme in which the guest code declares its imports and the host provides some implementation of those imports. this would be like webassembly. <dthompson>the guest could ask for call-with-input-file, and the host could give them the standard scheme call-with-input-file, or an attenuated version that only allows opening some specific file or files. <msavoritias>as in webassembly would the format to store it and you would write an ocap interface around it for scheme? <dthompson>not quite sure how to parse that question but the above is orthogonal to webasembly. you could implement this without it. <msavoritias>ah ok. My question was that we basically have apps compiled/shipped as webassembly that communicates with an ocap interface to get whatever it needs <dthompson>the host/guest boundary in wasm *is* an ocap interface <dthompson>or maybe it's better to just say "capability interface" and leave out the "object" part <msavoritias>:O well that got me more interested in a hoot/guile synergy now <dthompson>there's an example program that we refer to internally about this safe execution stuff. imagine an untrusted program that sorts a list of values you give to it. could you give it a list of credit card numbers and have confidence that they won't be exfiltrated via the network? <dthompson>if the sorting program were a wasm module, the answer is simple: you would never pass along an imported function (a capability) that could anything with the network <dthompson>realistically, that sorting program wouldn't declare any imports and would just export the sorting function. now the worst thing it could do is try to burn cycles on your cpu wastefully. <jfred>(specifically under the section "Getting out of the Sandbox Cycle: Safe Interactions", where they're passing in fs/https implementations to a `require`d module) <jfred>also man I need to watch some of the endo demos, it sounds like they're getting real far with it <dthompson>in scheme, we have a module system, too. guile searches a load path for modules and any module can import any other. we could use guile's multi-language features to build something that "compiles" to scheme but uses a POLA approach to modules <jfred>oh, right, I forgot about the multi-language stuff! <jfred>I suppose then you'd need to ensure that untrusted modules are s <jfred>*are loaded as source only and not as bytecode, given the above security discussion, yeah? <dthompson>safe bytecode would require some significant changes to guile which I'm guessing would be a hard sell <dthompson>untrusted programs as source is a much more realistic first pass at the problem <jfred>I guess you could still compile those modules so they load quickly the next time too, so long as you can be sure that compilation was done locally <dthompson>it's all wired up as it would need to be, but guile has a baseline compiler, the "real" compiler, and a jit compiler <jfred>I hadn't thought about the fact that e.g. v8 has a bytecode representation that it caches because you never really see it as a user <dthompson>so you could theoretically interpret user code then tier up to baseline <dthompson>scheme in the browser... how about scheme *is* the browser??? ;)