1. A presentation by Robin Upton (2009-03-24) ‏ Latest version at www.altruists.org/ff10 Attribution – NonCommercial - ShareAlike www.altruists.org FF 10 : Access Control Recommended Pre-requisite: FF9: Filters V1.0.1 http://www.altruists.org/ff10

2. Identity relies on Digital Signatures http://en.wikipedia.org/wiki/Public-key_cryptography soft-system Public Key Soft-systems have a cryptographic key-pair soft-system Public Key soft-system Public Key Soft-systems identify incoming packets by their digital signature. Soft-systems use their private key to sign outgoing packets & their friends’ public keys. Private Key Public Key

3. Incoming Packets External packets arrive at the root signed with a @public-key. / f2f f2f/guests f2f/guests /jim /f2f/lib /f2f/lib /demo f2f/guests /tom /f2f/lib /etc @uid top The root node has a list of all friends’ keys... Soft-nodes track identity with @uid. & a filter to map @public-key → @uid signed data.key.xml

4. Outgoing Messages Outgoing messages arrive at the root tagged with @uid. / f2f f2f/guests f2f/guests /jim /f2f/lib /f2f/lib /demo f2f/guests /tom /f2f/lib /etc @uid top The send-by-uid service manages cryptography & addressing. The root node has a list of all friends’ keys... & a filter to map @uid → @public-key signed data.key.xml

5. @uid The root node’s filters maintain 2 datastores, indexed by @uid: The send-by-uid service abstracts away cryptography & addressing from the programmer http://friend2friend.net/modules/firewall/ @uid data.key.xml XSL templates access the caller of a service as $_f2f-thread-uid data.address.xml Messages’ @uid is at the heart of the soft-system’s access control.

6. /f2f/example Controlling Access to Services http://www.altruists.org/ff11 Each soft-node has its own set of access control lists * Although required, the F2F namespace is omitted for brevity. It has either a whitelist (default=“deny”) or a blacklist (default=“allow”)‏ Each service has a list defining which @uids may access it caller’s @uid ($_f2f-thread-uid)‏......

7. Subsequent processing has the original caller’s @uid. Privileged Services A service with @privilege=“N” is processed up to N times in a child thread with a different @uid, usually that of its module. /f2f/example.................. this module’s @uid caller’s @uid...... If this service has @privilege=“1”... The first time it is processed, it has a different @uid

8. Permanent Privilege A service with @privilege=“*” continues with a different @uid until processing terminates. /f2f/example.................. this module’s @uid caller’s @uid......... Care should be taken to avoid privileging arbitrary s.

9. Module Requirements F2F modules’ signature’s public-keys are mapped to @uids. These identities are given to the module’s privileged services. A module’s @uid may always access its own services, but must list the other services it uses, as follows: This is used to check of dependencies and to grant permissions when a module is added to a soft-system.

10. Additional Access Considerations Services with admin=“1” may only be used from the administrator’s soft-server. Services with visibility=“private” are hidden from other soft-nodes, so requests from outside will not resolve. F2F basic access control is an XML-based system, on which more advanced layers can be built. Soft-nodes have a wildcard access list that controls whether @uids can executing any threads. The core services access-get & access-set provide hooks for integration with scripts.

11. Summary Recommended Follow-up: FF11: Modules http://www.altruists.org/ff11 Soft-systems allocate uids to signed packets. signed The root node stores keys & addresses in databases. Soft-nodes have a separate ACL for each service.