feat: AppArmor confinement for codejail-service #109

timmc-edx · 2025-02-13T00:24:37Z

Allow codejail-service to actually run code (and run it securely) by giving it the needed confinement. Previously it would run but refuse to execute code since it would detect the insecure environment; now, the startup safety checks pass and the code-exec endpoint works as expected.

Add an AppArmor profile with fairly strict rules. It needs to be thoroughly vetted and to have exceptions added before it can be used in production, but it's be fine for devstack. Some parts are based on the existing edxapp apparmor config without careful review.
Apply the profile to the codejail service in docker-compose.
Add Django configs for codejail service.
Add documentation for installing the profile so that it is available for use on the dev's machine.

Also:

Add configuration and documentation for edxapp to actually call the codejail service, disabled by default. (Will later want to make this default to true, once the service is working properly.)
Update image name in docker-compose to follow rename in Several codejail-service cleanups public-dockerfiles#102

Currently edxapp gets an error back from codejail-service, and then isn't able to read that error; separate work in the app repo will be needed to fix those. (The first issue relates to python_path, and the other to not returning globals_dict when there's an emsg.) But the integration is working otherwise.

I've completed each of the following or determined they are not applicable:

Made a plan to communicate any major developer interface changes (or N/A)

Allow codejail-service to actually run code (and run it securely) by giving it the needed confinement. Previously it would run but refuse to execute code since it would detect the insecure environment; now, the startup safety checks pass and the code-exec endpoint works as expected. - Add an AppArmor profile with fairly strict rules. It needs to be thoroughly vetted and to have exceptions added before it can be used in production, but it's be fine for devstack. Some parts are based on the existing edxapp apparmor config without careful review. - Apply the profile to the codejail service in docker-compose. - Add Django configs for codejail service. - Add documentation for installing the profile so that it is available for use on the dev's machine. Also: - Add configuration and documentation for edxapp to actually call the codejail service, disabled by default. (Will later want to make this default to true, once the service is working properly.) - Update image name in docker-compose to follow rename in edx/public-dockerfiles#102 Currently edxapp gets an error back from codejail-service, and then isn't able to read that error; separate work in the app repo will be needed to fix those. (The first issue relates to python_path, and the other to not returning globals_dict when there's an emsg.) But the integration is working otherwise.

py_configuration_files/lms.py

codejail.profile

py_configuration_files/cms.py

We can use either `#include` or `include` and it might be less confusing to use the one that doesn't look like a comment. I've added comments to some directives that I now understand better.

Just about every sample policy on the web includes attach_disconnected but the manpage describes it as a debugging tool that is not safe for general use.

docs/codejail.rst

codejail.profile

py_configuration_files/codejail.py

py_configuration_files/lms.py

- Document what netlink is and why it's needed - Allow TCP connections, but not establishing outbound ones - Split apart capability lines into two blocks for easier commenting

- `--add` vs `--replace` and when to use them - TODO around Mac - Hints that codejail.profile is a file provided in the repo

codejail.profile

docs/codejail.rst

py_configuration_files/lms.py

codejail.profile

Co-authored-by: Robert Raposa <rraposa@edx.org>

Just a better (more descriptive) name, and has parallels to codejail_service profile name.