File System Permissions

[KesterTan]

Description

This PR outlines a security model for the filesystem. The exact details of the permission model can be taken from docs/security-model.md. The setup can be viewed from docs/permission-model.md.

• Course and assessments should be owned by a unix group of the course. Instructors are now automatically added to or removed from the Unix group when their course role changes, both on creation, update, and deletion of course user data.
• Instructors are able to SSH into the system by providing their SSH keys and only view/edit their courses and data for their courses.
• Separate daemon running with root privileges is also created. This allows us to delegate certain actions of controllers to the daemon process now that rails process does not own the whole filesystem.

Tests

This has been tested by:

• testing that all basic Autolab features work
• checking that an instructor can upload ssh key, and only see courses that he/she is an instructor for. Note that it is a known issue that you have to re-ssh into the system to see the effects of new, updated and deleted courses.
• checking the permissions of files and that they are owned by the right user

[anthony-yip]

Do you want to change this to false? I'm thinking of the unlikely case where the UNIX_OPS_SHARED_SECRET is forgotten to be set/gets cleared and the unixops ports gets published to the host by mistake, then an outsider can perform filesystem operations. If you mandate the secret then it can only be from inside of the same host.

[KesterTan]

ok changed

[anthony-yip]

Is there a link to the Dockerfile for unixops and the corresponding change to docker-compose.yml?

[anthony-yip]

I think the unix ops daemon filesystem operations is very permissive (the path in the payload is not validated to reference a course's file path, could point anywhere basically)

[KesterTan]

The dockerfile change is in a branch called permission-unixops on the docker repository: link

[KesterTan]

I think it has to be designed in that way because there are other functions/file paths not in a course directory that would potentially need to be edited by the daemon. But agreed that it is super permissive and the only layer of security we have now is the function checks on rails and a shared secret in the env