1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
From the FAQ:
5. 'Saaaay, what _is_ the design of Penguin?'
Glad you asked.
Consider two machines, foo and bar. A user on foo (or perhaps
a program on foo) wishes to execute a program on machine bar.
However, imagine that the people running bar don't want just
anyone running code on their machine for security reasons.
This is the normal case on the Internet, and one which the
World Wide Web attempts to emulate with HTTP and CGI.
Normally, there is no well-known channel for foo to transmit
code to bar. Further, there is no provision for the code to
undergo verification after transmission. Too, there is no
well-defined way for bar to ensure that foo's code does not
attempt to perform insecure or damaging operations.
Penguin attempts to solve these issues while making sure the
code language maintains some acceptable degree of sufficiency
and power.
Using Penguin, the user/program on foo 'digitally signs' the
code that's earmarked for delivery to bar. The signature
encodes the code in such a way that it is impossible to alter
the code or deny that the signer signed it.
The code is then wrapped up into a packet and transmitted
through a 'channel' to a Penguin process running on machine
bar. The channel's protocol layer is abstracted away
enough that it becomes unimportant; Penguin code can just
as easily be delivered through SMTP or AOL Mail as through
TCP/IP, DECNet, AppleTalk, whatever.
The Penguin process on bar unwraps the packet, which contains
further verification and checksum information, and then
'digitally unsigns' the code, a process which provides the
code in 'clear' form while telling the receiver who digitally
signed it.
The receiver then cross-references the signer's identity with
a list of rights that the receiver associates with the signer,
reverting to a set of default rights if the signer is unknown
or unlisted.
A safe compartment is then created, populated with the
functions allowed to the signer, and told to limit the
operations it can perform to only those permitted to the
signer.
The code is then compiled within that safe compartment. If
it attempts to do something which the signer is not allowed
to do, or if it attempts to call a function not permitted
to the signer, the compartment immediately traps the operation
and throws the code away before it can execute. If the code
uses no unsafe or illegal operations, then it executes and
produces a result.
The code executing side then becomes the master in the
transaction, and can send code to the original sender,
send the return value back in a data packet, and so forth.
The process repeats as necessary until both parties are
done; the channel then closes, and the Penguin transaction is complete.
The basic sentiment behind the idea of 'identity' being
correlated to 'rights' in the receiver is that in signing
the code, the signer commits her identity and her reputation
on the correct operation of the code.
'highly trustable' signers (as one might imagine Larry Wall,
Randal Schwartz, and Tom Christiansen to be) might be assigned
very high levels of trust and equivalent degrees of 'rights',
so that programs they sign can perform very complex and
interesting operations on your computer. By the same token,
paranoid sites or those wishing isolation could assign zero
rights to everyone except for a select (perhaps internal) few.
Part of the 'rights' given to signers include possibly specialized
functions that encapsulate the functionality of extremely dangerous
operations. For instance, a store opening up on the Internet might
put up a Penguin server which put functions called 'list_items'
and 'buy_item()' into the limited compartments all users get.
'list_items' might open up a file on the store's machine, read
the contents, and spit them out -- an operation which, if allowed
in the general case, would clearly breach security. However,
by creating a specialized function, the security concern is
removed, and by letting potential customers know of the function,
the power and ease of use are kept high.
Niggling but important technical issues currently being wrestled
with include the way that foreign functions are registered into
the namespace, the construction of a foreign function framework
so that the names and function of the functions are well-known,
and a superior-than-current 'digital signature' method.
|
