mirror of
https://git.FreeBSD.org/ports.git
synced 2024-11-15 23:50:44 +00:00
96 lines
4.6 KiB
Plaintext
96 lines
4.6 KiB
Plaintext
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.
|