Re: PID of client requirements

On Mon, Nov 04, 2002 at 08:58:47PM -0800, Thomas Bushnell, BSG wrote:
> How does the manager kill the process?  It isn't necessarily
> running as root.  It had better work whether running as root or not.
> 
> I can think of two ways:
> 
> Way One: It sends a signal.  To make this work, use the same trick as
> term. 
> 
> Way Two: It calls task_terminate.  To make this work, require the
> locking task to provide its own task port when acquiring the lock.
> 
> 
> However, way two is unacceptible, because users cannot be required to
> trust file servers.
> 
> I would suggest neither Way One nor Way Two, and go for something
> else:
> 
> If the manager sees that the lock is locked too long, it sends a
> message to the task and forcibly releases the lock.  The process whose
> lock has been broken can do what it likes (including, for example,
> terminate).

You are indeed missing the point.  I am not talking at all about how to do
such things cleanly and nicely.  My example was deliberately arbitrary, but
carefully set up around the following assumptions:

1. The manager program lives entirely in the POSIX world and doesn't know
   about the Hurd at all.
2. The rogue task lives in the Hurd world and knows about such dirty tricks
   like that the PID can be set to anything.

A POSIX program would not send messages, it would just use kill().  It could
rely on the information provided by GETLK that the process ID is valid and
always equals the process ID of the process having the lock, because that is
what the standard says.  If it would be running as root, it could kill() any
process.  Now imagine some unprivileged rogue process being able to set a
lock on the file.  In the POSIX world, this would be rather safe: Although
it would now have a lock (and thus might be able to make other privileged
processes stall if they relying on the lock), the manager process might at
some time notice it and kill this rogue process.  Net effect is that a bug
in the subsystem (makes the lock file readable for unprivileged users) is
only a small bug local to this subsystem (an attacker can only make this
subsystem hang by grabbing the lock for a while).

In the Hurd world, the rogue process could insert the PID of the root
filesystem, leading to a desaster.  So a small bug in the POSIX world would
be a grave bug in the Hurd implementation.

Now, the above locking example is not the ideal example, in that it relies
on a bug in the first place to illustrate the problem.  Lock files should
not be readable or writable to untrusted users.  But that is only the best
example I came up with so far.  I am worried that there are similar or worse
problems hidden.

To reiterate the question:  If the Hurd allows the PID to be provided
by the client, what (security) implications would this have on POSIX
programs making assumptions about the PID?

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    [email protected]
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
[email protected]
http://www.marcus-brinkmann.de/