8,288
edits
Changes
Jump to navigation
Jump to search
Line 9:
Line 9: − + Line 16:
Line 16: − + Line 27:
Line 27: − + Line 33:
Line 33: − + Line 40:
Line 40: − Provide Sugar users registration on a school server. After being registered, Sugar on users side will setup interaction with a school server. See [[Sugar_Server_Kit/sugar-client|sugar-client]] project for details from client point of view.+ Line 68:
Line 68: − + − + − + − + − Backward compatibility:+ − + − + − + Line 96:
Line 96: − + Line 104:
Line 104: − + − Backward compatibility:+ − + − + Line 126:
Line 126: − + − Backward compatibility:+ − + − + Line 141:
Line 141: − + − + − + − + − + − + − + − + − + − + − + − + Line 190:
Line 190: − + − + − + − + − + − + Line 209:
Line 209: − +
Platform Team/Server Kit/sugar-server (view source)
Revision as of 21:51, 2 December 2011
, 21:51, 2 December 2011no edit summary
=== Registry ===
=== Registry ===
During the sugar-server work, all its components have access to a registry, an analog of database to keep information about registered users or activated machines. The registry is file based, i.e., every item is being kept in one file (in JSON notation) in {{Code|<root-option>/home/registry}} directory.
During the sugar-server work, all its components have access to a registry, an analog of a database to keep information about registered users or activated machines. The registry is file based, i.e., every item is kept in one file (in JSON notation) in the {{Code|<root-option>/home/registry}} directory.
There are two subdirectories, i.e., "tables":
There are two subdirectories, i.e., "tables":
* {{Code|machines}}, for machines that requested activation leases on bootstrap.
* {{Code|machines}}, for machines that requested activation leases on bootstrap.
Registry items might contains the following keys:
Registry items might contain the following keys:
* {{Code|uid}}, user's identity got after registration on a server;
* {{Code|uid}}, user's identity got after registration on a server;
The list of services that sugar-server provides. Each service has a described interface to understand how it interact with clients. The counterpart for these interfaces is the [[Sugar_Server_Kit/sugar-client|sugar-client]] with a [[Sugar_Server_Kit/Client_API|Client API]] it provides for clients, e.g., Sugar Shell.
The list of services that sugar-server provides. Each service has a described interface to understand how it interact with clients. The counterpart for these interfaces is the [[Sugar_Server_Kit/sugar-client|sugar-client]] with a [[Sugar_Server_Kit/Client_API|Client API]] it provides for clients, e.g., Sugar Shell.
If particular service supports RESTfull interface, the HTTP server is started on {{Code|host}} with {{Code|httpd-port}} port. The content of requests and replies is being transfered using dictionaries in JSON notation.
If a particular service supports a [[wikipedia:Representational_state_transfer |RESTfull interface]], the HTTP server is started on {{Code|host}} with the {{Code|httpd-port}} port. The content of requests and replies is transferred using dictionaries in JSON notation.
The resulting dictionary on success, will contain predefined keys:
The resulting dictionary on success, will contain predefined keys:
* {{Code|success: OK}};
* {{Code|success: OK}};
The resulting dictionary on fails, will contain:
The resulting dictionary on failure, will contain:
* {{Code|success: ERR}};
* {{Code|success: ERR}};
=== registry ===
=== registry ===
Provides Sugar users registration on a school server. After being registered, Sugar on user's side will set up interaction with a school server. See [[Sugar_Server_Kit/sugar-client|sugar-client]] project for details from the client point of view.
Interface:
Interface:
* {{Code|jabber-url}}, if {{Code|registered}} is {{Code|True}}, Jabber server url;
* {{Code|jabber-url}}, if {{Code|registered}} is {{Code|True}}, Jabber server url;
* {{Code|backup-url}}, if {{Code|registered}} is {{Code|True}}, Rsync url to backup Journal to, needs to be used as-is.
* {{Code|backup-url}}, if {{Code|registered}} is {{Code|True}}, Rsync url to backup Journal to, needs to be used as-is.
* {{Code|pending-restore}}, is there pending restore, i.e., if {{Code|True}}, during the registration on a server, there was an existing backup; any further, after registration, backup or restore will clean up {{Code|pending-restore}} flag.
* {{Code|pending-restore}}, is there a pending restore, i.e., if {{Code|True}}, during the registration on a server, there was an existing backup; any further, post registration, backup or restore will clean up the {{Code|pending-restore}} flag.
Requested uid might be not registered in cases like:
Requested uid might be NOT registered in cases like:
* registration was removed from the server,
* registration was removed from the server,
* request was sent to the server not the same where uid was created,
* request was sent to a server that was not the same as where the uid was created,
* someone [[#Vulnerabilities|registered]] the same serial number.
* someone [[#Vulnerabilities|registered]] the same serial number.
Requirements:
Requirements:
* Current Sugar Shell code calls only XML-RPC method suing hard coded {{Code|http://schoolserver:8080/}} url. This restriction can be avoided using [[Sugar_Server_Kit/sugar-client|sugar-client]].
* Current Sugar Shell code calls only XML-RPC method using the hard coded {{Code|http://schoolserver:8080/}} url. This restriction can be avoided using [[Sugar_Server_Kit/sugar-client|sugar-client]].
Backwards compatibility:
''dict'' '''register'''(''str'' machine_sn, ''str'' nickname, ''str'' machine_uuid, ''str'' pubkey)
''dict'' '''register'''(''str'' machine_sn, ''str'' nickname, ''str'' machine_uuid, ''str'' pubkey)
To support OLPC's XS clients, RPC function to serve registration requests. The XML-RPM service will be listening {{Code|8080}} port on the {{Code|--host}} host.
To support OLPC's XS clients, RPC function to serve registration requests. The XML-RPM service will be listening to the {{Code|8080}} port on the {{Code|--host}} host.
=== backup ===
=== backup ===
Process backup and restore for students' Journals. The service is accepting requests that clients send before starting backup process. If server accepts requests, clients start Rsync'ing Journal data via SSH. The Rsync url needs to be gotten from {{Code|/client/status}} request and be used without any modification on the client side, i.e., the process is fully server driven.
Process backup and restore for students' Journals. The service accepts requests that clients send before starting the backup process. If server accepts requests, clients start Rsync'ing Journal data via SSH. The Rsync url needs to be obtained from a {{Code|/client/status}} request and be used without any modification on the client side, i.e., the process is fully server driven.
Users' backups are being stored in {{Code|<root-option>/home/backups/<UID's-last-two-chars>/<UID>}} directories.
Users' backups are stored in the {{Code|<root-option>/home/backups/<UID's-last-two-chars>/<UID>}} directories.
Interface:
Interface:
GET '''/client/backup'''?uid=''UID''
GET '''/client/backup'''?uid=''UID''
Check if client can start transfering Journal files using.
Check if client can start transferring Journal files.
The resulting dictionary, contains:
The resulting dictionary, contains:
Requirements:
Requirements:
* The {{Code|root}} configuration option should point to the home directory of system user that starts sugar-server process. That needs because clients will SSH to this user to do Rsync backups.
* The {{Code|root}} configuration option should point to the home directory of the system user that starts sugar-server process. This is needed because clients will SSH to this user to perform Rsync backups.
Backwards compatibility:
Note, this backup functionality does not compatible with client tools that work with OLPC XS. The problem is that these tools construct backup url on a client side (using only server host name from backup url given after registration on a server) with relying that every client has its own system user on a server side. That doesn't work with new backup functionality where there is only one system user on a server side and authorisation happens on SSH level (using {{Code|command}} option in {{Code|~/.ssh/authorized_keys}} file).
Note, this backup functionality is not compatible with client tools that work with OLPC XS. The problem is that these tools construct a backup url on the client side (using only the server host name from a backup url given after registration on the server) so relying that every client has its own system user on the server side. That doesn't work with this new backup functionality, where there is only one system user on the server side, and authorisation happens at the SSH level (using the {{Code|command}} option in {{Code|~/.ssh/authorized_keys}} file).
=== activation ===
=== activation ===
This service is intended to process anti-thief requests XO laptops send to the server during the boot process. It is looking for precreated leases using {{Code|<root-option>/share/leases/<SN's-last-two-chars>/<SN>}} paths. If there is no existing leases and {{Code|delegation}} option is {{Code|True}}, it will ask the [[#keyring|keyring]] service to generate new one using delegated leases.
This service is intended to process anti-thief requests that XO laptops send to the server during the boot process. It is looking for pre-created leases using {{Code|<root-option>/share/leases/<SN's-last-two-chars>/<SN>}} paths. If there are no existing leases and the {{Code|delegation}} option is {{Code|True}}, it will ask the [[#keyring|keyring]] service to generate a new one using delegated leases.
Interface:
Interface:
Requirements:
Requirements:
* Current XO's bootstrap code uses TCP interface with having the following numbers hard coded:
* Current XO's bootstrap code uses TCP interface, having the following numbers hard coded:
** {{Code|host}} needs to be {{Code|172.18.0.1}},
** {{Code|host}} needs to be {{Code|172.18.0.1}},
** {{Code|activation-port}} needs to be {{Code|191}},
** {{Code|activation-port}} needs to be {{Code|191}},
** XOs use {{Code|172.18.96.1}} as a gateway while connecting to {{Code|172.18.0.1}}.
** XOs use {{Code|172.18.96.1}} as a gateway while connecting to {{Code|172.18.0.1}}.
Backwards compatibility:
Service is also listening {{Code|--activation-port}} port on the {{Code|--host}} host to process TCP requests used by XO's bootstrapping code. If sent data starts from serial number, the service will reply with:
Service is also listening to {{Code|--activation-port}} port on the {{Code|--host}} host to process TCP requests used by the XO's bootstrapping code. If sent data starts with a serial number, the service will reply with:
* {{Code|STOLEN}} text if serial number is stated as stolen;
* {{Code|STOLEN}} text, if serial number is stated as stolen;
* lease content found for serial number;
* lease content found for serial number;
* {{Code|UNKNOWN}} for errors.
* {{Code|UNKNOWN}} for errors.
=== keyring ===
=== keyring ===
Keyring service is needed to work with activation one. It signs delegated leases for activation requests if pre-existed leases weren't found.
Keyring service is needed to work with the activation one. It signs delegated leases for activation requests if pre-existing leases weren't found.
Interface:
Interface:
There is no public interface, the service is being used internally by sugar-server.
There is no public interface, the service is used internally by sugar-server.
== User identity models ==
== User identity models ==
How sugar-server will identify users while registration.
How sugar-server will identify users upon registration.
=== Hardware based model ===
=== Hardware based model ===
The usecase assumes:
The use case assumes:
* the hardware is intended to run only Sugar,
* the hardware is intended to run only Sugar,
* it serves only one user,
* it serves only one user,
* there is existing practice within XO deployments with workflows that need to be preserved.
* there is an existing practice within XO deployments with workflows that need to be preserved.
To process registration, users need to provide:
To process registration, users need to provide:
* valid SSH public key,
* valid SSH public key,
* valid machine serial number, i.e., serial number that school server is aware about, e.g., there is an activation lease.
* valid machine serial number, i.e., a serial number that the school server is aware of, e.g., there is an activation lease.
After re-flashing a XO (with loosing private key), it is possible to re-register user with uploading new public key. See [[#Vulnerabilities|below]] for related vulnerability issues.
After re-flashing an XO (with loosing private key), it is possible to re-register the user by uploading a new public key. See [[#Vulnerabilities|below]] for related vulnerability issues.
The following TODO needs to be implemented:
The following TODO needs to be implemented:
* Properly handle backups after hardware switching for the particular user.
* Properly handle backups after hardware switching for the particular user.
* More reliable identity scheme that will let to avoid [[#Vulnerabilities|compromising users]].
* More reliable identity scheme that will avoid [[#Vulnerabilities|compromising users]].
=== SSH key based model ===
=== SSH key based model ===
This is a low level model, since the major purpose is uploading SSH public key to the server. This model might be useful in cases like:
This is a low level model, since the major feature is uploading an SSH public key to the server. This model might be useful in cases like:
* the hardware is intended to run not only Sugar (thus, might be not affected by "re-flashing" issue),
* the hardware is intended to run not only Sugar (thus, might not be affected by "re-flashing" issue),
* it might serve multiple users.
* it might serve multiple users.
To process registration, users need to provide:
To process registration, users need to provide a
* valid SSH public key.
* valid SSH public key.
To have all-time access to already uploaded to the server data, people need to take care about keeping SSH key. This key can be found in {{Code|~/.sugar/''<profile>''/owner.key}} file.
To always have access to already-uploaded-to-the-server data, people need to take care about securing their SSH key. This key can be found in the {{Code|~/.sugar/''<profile>''/owner.key}} file.
=== Vulnerabilities ===
=== Vulnerabilities ===
'''Compromised users'''
'''Compromised users'''
Current implementation of [[#Hardware based model|hardware based]] identity model has a security issue that might be described with the following usecase:
Current implementation of [[#Hardware based model|hardware based]] identity model has a security issue that might be described with the following use case:
* a XO registered on a school server;
* an XO registered on a school server;
* processed several Journal backups there;
* processed several Journal backups there;
* got re-flashed with not keeping client side identities, like Sugar profile private key;
* got re-flashed and failed in keeping client side identities, like the Sugar profile private key;
* the XO wants to re-register to restore Journal content from previous backup. But from school server point of view, this request is a regular registration request from new XO (that provides the same serial number that existing registration uses).
* the XO wants to re-register to restore Journal content from a previous backup. But from the school server point of view, this request is a regular registration request from a new XO (which provides the same serial number that the existing registration uses).
Sugar-server will process these registrations assuming that the request was sent from a XO that has exactly the same serial number that was provided with the request.
Sugar-server will process these registrations assuming that the request was sent from an XO that has exactly the same serial number that was provided with the request.
'''Compromised servers'''
'''Compromised servers'''
Both identity models might process registration on fake servers. The only thing clients need to start a registration, is properly resolved {{Code|schoolserver}} host name.
Both identity models might process registration on fake servers. The only thing clients need to start a registration, is a properly resolved {{Code|schoolserver}} host name.
Possible solutions:
Possible solutions:
== Configuration ==
== Configuration ==
By default, configuration occurs based on several sources (sorted by applied order):
By default, configuration occurs based on several sources (sorted by order of application):
* {{Code|/etc/sugar-server.conf}} system-wide configuration file,
* {{Code|/etc/sugar-server.conf}} system-wide configuration file,