task info cap access

[Marcus Brinkmann]

Hi,

we talked at the weekend about task info capabilities (formerly known as
task ID references, or task ID handles).  You showed me how they could be
passed from one task to another like normal capabilities, and since then I
made variants of my protocols that would do it that way, and calculated the
additional cost for that.  However, I also constantly thought if they are
really necessary and what functionality they provide.  I think I found out
why I am intuitively not convinced of the merit of this approach:

A task info capability does not protect anything you own yourself.  So there
is no incentive for you to keep it private.  For example, if you open a
private file, and get a file capability, then surely you have an incentive
to keep it to yourself because the file is owned by you and you want to
protect the data it contains etc.

However, a task info capability does not give you an advantage.  It's only a
burden.  It might have negative effects on your system wide quota (to
prevent DoS attacks), and the only thing that it protects is the task ID,
which you don't have any control over anyway (you can not choose which task
ID you want at task creation time).  So, for example, if a server gave out
its task info capability to an untrusted user, that untrusted user could
just give it to everyone who wants it, without any loss.

My main argument that there is no incentive for a task to keep task info
capabilities private, and thus there is no need to protect them.  You could
also say that restricting access to them by requiring that they are passed
from one task to another is not an effective method of controlling their
distribution.  

Consider that in the Hurd, you can try to send signals to any task.  The
implementation of signals in the Hurd on L4 will require tasks to do their
own handshake and authentication with the sender of the signal: proc can not
be bothered to keep the signal capabilities to all tasks (it can not accept
them, as they come from untrusted clients).  So proc will only store the
signal thread id in the client, which you can read out.  In the initial
handshake, the tasks would have to exchange task info capabilities _before_
any further authentication happens.  There is nothing that prevents you from
guessing the signal thread id of other tasks.  A similar handshake will be
necessary to contact mounted translators, as the parent filesystem can not
provide the root dir capability of an untrusted mounted filesystem. 

The logical conclusion is, that under normal circumstances (glibc linked
programs with signal thread), you can get the task info cap from any other
task anyway, they just give it out to you, no questions asked.  This
illustrates my point above that tasks have nothing to lose giving out task
info caps.

What are effective ways to control creation of task info capabilities?

* If a task does not release the task info cap for a dead task timely,
  it could be revoked and the task ID be reused anyway.
* If a task does not release the task info cap for a dead task timely,
  the dead task could be added with the cost of a normal task to its
  quota.
* Proc can list dead tasks as some obscene sort of zombies, and also make it
  possible to list tasks that have outstanding task info capability
  references to the dead task.
* The task server can limit the number of task info capabilities in one task
  to the number of _live_ tasks in the system, maybe plus some slack.
  Then a task has a real incentive to release dead info capabilities.  If it
  tries to acquire a new task info cap and that fails because of the limit, it
  can block until it received and processed the pending task death
  notifications.

Especially the 2nd and 4th item in the list seems to me to be quite
effective.  Also, any of the above is equally effective if task info caps
are protected or given out freely.  So it doesn't seem to matter to me from
the functionality point of view.

Allowing anybody to acquire any task info caps they want is faster and less
complex, IMHO.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/