[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
More Trust (was: "Re: (null)")
- Date: Wed, 26 Jan 2000 20:55:43 -0500 (EST)
- From: "Rocco Caputo" <email@example.com>
- Subject: 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 [188.8.131.52]
----- The following addresses had permanent fatal errors -----
----- Transcript of session follows -----
... while talking to cs.cmu.edu.:
>>> MAIL From:<firstname.lastname@example.org>
<<< 451 Nameserver timeout during parsing
<email@example.com>... 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:
>> 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 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.
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. ]
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
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
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.
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 / firstname.lastname@example.org / *paf*