[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

inheritable file system objects, part 1: security



Rob Rodgers wrote:
>Security isn't it:  Any program that's useful
>is going to be able to pull the same kind of 
>nonsense on Inferno that trojans &c pull today.

Not so. Controlling functionality visible for any program/process
through stack directories (they call them unions in Inferno, I thought
the Plan 9 term "stack directory" captured the essence of this object
inheritance mechanism) is a novel, patented mechanism. Suppose you have
a program which downloads anonymous code (the worst case). You might
want to give it:

- read-only rights to all public Internet, 
  so it can read any public information
  but is unable to send your secrets someplace
- "use" rights to all your non-critical networked resources
- write rights to any set of directories you pick

This is just a matter of doing some mounts and binds to hide and reveal
parts of your visible resource (file system object) space for the new
process. If the granularity of available resources/functionality is not
right, you can use pre-programmed, often trivial auxiliary "guardian"
file systems stacked on the originals inheriting and redefining their
functionality, or program them yourself.

This is a central aspect of essential Inferno innovativeness (It has
more aspects, though, relating to general objectives of language
independent, persistent, networked objects). It is so novel the
JavaWorld article simply missed the whole idea, as you seem to miss,
too. And this was what works within any environment and regardless of
the programming tools used. Within Styx networks there is the additional
security of user and group rights, authentification, verification and
encryption.
 
Anssi