l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future Direction of GNU Hurd?


From: William ML Leslie
Subject: Re: Future Direction of GNU Hurd?
Date: Thu, 18 Mar 2021 19:35:26 +1100

On Mon, 15 Mar 2021 at 19:58, William ML Leslie
<william.leslie.ttg@gmail.com> wrote:
> To a first approximation, I guess.  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).  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).
> Similarly, you can know that I can't open your program up in the
> debugger and force it to leak or misuse your authority.  The process
> is "mine" in the sense that I have the authority to reclaim its
> resources.
>
> I don't imagine that this feature will be used that much between
> different users on the same system, but more likely between two
> different processes.  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.  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.
>

I feel it's worth saying that constructors aren't super useful anyway,
as far as I can tell.  They can only attenuate read authority, and so
aren't really a substitute for the setuid mechanism.

They aren't really an essential part of the system, they require no
kernel support (unless you *really* squint at Descrim), the truly
special part is the attestation about non-leakage, which isn't very
useful for system services or for most kinds of collaboration, anyway.

It's easy enough to ignore them, at least as far as the GNU is
concerned; leaving only the missing facilities for debugging and
inspection that aren't so difficult to add.

-- 
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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]