5,705
edits
Changes
Jump to navigation
Jump to search
Line 18:
Line 18: − + − − === UUID per Sugar user === − − Sugar-server treats UUID values as unique identities of particular Sugar users, i.e., not unique identities of particular hardware that Sugar users run on (like OLPC XS does). UUID values are being calculated from users' pubkey, in the same way as JID values in Sugar Shell. If people need to keep access to their personal data, uploaded to the server, they need to keep private key, from {{Code|~/.sugar/default/owner.key}} file, e.g., while hardware migration or software reinstalling. Line 59:
Line 55: − + − * {{Code|uuid}} Line 140:
Line 135: − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + − + − The usecase:+ + + + + − + + + + + − Since this usecase is common for the current XO deployments, sugar-server will process a workaround with permitting such re-registration to let people do restore after re-flashing, even if private key is lost. This will happen only for XO laptops. For the rest of cases, workflow is [[#UUID_per_Sugar_user|regular]].+
Platform Team/Server Kit/sugar-server (view source)
Revision as of 19:20, 11 November 2011
, 19:20, 11 November 2011no edit summary
Registry items might contains following keys:
Registry items might contains following keys:
* {{Code|uuid}}, a hash value of the {{Code|pubkey}} treated as unique and short [[#UUID per Sugar user|user's identity]];
* {{Code|uuid}}, user's identity got after registration on a server;
* {{Code|serial}}, serial number of hardware Sugar user is running on, e.g., serial number of a XO laptop;
* {{Code|serial}}, serial number of hardware Sugar user is running on, e.g., serial number of a XO laptop;
* {{Code|pubkey}}, SSH public key, this is the exact line that needs to be placed as-is to {{Code|~/.ssh/authorized_keys}} file; note that OLPC XS operates with striped version of public keys.
* {{Code|pubkey}}, SSH public key, this is the exact line that needs to be placed as-is to {{Code|~/.ssh/authorized_keys}} file; note that OLPC XS operates with striped version of public keys.
== Services ==
== Services ==
Process registration on the server.
Process registration on the server.
The input dictionary, contains:
The input dictionary, contains (see [[#User_identity_models|identity models]] section for additional details):
* {{Code|nickname}}
* {{Code|nickname}}
* {{Code|serial}}
* {{Code|serial}}
There is no public interface, the service is being used internally by sugar-server.
There is no public interface, the service is being used internally by sugar-server.
== Caveats ==
== User identity models ==
How sugar-server will identify users while registration.
=== Hardware based model ===
The usecase assumes:
* the hardware is intended to run only Sugar,
* it serves only one user,
* there is existing practice within XO deployments with workflows that need to be preserved.
To process registration, users need to provide:
* valid SSH public key,
* valid serial number, i.e., serial number that school server is aware about, 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.
The following TODO needs to be implemented:
* Properly handle backups after switch hardware for particular user.
=== 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:
* the hardware is intended to run not only Sugar (thus, might be not affected by "re-flashing" issue),
* it might serves multiple users.
To process registration, users need to provide:
* valid SSH public key.
=== Restore backups after re-flashing XOs ===
=== Vulnerabilities ===
How current implementations are bad.
'''Compromised users'''
Current implementation of [[#Hardware based model|hardware based]] identity model has a security issue that might be described with the following usecase:
* a XO registered on a school server;
* a 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 with not keeping client side identities, like Sugar profile private key;
* the XO wants to restore Journal content from previous backups, but from school server point of view, it is regular registration request from new XO that provide the same serial number that existing registration uses.
* the XO wants to restore Journal content from previous backups, but from school server point of view, it is regular registration request from new XO that provides the same serial number that existing registration uses.
Sugar-server will process these registrations assuming that the request was sent from a XO that has exactly serial number exactly as the one provided with the request.
'''Compromised servers'''
Both identity models might process registration on fake servers. The only thing clients need to start registration, is properly resolved {{Code|schoolserver}} host name.
== Configuration ==
== Configuration ==