Constructors vs. GNU (was: Future Direction of GNU Hurd?)

[Olaf Buddenhagen]

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 <olafbuddenhagen@gmx.net> 
> 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-