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

More Trust (was: "Re: (null)")

I originally wanted to run this past Kevin before posting it to the
list, but his address seems to have dropped off the face of the 'net:

  The original message was received at Fri, 21 Jan 2000 20:35:43 -0500
  from abuse@dialin-pm3-miami-FL-2-116.netrus.net []

     ----- The following addresses had permanent fatal errors -----

     ----- Transcript of session follows -----
  ... while talking to cs.cmu.edu.:
  >>> MAIL From:<troc@netrus.net>
  <<< 451 Nameserver timeout during parsing
  <lenzo@cs.cmu.edu>... Deferred: 451 Nameserver timeout during parsing
  Message could not be delivered for 5 days
  Message will be deleted from queue

So, here's the message:

On Thu, 20 Jan 2000 22:38:35 -0500, Kevin Lenzo wrote:

>scozens@pwj.co.jp wrote:
>> Rocco Caputo writes:
>> > On the receiving end, you get an event that says "you got this
>> > thing, \@thing".
>> Eee. Um. That's nice, but... isn't it a little trusting? I mean,
>back to vivification. if Infobot=HASH(), or its image, is seen
>in the serialized form (as with using Leolo's XML::Storable),
>the object getting the reference should make appropriate moves
>to vivify the code of an object from the _internal_, safe store.
>i'm not sure how the ref server does this, but i think the
>vivification mechanism puts a lot of the burden of security
>onto the users faith in their internal code, which is pretty
>much on par with using modules.  and modules, it seems, should
>be able to authenticate and secure channels as any other
>Entity might... hmm.

Filter::Reference just passes references around.  Stuff's frozen on
the sender side (&freeze call); it's thawed on the receiver's side
(&thaw).  If it was blessed to begin with, it's reblessed at
reconstitution time.  It makes no guarantees about the validity of the
data that it moves; that's better left to the receiver because she
knows what the data's supposed to look like.

>> > Artur/Sky has a patch pending that lets it use Compress::Zlib
>> > transparently, so network traffic can be balanced against CPU.
>> Oh, wow. That's special.
>Do we have Filter::PGP yet? That or something like it would
>help move the burden of authentication.  You could trust
>some hosts more than others for certain types of transfer --
>like tainted 'references' that might vivify into evaled perl code. 

Stackable filters would be excellent here.  Pipe::PGP looks like a
good start for a Filter::PGP.  The filter would probably build a
Pipe::PGP in the background at constructor time, and sign,
authenticate, encrypt or decrypt the things that go through it.

Speaking of validating tainted references, here's some design I have
in a dusty old development directory.  Its MUD/Agentspace focus may
not be entirely appropriate for infobot, but it seems to address some
of the same problems.

[ Names: Universe is an object environment/MUD/Agentspace; Continuum
is a peered network of universes. ]

Object Transferrence (Roaming)

Sending an object 
  1. Extract a portable representation of the object from the
  2. Recursively extract as portable representations all templates
     from which this object inherits.

     [ This assumes a sandbox, possibly running atop one or more
     virtual machines, and an object repository that treats code
     as data.  I seem to be writing this in my spare time. ]

  3. Bundle the objects together. 
  4. Prepend internal headers to the object bundle. 
  5. PGP sign the object & headers. 
  6. Compress the bundle & headers. 
  7. Prepend external headers to the compressed object bundle. 
  8. Place the headers and bundle into the outbound object queue. 
Receiving an object 
  1. Accept the object and place it in an inbound queue. 
  2. Record important details of the transfer as external object

       The machine ID of the remote Universe. 
       The date and time of receipt. 

Dequeuing a received object 
  1. Remove the object from the inbound queue. 
  2. Verify the external headers. 

     1. Contact the object's alleged home Universe and acquire its
        PGP public key if necessary.  If the alleged home Universe
        is unreachable, add an "unreachable" external header to
        the object and put the object back in the incoming queue
        with a 15-minute "do not disturb" delay.  Double the DND
        delay for every subsequent connection failure. Return the
        object to its author after 8 failed attempts to acquire a
        PGP key. Set the destination address to the object's
        alleged author and place it in the outgoing object queue. 
     2. Decompress the object. If the object fails decompression,
        add a "damaged object" external header, set the destination
        to the alleged author, and place the object in the outbound

  3. Verify the object's signature. If the signature does not
     match (what?), add a "possible forgery" external header,
     set the destination to the alleged author, and place the
     object in the outbound queue.
  4. If the object passes all initial tests, import it and the
     templates it rode in on. Place the object in a safe landing
     area. Access permitting, the object may be able to leave
     the landing area and move about the Universe.
  5. If the object crashes for any reason, it is packed up and
     shipped back to its owner with external headers describing
     the reasons for error.

External Object Headers
    Each object requires a plaintext From header so that the
    receiving Universe knows where to look for a public PGP key.
    The rest of the headers will be inside the signed, compressed
    object. This header is external so that there is a chance of
    returning corrupt objects.

    If the key acquired from the Universe in the From header does
    not match, then the object is returned to the From site in a
    body bag with a "possible forgery" note.

    If the PGP key is on file, but the key's source does not match
    the Universe in the From header, then the object is sent to the
    Universe in the PGP key with a "possible forgery" note. 

Internal Object Headers 
  Personal Security Level 
    Contains the level of trust that the object's home Universe
    placed in the object's author at the time when the object was

Notes about PGP & Sharing Objects 
  Long, blocking processes 
    A second process will be required to handle time consuming
    tasks including PGP signatures and verification. This can be
    tied into the main process with a soft-blocking job queue or
    a non-blocking queue with job-completion callbacks.

    Every Universe in a Continuum must use the same time standard.
    The Universe kernel will detect strange time changes and realign
    its clock to stay current.

  Object IDs 
    Object IDs are unique even across Universes since part of the
    ID is the object's home Universe. This allows Universes to
    assimilate foreign objects without namespace problems.

  Object Purity 
    Objects may only inherit from templates originating in the
    local Universe. A local Native user may copy foreign objects
    to make inheritable local versions with separate Object IDs.
    The new USL becomes Native and is owned by the admin. This
    is a potential security hole. Be sure to check over the
    object's code before allowing it to be invoked.

    [ Templates do not rely on Safe.pm; instead, they are a
    source-validated subset of Perl with object manipulation
    extensions.  Universe code (Ptah) is validated and translated
    into native Perl, then eval'd into a coderef for reuse. ]

  Template Expiration 
    Imported templates expire when all objects using them have
    left the Universe. Since each incoming object has the
    templates it needs, we can expire them as soon as they're

Security Classes
  Universal Security Class (USC) 
    The USC is the amount of trust that the local Universe
    places in the Universe where an object was created.

  Personal Security Class (PSC) 
    This is the amount of trust that the object's native
    Universe admin places in the user who created the object.
    An object's author's PSC is embedded in the object at the
    time it is exported from a Universe. Roaming agents' PSCs
    do not change even if the author's PSC changes. 

        This Universe does not trust the remote Universe at all.
        This is equivalent to the stranger USC, but the object
        is returned immediately to the source with an access
        violation. The admin who flags a Universe as malicious
        must record the reasons behind doing so. Those reasons
        will be included in the access violation message, along
        with the date and time of the access change and the name
        of the admin who flagged the Universe.

        The malicious Universe's USC may be changed by a quorum
        of admins. If there are fewer than three admins, then the
        malicious Universe must be approved twice. The malicious
        status doesn't change automatically.

        This Universe does not trust the user at all. This is
        equivalent to the stranger PSC, but the user must be
        approved by a quorum of admins before they can become
        familiar. If there are fewer than three admins, then the
        user must be approved twice. The malicious PSC does not
        change automatically.


        This Universe does not have the PGP public key for the
        object's home Universe on file. The object will be held
        in escrow until this Universe can acquire the object's
        home Universe's public key for signature validation. The
        object's home Universe's USC becomes familiar when the
        PGP key is acquired.


        The object's author is a temporary or anonymous user. The
        admin places minimal trust in this user, and any objects
        she creates have access only to the most harmless commands.
        She probably doesn't even get to use loop commands.


        The local Universe has the object's home Universe's PGP
        public key on file, but the local one doesn't place special
        trust in the remote one. The object's home Universe may
        then be held accountable for the actions of its users.

        The object's author is registered with her home Universe.
        She is accountable for her objects' actions, but she
        doesn't have enough access at this point to do any damage.
        This type of user has access to normal commands. Some
        denial-of-service attacks (infinite loops, for example)
        may be possible, but the system must be able to recover

        Denial-of-service exceptions will be logged, and the system
        may temporarily flag users and remote Universes as malicious
        if they generate more exceptions per unit time than the admin
        thinks is reasonable.

        The local Universe places extra trust in the Universe where
        the object was created.

        The object's author is a special friend of the admin. Trusted
        users' objects have access to more dangerous commands, but
        they should not have access to private system or user data. It
        should be impossible for a friend object to permanently harm a
        Universe. Think "co-sysop".

        The object was created in the local Universe. Objects created
        in other Universes never have the Native USC. The local
        Universe completely trusts itself.


        The user of this object is an admin in her home Universe. She
        has ultimate access to everything, but the system should still
        be robust in the face of admins of little clue.

Class Combinations

  Universal + Personal = Combined security level

  Stranger + Stranger = None
  Stranger + Familiar = None
  Stranger + Friend   = None
  Stranger + Native   = Minimal

  Familiar + Stranger = None
  Familiar + Familiar = Minimal
  Familiar + Friend   = Average
  Familiar + Native   = Average

  Friend   + Stranger = None
  Friend   + Familiar = Average
  Friend   + Friend   = Average
  Friend   + Native   = Extra

  Native   + Stranger = Minimal
  Native   + Familiar = Average
  Native   + Friend   = Extra
  Native   + Native   = Ultimate

>> > On the decentralized side, factoids could be propagated like
>> > Usenet news messages.  Factoids won't get lost if there are
>> > redundant paths.
>> OK, let's take this principle and run with it. Here's my complete
>> train of thought on how interbot is going to work if we go with a
>> peer-to-peer network. How you traverse it is up to you, but I've tried
>> to make it a DFA. :)
>Phew! OK i have some ideas to throw into the pot here.

This explodes my brane.  I'll chime in again on it once I
can wrap my head around it.

-- Rocco Caputo / troc@netrus.net / *paf*