On Fri, Nov 5, 2021 at 1:41 PM Samuel Thibault <samuel.thibault@gnu.org> wrote:
>
> William ML Leslie, le ven. 05 nov. 2021 21:18:50 +1100, a ecrit:
> > > which makes the root filesystem reauthenticate all of the
> > > processes file descriptors.
> >
> > It seems to eliminate a rather convenient method of delegation; a
> > process opening a descriptor, forking and executing a child, and
> > dropping privileges, while retaining access to that one resource.
>
> reauthenticating doesn't mean closing. File permissions for open are
> checked at the open step, not later on. But then there are other things
> than just opening a file, such as starting a translator, which we don't
> necessarily want to let the unprivileged-with-one-opened-file do.
If I may add to what Samuel has said...
The Hurd is a capability system, but not a *pure* capability system:
it implements Unix semantics on top of Mach/capabilities. File
descriptors, exec, setuid, etc. are all Unix concepts.
Indeed, and the reason I ask is because I'd like to enable more capability patterns, even though Mach and The HURD don't protect ports like they are capabilities (c.f. hurd/utils/msgport.c for some really cool and impressive "look at how much power you have!" moments).
And in a Unix
system, you definitely expect that a change in a process' authority
applies to things like which files it is allowed to open through a
file descriptor that refers to a directory, which is why all the file
descriptors have to be reauthenticated when the auth changes. The file
descriptor table is really meant to hold I/O objects, not arbitrary
ports; and I/O objects are expected to behave in a predictable way
when reauthenticated: you keep access to the object, but the object
reconsiders what further things you can do to it / access through it,
according to your new authority.
I'm still not confident this is the right approach, but if that's limited to changing the behaviour of translator nodes that is much less scary.
One wonderful property of capabilities is that delegating them works. You should be able to weaken them deliberately, but having them weakened for you is a bit weird. The stranger thing is having them become more powerful without an explicit action. Implicitly gaining more power on what is supposed to be a capability sounds like a new way to introduce a confused deputy vulnerability. I have read access to this, I exec you, and you have write access. If you were fishing this file out of the file system you'd expect it to have your authority, but if you were passed it from another program, you expect to use the authority that the caller provided and no higher.
As another example, you can open a
device while you have root access, then drop privileges; you'll still
be able to read or write the file descriptor, but you won't be able to
fchown/file_chown it.
Righto yes, a port to an open file is a port to an io object, and io objects can implement messages like io_mod_owner and so. I'd missed that these were not distinct responsibilities.
If you ignore the Unix personality of the system, you can indeed pass
any ports to an otherwise unprivileged task, but you better do it
outside of the file descriptors table. The Mach mechanisms for that
are the bootstrap port and mach_ports_register ().
Or alternatively, ignore glibc exec() and talk to the exec and proc servers directly.
--