On Tue, 2006-05-16 at 13:43 +0200, Espen Skoglund wrote:
> [Jonathan S Shapiro]
> > On Mon, 2006-05-15 at 20:29 +0200, Espen Skoglund wrote:
> >> o Depending on your definition of security, the presence of global
> >> names does not necessarily mean that the system is unsecure.
>
> > Yes. If you are prepared to redefine security to exclude
> > considerations of denial of service, fault isolation, or information
> > flow isolation, this is certainly reasonable.
>
> > But the credibility of such a definition would have to be severely
> > challenged.
>
> So, if I go ahead and tell a subsytem that: "These are the only names
> you're allowed to use. You cannot access any other names within the
> system or communicate with anyone outside of your subsystem." How
> exactly does this preclude denial of service, fault isolation, and
> information flow isolation.
Um, Espen? Haven't you read *any* of the security literature?
If program A cannot communicate with program B, then program A cannot
impose denial of resource on program B. Similarly, if there is no overt
information flow, the faults cannot propagate: faults are information.
Finally, if there is no channel of communication then there is no overt
information flow. This leaves the problem of covert channels, which is a
disturbing open problem.
Simply "telling" a subsystem that it cannot use certain names, of
course, accomplishes nothing. This is why enforcement is required. L4
has clans and chiefs, and I think we all agree that something more
efficient is needed. The *reason* that something more efficient is
needed is that the need for protection is nearly universal.
The argument for local names has two parts:
1. It is probably the simplest mechanism for enforcing the access
check.
2. By encapsulating the true name of the service, it allows the
service to alter its behavior or implementation in ways that
can be transparent to the client.
The second is an argument about a kind of virtualizability. In my
opinion, this is very nearly as important as the protection argument.
shap
_______________________________________________
L4-hurd mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/l4-hurd
