Hi, On Mon, Mar 15, 2021 at 07:58:33PM +1100, William ML Leslie wrote: > On Mon, 15 Mar 2021 at 05:19, Olaf Buddenhagen <[email protected]> > wrote:
> > Well, there is likely nothing we can really do with the system > > design that could prevent others from creating and certifying a > > setup without an almighty admin. Whether it's a good idea or not to > > provide this ability by default is a different question... But > > actually mostly orthogonal as far as I can tell from the question > > whether we want to provide a privileged constructor mechanism. I should qualify that: while you can have a system with a restricted admin without having protected constructors, and vice versa, both together arguably make the associated problems a lot worse... > > More importantly though, I believe that it's a bad idea to make the > > process appear as a child of the invoker: giving the impression that > > it owns that process, when in truth it doesn't. It presents a false > > process hierarchy, that doesn't reflect the actual ownership > > relations. Not only is this misleading: but I feel that it > > encourages a system design that relies on this mechanism more than > > it should, needlessly disempowering the user. I should probably elaborate on that, and put it in a larger context. (Note that I never used EROS or simlar systems; and haven't studied their documentation: my understanding is mostly just what I gathered from the various discussions 15 years ago... If I got anything wrong, feel free to correct me.) The motivation for using constructors generously, in my understanding, is that in principle, it offers an additional security property: when a process can use some resources not available to the invoker (the apparent parent), those resources are protected even when the invoker gets compromised. The issue with that is that unlike in a hierarchical system, the apparent parent can't inspect the process even for perfectly valid reasons. As long as the user session has access to the resources in question, this is not strictly limiting user freedom: since presumably, the user still has access to full control capabilities for the child activity, which they can use to explicitly launch a debug session in order to inspect the child process in question. However, that's less obvious; more cumbersome; the resulting relationships are less straightforward; and arguably it offers less flexibility in organising nested activities. (Alternatively, the user could explicitly pass the control capability to the parent activity, so it can do the inspection directly... Though in a system design that generally relies on the parent isolation, that would likely be frowned upon.) While inspecting a child is natural in a hierarchical system, it becomes more indirect in one involving constructors -- discouraging exploration. Up to this point though I can understand why some people would consider it a worthwhile trade-off, even if personally I don't like it. Where it becomes really problematic however is when a program uses resources the user has no access to, and thus the user can't get control over it. This too seems to be considered a desirable property in systems like EROS: with the argument that a password vault for example shouldn't be accessible, even when the user session is compromised... 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. Since in such a design, the admin is also not supposed to have access to a password vault, this of course implies not having an almighty admin -- meaning that even if there is a "friendly" admin, or the user is the admin, they are still at the mercy of third parties. This is exactly the same scenario as Apple and Google jailing users "for their own good". I hope we can all agree that this is *not* a desirable situation?... Of course, as I said before, the system designers can't really do anything to prevent a third party from creating a modified variant of the system, adding such problematic functionality, and trying to lure users to run it instead of the original. (E.g. by making it a precondition for using Netflix...) However, by providing the functionality as a central part of the system design, we are making this so much easier for them. This, I believe, is why Marcus concluded -- and why I am concluding -- that a system following GNU ideals MUST NOT come with this sort of functionality. This is not really a matter of opinion: it's an inevitable conclusion. Such a system is *not* facilitating user freedom -- at least not in the GNU sense. There is really no arguing that. > The constructor can take on a similar role to a setuid binary in that > it may have access to things the user does not, but that is not unique > to constructors really (it's true of most running system services, > also). Yeah, that's what I said myself... > What a constructor enables is local secure collaboration. If we use > the same machine, then I can run a program that you've shared with me, > and if you have provided it as a constructor then I can check that it > cannot leak any data or capabilities I provide it back to you (or > anyone else). The "local collaboration" case is extremely niche, to the point that it's not worth considering IMHO. It's one failed promise of the original Hurd design that I really don't see as a loss... More importantly though -- whether it's about user collaboration, or more general collaborating processes -- the "no leaking" property is mostly hypothetical, since it relies on the absence of covert communication channels... But in the real world, we can't avoid covert channels. (At most, we can limit their bandwidth.) > The process is "mine" in the sense that I have the authority to > reclaim its resources. That doesn't make it yours. You are only providing a runtime resource lease. You can revoke the lease: but otherwise, you have no control over the leased resources -- and certainly do not own the activities performed with these resources. I guess the takeaway is twofold: a), we should strive to minimise cases of discrepancy between resource ownership and activity ownership; and b), where such discrepancies are unavoidable, it is important to understand that what really matters (in terms of who controls whom), is the ownership relations of activities, not those of runtime resource leases... The system structure should reflect that. > The *default* should be not to leak information that isn't necessary > to other applications. For example, windowed clients shouldn't by > default get to learn about what other processes are visible, or what > brand of GPU is rendering them, or what keybindings are not passed on > by the window manager. I don't see how that requires privileged constructors?... (BTW, a system where applications don't know the GPU -- i.e. one without direct rendering -- seems a tough sell, if you are targeting desktop users...) > The aim should be to limit any surveilance or fingerprinting to the > level where it must be explicitly operated on, namely, at the express > request of the user, not a random process running on their behalf or a > broad root user that is misused by everything under the sun. There is no reason for a window server to require enhanced privileges. Indeed, Xorg/Wayland do not nowadays... But even in situations where privileged services *are* required, there is no reason for them to get full root privileges -- and that doesn't depend on availability of a constructor mechanism. -antrik-
