Completion Report - Map of the Taught Student's Labs

Final report for the #405 Map of the Taught Student's Labs computing project.

This project was to review and further develop, improve and integrate a desktop availability map already developed by students (https://mapp.tardis.ed.ac.uk, demo: https://mapp.tardis.ed.ac.uk/demo , about: https://mapp.tardis.ed.ac.uk/about). This was currently running on the Flask dev server so crashes fairly often and would require: some form of callback on login for DICE, with opt-in to name visibility to friends on the map; either integration with Informatics' LDAP or change to Cosign authentication; code review to make sure the existing code is sufficiently secure (it was built quickly over a weekend at a hackathon); moving off Tardis' servers onto an Informatics machine. The existing map service had two parts, the UI and webserver was written in Python, with a Redis backend. The crawler (not currently running) was also written in Python, and was an SSH bot runnable from DICE or within the Inf network that accesses all the machines it knows about and checks for a physical user, exporting a hashed string if someone is there; this is the component that would be replaced with the callback on login, as the SSH bot makes DICE pretty upset, and causes unnecessary amounts of traffic. Students continue to express interest in the map, but the students that built it don't have the time to maintain it. No concerns over privacy nor security have been raised though asking a wider population of students would be sensible.

After review it was determined:

  • to replace the crawler with a simple (Python) daemon that would run on every lab desktop reporting back console status, but not the console user unless they had explicitly opted in to allow this
  • to replace the existing UI/Redis backend with a Theon micro-managed service which provides sufficient database, access control, systems integration and API functionality without further work
  • to provide an Android application to interface to the API for general student usage
  • to allow the collected desktop usage to be accessible as aggregated statistics on overall lab usage
  • to provide a simple friends finding feature to the same kind of functionality as in the original service but with an opt-in approach

An initial design was produced with an emphasis on simplicity and so that ALL functionality including authorisation control could be implemented entirely within the PostgreSQL back end itself, making it easier to check and maintain security.

The project was completed with 154hrs effort (about four and a half weeks).

The project was structurally complete quite quickly, but the Android application took a bit more effort than expected (maybe half of the total), specifically in the areas of interfacing with the Cosign service to obtain credentials and in handling SSL certificates. Effort was also spent learning from scratch AndroidStudio, the app development environment/structure (use of layouts and resources for example) and Java.

Unfortunately we have no access to the data on when labs have been booked out for tutorial sessions and other group meetings, hence the application can show desktops available when they are not available as the room they are in is occupied. This would be a nice feature enhancement and would be trivial to add to the back end if we could actually get hold of the relevant data feed.

The API provides a call that lists all the desktops that have not responded made a status report within the last twenty four hours or more. There are some discrepancies compared to the equivalent report from the Inventory (Tartarus) which is primarily due to location handling (machines that have been relocated but not turned on again in the new location). However this provides some additional data for front line support in tracking down desktops that are not working correctly.

The API provides calls to return statistics on lab usage but we don't do anything with this yet. The data available is maximum and average percentage usage per-lab, per-floor, per-building within every 5 minute period (rolls over after twenty four hours), 30 minute period (rolls over after 7 days), sixty minute period (rolls over after one month) and daily period (rolls over after one year). The statistics are also currently uncategorised (type of user) which is a requested feature addition.

Security Review

A security review of the service was carried out by Graham Dutton. His report is included in full below, with comments in italics where appropriate.

  • Server: standard DICE; locked down as expected. Not reviewing this as it will get regular review.
  • Service: authenticated HTTP API and unauthenticated website.
    • Requires DICE credentials OR token.
    • Credential acquisition usual DICE / Kerberos setup, not reviewing further.
    • Token handling seems sound, simple input to validate.
    • Misuse of the service within the range of permitted API use is unlikely to permit significant leaks as there are very few inputs, all of which receive some sort of validation. It might be worth highlighting that the use of friend API data could permit one user to construct a mechanism of login/out notification which furthermore could send data outwith locally-connected users/devices, which is not obvious from the more passive nature of the app. From a computing point of view this activity would be clear from logs if it were to take place, though it would not necessarily be prohibited.
      • TC: Yes, an interesting analysis which I hadn't considered. Certainly it is the case although of limited practical use - the API does not reveal which friends are in which labs just that one or more of your friends are in a lab so, unless you had only one friend association, it could only be used to broadcast the login pattern of a group of users not actual individuals. Might be worth explicitly identifying this on the documentation page as a risk of opting in to tracking and to remind users they can opt out at any point (should friends turn against one another, which I guess is the main risk case here)?
    • In a worst case scenario, if some exploit is found which reveals the entire database, a malicious users will be able to see live (non-historical) data on specific usernames who have opted-in to tracking, and slightly more fine-grained, totally anonymous data on lab usage. Note also that a logged-in user doesn't imply physical presence at that time.
  • App review:
    • Code heavily relies on standard, supported Android APIs so I'm not reviewing these further.
    • Service handles all authorization so app review from hereon in is largely about authentication and access to private data.
    • Handles DICE credentials, which is as safe as any other route, but unorthodox - suggest future work for a user-elected option to generate token via Weblogin-authenticated page, meaning we're never asking for credentials outwith the unavoidable entry points of desktop greeter / SSH / kerberos / web.
      • TC: Yes, this would be preferable - at the time I couldn't see a clean/nice way for the user/system to do this (i.e. passing the token retrieved via separate weblogin auth page to the app) - more research might well throw up an approach that works however.
      • GD: The only thing I'd imagined for the manual token passing was pretty rough and ready - along the lines of a Kerberized / Cosigned page which simply hands out / renews tokens to copy & paste into the app manually.
    • Token acquisition seems sound though I'm not sure I'm qualified to determine this at a glance!
    • App doesn't store DICE credentials at any point, which is good; however auth token is stored as a preference in 'Shared storage', the standard option for Android preferences which in theory (and practice) allows this value to be read by other apps. This isn't necessarily a problem, but users might need to be made aware that any other application on their phone might have access to privileged (albeit strictly limited) information about their friends' location. Future API targets will permit automatically-encrypted preference values which should eliminate this risk entirely.
    • All other data is kept securely within the confines of the app or transmitted securely (HTTPS to DICE-managed Let's Encrypt-certified service). Tokens nor responses are unlikely to reveal anything overly sensitive thanks to encryption. Friend list is not stored locally in any permanent capacity that I know of.
    • For enhanced paranoia it might be worth investigating newer APIs for password-specific variable handling routines in the login dialog; the layout already determines that the password field is not a normal text field, so this should provide adequate protection from e.g. third-party keyboard apps. After that, normal Android security and memory randomisation should ensure the password is reasonably hard to retrieve, but there might be more we can do (e.g. on a rooted phone). I've not investigated this further as the risk seems exceptionally low.
    • Not a security issue, but source probably shouldn't contain student UUNs even in comments.
      • TC: Erm, ooopsy daisy. I have removed from the source and committed. It will still be in the Git history of course - could even remove that but thats somewhat more painful to do.

-- TimColles - 31 Jan 2019

Topic revision: r3 - 06 Jan 2020 - 13:33:03 - TimColles
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies