Re: Just a few questions

[Jonathan S. Shapiro]

On Sun, 2005-10-23 at 19:39 +0100, Justin Emmanuel wrote:
> Thanks for the prompt replies;
> 
> So let me get this right, if I hack an application (Capability A)and
> take over execution with my virus the kernel should be able to identify
> me as cap A.

Justin: it is very difficult to answer this question, because your
terminology is still very confused. The capability and the application
are distinct things. The application is a program that is running
somewhere. The capability is an operating system protected descriptor
that names a process.

This is similar to the distinction between a file and a file descriptor.

In the situation you describe, the kernel's ability is limited. In EROS,
what the kernel can actually certify is the following:

  When this process was started, it was (or was not) started by a
  particular constructor.

More precisely: there is a kernel capability that the constructor can
use to answer the question:

  Did you (the constructor) start this process?

The process can later be compromised -- the identification function does
not prevent this and does not attempt to detect it. There are various
ways to make this compromise exponentially more difficult than it is in
a POSIX system -- which is one reason EROS is not a POSIX system.


>  It should have  list of my rights somewhere so I shouldn't
> be able to do any copying that I am not allowed to do by my kernel
> designated rights.

Every process has a capability address space, in the same way that every
UNIX process has a file table. This *is* the list of rights.

>  However if I then create a new process with copying
> rights I can then get the system to copy my code with my newly created
> capability or are Rights recursive? So that a child process can have no
> more rights than than its parent?

I do not understand what "newly created capability" you are referring
to, unless you mean "I have created a new process and now I hold a
capability to this new process."

You can only copy rights that you hold. You are not *obligated* to copy
rights that you hold. I would not characterize this as recursive.

> Am I guessing correctly when I say that the kernel will ID a capability
> by its memory location?

It does not rely on memory location. I have previously described the
mechanism in:

        http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00020.html

the description is about mid-way down, starting at "The more general
solution..."

> In
> that case what about RPC's? How can cross system procedure calls be
> securely identified?

They cannot, unless the two kernels involved trust each other entirely.
This is axiomatically and necessarily true; it is not a limitation of
capabilities.

> In Eros/Coyotos all processes are capabilities. Is this same
> understanding being applied to this project?

Since this is not true in EROS/Coyotos, I hope not. :-) Capabilities
*name* processes (or, in some cases, kernel-implemented objects). They
are not the same as processes.

> >From what I have seemed to grasp a capability is an atomic unit of
> ability. Therefore it is system of controlling actions within a
> names-space. (I could be completely wrong, this is just what I have
> seemed to understand). Therefore a capability is an ID/Ability
> combination. All internal processing within the process can be seen in
> the normal method/attribute manner but any interaction with the system
> then needs to be looked at in the ID/Ability way. This would probably
> include all instantiations as they will each need there own ID/Ability
> pair.

This is close. A capability is a (resource-id, interface-id) pair. There
has already been an extensive discussion of this. Please examine the
l4-hurd archive.

> How can the system make sure that memory leakage is avoided? This is
> particularly important with a persistent operating system.

Please examine the l4-hurd archive for October, 2005.

> I heard that the kernel should never be permitted to kill a process! Why
> not? Particularly if a process has gone out of control. Whats the
> thinking in that?

There is a difference between *halting* a process and *destroying* a
process. Stopping execution is perfectly fine. The decision about when
to reclaim the process state is a policy decision, and should not be
made by the kernel.

This has also been discussed in the archives for October.

> In Eros/Coyotos all applications are limited to an application-user
> delimited name-space. If not a capability-user delimited name-space, an
> idea that I think is particularly good. What is the projects leanings
> towards this idea at current?

I am not sure what you mean by "name space" here, and this is VERY
important to understand correctly. An EROS/Coyotos (and, I think,
L4.sec) application has an address space of capabilities. There is no
other kind of name space that is known to the kernel in any of these
systems.


shap