On Sun, 21 Mar 2021 at 05:08, Olaf Buddenhagen <[email protected]> wrote: > Now the user is dealing with a piece of software they don't control: > that they can't inspect or modify; that requires trusting third parties > to follow the desires of the user -- supposedly for their own good... > Software that they can't fix for bugs, annoying behavious, missing > functionality etc.; and that could also have any number of intentional > anti-features: be it backdoors, cryptominers or other trojan horses; > adware; or digital restrictions management. Literally everything that > Free Software is supposed to protect users from. >
So here's my thinking on the subject, and how Coytotos provides what I want. If I am given a program to run on my personal system - whether I download it from the internet or get it from some other source - I want it to be confined. I don't want it to have access to any of my stuff. However, I don't want it to be confined *from me*. If I want to debug a program I'm handed, I should be able to. I should be able to inspect and modify its memory, make requests on its behalf etc. Thankfully, in the capability model, there's nothing strange about this. The program doesn't have access to anything other than what I have handed it. It's actually pretty easy to get this behaviour in Coyotos. Coyotos only provides functionality and isn't very prescriptive about how you use it. Part of building a system on Coyotos is adapting your system model to the primitives it provides. For example, Coyotos has Processes (somewhat akin to Mach threads), GPTs (a completely different level of abstraction to, but still somewhat like, a Mach task's vm map), process constructors, scheduler capabilities etc. Building something that looks and feels like a GNU process on top of these primitives is absolutely possible, and it doesn't have to have the same constraints. For example, there may be no need for a process to have direct access to its process capability, GPT, or the process constructor. Instead we have servers that implement the interface that GNU programs expect. By the same token, it's feasible to implement Coyotos in Coyotos and even be able to debug Coyotos-native applications. It's mechanism and not policy; it's capabilities all the way down. Part of implementing the system you want using these primitives is implementing memory allocation and management using the existing Coyotos spacebank. It's true that spacebanks do not automatically grant the ability to access pages granted in a child bank to the holder of the parent bank, which is a good thing. However, the memory manager that the system uses to provide applications with the mappings they need is free to manage its bank hierarchy and the pages it provides as it seems fit. This won't help when communicating outside the system - communicating to a process that requires a real space bank, such as the native process creator - but it means that within the higher-level system, you are free to implement whatever security model for memory you like. -- William Leslie Q: What is your boss's password? A: "Authentication", clearly Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely MAY reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior contractual agreement.
