[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Just a few questions
From: |
Jonathan S. Shapiro |
Subject: |
Re: Just a few questions |
Date: |
Mon, 24 Oct 2005 15:11:39 -0400 |
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
- Re: Just a few questions, (continued)
Re: Just a few questions, ness, 2005/10/23