IRC channel logs
2024-08-14.log
back to list of logs
<cwebber>there's a way we could do references that didn't use captp but use file handles instead but I'm not sure <cwebber>I suppose it would actually still be captp <cwebber>because we'd need to gc between processes <sneek>weary-traveler, you have 1 message! <sneek>weary-traveler, dthompson says: I think shepherd will be the first external project to use goblins (if it is adopted) as we are only now starting to reach a point where goblins is more generally usable <weary-traveler>sneek: later ask dthompson what's the mailing list that would be relevant/helpful for keeping up with the shepherd/goblins integration work? <sneek>dthompson, you have 1 message! <sneek>dthompson, weary-traveler says: what's the mailing list that would be relevant/helpful for keeping up with the shepherd/goblins integration work? <dthompson>we implement an object capability security system <dthompson>I'm sure the guix mailing list will also get some updates later on in the project <weary-traveler>thank you for the heart of spritely reference. that looks like it has some relevant details <dthompson>"object capability security" is the more general term to read into if you're looking for more stuff later <weary-traveler>thank you. the heart of spritely paper might make this clear, but do you know which of the properties the security model relies on (interaction only via messages given references, references only via {initial conditions, parenthood, endowment, introduction}) does the guile runtime provide, vs goblins implements ensures itself <weary-traveler>dthompson: for instance, though i don't have experience with it, it seems guile has "reflection" capability of some sort. could that not provide a way to bypass the above requirements? <weary-traveler>my intuition may be wrong, but it seems you need some sort of functional purity guarantee. a typechecker may provide that, or in general some kind of verifier. but it's not clear how one could achieve these guarantees without such a thing <dthompson>weary-traveler: there are various levels to which you can apply ocaps. you're referring to language-level ocaps, which indeed is not currently possible with guile. <dthompson>goblins provides ocap security at the process level via ocapn <dthompson>language-level ocaps are on our roadmap. webassembly is an example of something that provides ocaps within a single process. <weary-traveler>though perhaps the process-level ocaps that goblins provides precludes things like attaching a debugger etc. <dthompson>weary-traveler: if you're root on the machine, it doesn't matter what we do, you can inspect the process. <weary-traveler>right. so then i'm not sure what you mean by process-level ocaps. is it something like, assuming no privilege escalation etc etc, then we can guarantee ... <dthompson>maybe it would make more sense if I just say network level <dthompson>ocapn provides ocap security at the network level <dthompson>but projects like goblins + shepherd are the start of a larger project to move guix towards being an ocap OS <weary-traveler>yes, that makes more sense. the assumption is for nodes to not be able to interfere with one another. the only way they should be able to affect the other is via the exchange of messages given references that can only be created in some limited ways <weary-traveler>i suppose it's not so much that the nodes even need to be on different machines, they simply need to not be able to discern in any way whether or not they are. interesting. <dthompson>leaving aside the fact that on linux we can't get rid of root, it would otherwise be possible to use things like containers to create a userspace ocap system on top of linux ACLs <dthompson>it would be a large improvement over the status quo <weary-traveler>i'm not sure if containers would provide sufficient isolation. perhaps virtualization. so something akin to vms on a hypervisor <dthompson>vms are too heavyweight. I wouldn't want to use such a system. <dthompson>guix already has call-with-container for isolation via containers, it would be good to build off of it. <weary-traveler>i think it depends on the usecase. my point is simply that if one wants OS-level ocaps on something like linux, going the way of qubes is perhaps a minimum requirement. if, however, the goal is simply to improve on the status quo (without necessarily providing strong guarantees) then containers might be an option as well <jfred>even containers would be a security improvement over the status quo (every application you run running "as you") - granting the container access to everything it needs can be annoying but that's one of the things ocaps help with :) <jfred>but yeah Linux is not really designed with capabilities in mind... <dthompson>imagine there not being a "you", maybe just "root" and "guix" or something <dthompson>anyway probably not worth getting into implementation details as that's an area of research, just wanted to illustrate the general vision <jfred>thinking about how to do OS-level ocaps is a deep deep rabbit hole (persistence?! the Hurd sidesteps that and bootstraps file perms from ACLs, that design predates the Jhu-paper I think) <weary-traveler>sure. but if you believe we can do OS-level ocaps with it using containers, then i have misunderstood what you mean by OS-level ocaps <dthompson>(aside from the shepherd thing but that's not OS ocaps... yet) <weary-traveler>i think it's possible to discuss things that nobody's started implementing yet. but perhaps it's off topic in which case i won't ask for followups on the OS-level ocaps topic <dthompson>okay then agree to disagree on containers :) <weary-traveler>agree to be confused, more like :) the requirements for ocaps seem pretty clear cut. the shared kernel across containers means linux at present can't provide those guarantees. perhaps when you say linux and containers you mean something different <dthompson>weary-traveler: well now I'm curious... how does a shared kernel cause a problem? do you mean specifically on a monolithic kernel vs. microkernel? <dthompson>a true ocap OS is much more possible on something like Hurd, but no one uses it so we need to do what we can with Linux. <dthompson>and we haven't even opened the can of worms that is hardware ocaps yet ;) <weary-traveler>i think your usage of "true ocap OS" is indicative perhaps, that we're using the term differently. it seems things can qualify as being an "ocap OS" without being "true ocap OS". there being a shared kernel means, a misbehaving process could, by way of privelege escalation access the memory of another process. this could, potentially lead to violation of "unforgeable references" <dthompson>I mean, yeah, on linux if something becomes root then you're hosed no matter what. but you can make it really hard to do this. <weary-traveler>sure, but really hard isn't impossible. and that's the difference between providing a security guarantee vs improving over current stat <dthompson>and you can make it really hard for solitaire to talk to a botnet <dthompson>someone can exploit a cpu level vulnerability and invalidate the security above it. it's not an all or nothing thing. <dthompson>ideally we could run systems on a microkernel on top of something like CHERI <weary-traveler>when stating security guarantees it kind of is. perhaps ocaps is not intended to provide security guarantees, in which case i'm mistaken and my apologies. but if it is, then i think it's really important to be explicit about what's being assumed vs ensured vs simply made less likely <dthompson>well I certainly don't believe that we should lie about what we are able to protect against <dthompson>you can't really make any guarantees in computer security, but you can be safer relative to something else. <weary-traveler>perhaps a better way to phrase my confusion from earlier would've been, when you talk about OS-level ocaps, what are you assuming in order to guarantee that the references are unforgeable <dthompson>references need to be unguessable. incrementing ids being an obvious example of guessable. ocapn uses crytographic keys to create unforgeable references. a machine's identifier is its public key + some other info <dthompson>s/machine/node/ is the more proper term I suppose, according to the language of the draft spec <weary-traveler>in my limited experience, for secrets (which need to be unguessable), large address space, good pseudo rng, and prevention of leaks are the usual criteria. on nodes running on different physical machines that can't discover each other except by introduction, the fulfillment of these criteria is clear(er) <weary-traveler>on processes running in different containers on same machine, it's not clear what additional things are being assumed for this to hold <weary-traveler>whatever additional thing(s) is (are) being assumed would have to preclude privilege escalation in some way. perhaps trivially (by assuming it doesn't happen) <dthompson>erlang, for example, doesn't meet the requirements because PIDs are guessable. <weary-traveler>hm over the network that wouldn't matter though, unless the guessable PIDs are sufficient for communication <dthompson>they're not designed to be private addresses. I'm not an erlang programmer so I don't know how they're used in practices but I know this much. <dthompson>doug crockford's talks on the actor model mention this <weary-traveler>i haven't used erlang since gradschool, but i don't believe it's relevant when considering different processes on different machines over the network. and if we're talking about processes on the same machine, i think you might agree that it's not clear what that looks like <weary-traveler>though perhaps you simply meant language-level (as opposed to network and OS level), in which case i'd agree that erlang doesn't implement that <weary-traveler>actually, speaking of language-level ocaps, dthompson you mentioned that goblins would get that via wasm. is it specifically, via the wasm runtime or via the wasm compiler-backend or some combination thereof? i don't know much about wasm nor its runtime <jfred>dthompson: References don't necessarily need to be unguessable within a single machine depending on your design. File descriptors are probably the most familiar example; a process has file descriptors for its open files, and even if you know that a given process's FD 10 is a file you're interested in, you can't do anything with that from another process since it's not in your FD table <jfred>(well, procfs shenanigans and such aside...) <weary-traveler>true, not necessarily. but i think in the case of an erlang process when considering the message passing it does, knowing the pid is sufficient for sending messages. i.e., on the same erlang vm what you get are vats not nodes <weary-traveler>hm it seems functionally pure languages or those where the type-system can distinguish between side-effecting and pure computation would be sufficient for implementing language-level ocaps <weary-traveler>sort of like what haskell does in stref. creates a reference that the typechecker ensures cannot be acted on except by passing explicitly