Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Secure codejail code-exec #927

Open
2 of 8 tasks
timmc-edx opened this issue Feb 3, 2025 · 0 comments
Open
2 of 8 tasks

Secure codejail code-exec #927

timmc-edx opened this issue Feb 3, 2025 · 0 comments
Assignees
@timmc-edx

Comments

@timmc-edx
Copy link
Member

timmc-edx commented Feb 3, 2025 •
edited
Loading

The codejail-service IDA currently runs all code directly, without sandboxing.

Acceptance criteria

  • Testing procedure is complete: Create codejail functionality and security test script #896 (parallel work)
  • Devstack deployment runs code-exec securely (or, if manual steps are required, rejects code-exec until those steps are taken)
  • CODEJAIL_ENABLED is still disabled by default, and is not yet enabled in edge and prod
  • Stage deployment runs code-exec securely (and other environments, if set up)
    • Will require setting CODEJAIL_ENABLED to True temporarily for testing
    • Do not enable in stage until testing procedure is complete, passing in devstack, and ready to be tested in stage
  • If IDA is misconfigured, refuse to answer code-exec calls, and return a 500 on the healthcheck endpoint

Implementation
@timmc-edx timmc-edx converted this from a draft issue Feb 3, 2025
@timmc-edx timmc-edx removed the status in Arch-BOM Feb 3, 2025
@timmc-edx timmc-edx mentioned this issue Feb 3, 2025
Open
5 tasks
@timmc-edx timmc-edx moved this to In Progress in Arch-BOM Feb 3, 2025
timmc-edx added a commit to timmc-edx/codejail-service that referenced this issue Feb 6, 2025
@timmc-edx
feat: Configure codejail and run safety check at startup
42fe182 
- Initialize codejail at startup, if `CODE_JAIL` is set
- Run safety checks at startup, locking out the API if the checks fail

If codejail isn't properly configured, it defaults to running code
unsafely. To prevent this from affecting the service, we run a smoke test
at startup to check if there's anything just *drastically* wrong.

If this check does not pass, two things happen:

- The healthcheck endpoint will never return a 200 OK
- The code-exec endpoint will refuse with a 500 error

Supporting changes:

- Define an explicit AppConfig for the api subpackage so that we can hook
  into the `ready()` mechanism
- Wrap `safe_exec` to prevent codejail eagerly setting `UNSAFE=True`
  at module load time. (Not clear why this doesn't affect
  edx-platform; maybe something to do with app vs. middleware load
  order.) Filed openedx/codejail#225 for
  possibly fixing this.
- `safe_exec` wrapper also provides deepcopy to allow callers to
  reason about the globals dict more easily.

Other changes:

- Clean up healthcheck docstring (mostly just trim it down)
- Lint cleanup

Part of edx/edx-arch-experiments#927
timmc-edx added a commit to timmc-edx/codejail-service that referenced this issue Feb 6, 2025
@timmc-edx
feat: Configure codejail and run safety check at startup
eca968a 
- Initialize codejail at startup, if `CODE_JAIL` is set
- Run safety checks at startup, locking out the API if the checks fail

If codejail isn't properly configured, it defaults to running code
unsafely. To prevent this from affecting the service, we run a smoke test
at startup to check if there's anything just *drastically* wrong.

If this check does not pass, two things happen:

- The healthcheck endpoint will never return a 200 OK
- The code-exec endpoint will refuse with a 500 error

Supporting changes:

- Define an explicit AppConfig for the api subpackage so that we can hook
  into the `ready()` mechanism
- Wrap `safe_exec` to prevent codejail eagerly setting `UNSAFE=True`
  at module load time. (Not clear why this doesn't affect
  edx-platform; maybe something to do with app vs. middleware load
  order.) Filed openedx/codejail#225 for
  possibly fixing this.
- `safe_exec` wrapper also performs a deepcopy to allow callers to
  reason about the globals dict more easily.

Other changes:

- Clean up healthcheck docstring (mostly just trim it down)
- Lint cleanup

Part of edx/edx-arch-experiments#927
timmc-edx added a commit to timmc-edx/codejail-service that referenced this issue Feb 6, 2025
@timmc-edx
feat: Configure codejail and run safety check at startup
edd7062 
- Initialize codejail at startup, if `CODE_JAIL` is set
- Run safety checks at startup, locking out the API if the checks fail

If codejail isn't properly configured, it defaults to running code
unsafely. To prevent this from affecting the service, we run a smoke test
at startup to check if there's anything just *drastically* wrong.

If this check does not pass, two things happen:

- The healthcheck endpoint will never return a 200 OK
- The code-exec endpoint will refuse with a 500 error

Supporting changes:

- Define an explicit AppConfig for the api subpackage so that we can hook
  into the `ready()` mechanism
- Wrap `safe_exec` to prevent codejail eagerly setting `UNSAFE=True`
  at module load time. (Not clear why this doesn't affect
  edx-platform; maybe something to do with app vs. middleware load
  order.) Filed openedx/codejail#225 for
  possibly fixing this.
- `safe_exec` wrapper also performs a deepcopy to allow callers to
  reason about the globals dict more easily.

Other changes:

- Clean up healthcheck docstring (mostly just trim it down)
- Lint cleanup

Part of edx/edx-arch-experiments#927
@timmc-edx timmc-edx mentioned this issue Feb 6, 2025
Merged
6 tasks
timmc-edx added a commit to timmc-edx/codejail-service that referenced this issue Feb 6, 2025
@timmc-edx
feat: Configure codejail and run safety check at startup
6479eca 
- Initialize codejail at startup, if `CODE_JAIL` is set
- Run safety checks at startup, locking out the API if the checks fail

If codejail isn't properly configured, it defaults to running code
unsafely. To prevent this from affecting the service, we run a smoke test
at startup to check if there's anything just *drastically* wrong.

If this check does not pass, two things happen:

- The healthcheck endpoint will never return a 200 OK
- The code-exec endpoint will refuse with a 500 error

Supporting changes:

- Define an explicit AppConfig for the api subpackage so that we can hook
  into the `ready()` mechanism
- Wrap `safe_exec` to prevent codejail eagerly setting `UNSAFE=True`
  at module load time. (Not clear why this doesn't affect
  edx-platform; maybe something to do with app vs. middleware load
  order.) Filed openedx/codejail#225 for
  possibly fixing this.
- `safe_exec` wrapper also performs a deepcopy to allow callers to
  reason about the globals dict more easily.

Other changes:

- Clean up healthcheck docstring (mostly just trim it down)
- Lint cleanup

Part of edx/edx-arch-experiments#927
timmc-edx added a commit to timmc-edx/codejail-service that referenced this issue Feb 6, 2025
@timmc-edx
feat: Configure codejail and run safety check at startup
a0de742 
- Initialize codejail at startup, if `CODE_JAIL` is set
- Run safety checks at startup, locking out the API if the checks fail

If codejail isn't properly configured, it defaults to running code
unsafely. To prevent this from affecting the service, we run a smoke test
at startup to check if there's anything just *drastically* wrong.

If this check does not pass, two things happen:

- The healthcheck endpoint will never return a 200 OK
- The code-exec endpoint will refuse with a 500 error

Supporting changes:

- Define an explicit AppConfig for the api subpackage so that we can hook
  into the `ready()` mechanism
- Wrap `safe_exec` to prevent codejail eagerly setting `UNSAFE=True`
  at module load time. (Not clear why this doesn't affect
  edx-platform; maybe something to do with app vs. middleware load
  order.) Filed openedx/codejail#225 for
  possibly fixing this.
- `safe_exec` wrapper also performs a deepcopy to allow callers to
  reason about the globals dict more easily.

Other changes:

- Clean up healthcheck docstring (mostly just trim it down)
- Lint cleanup

Part of edx/edx-arch-experiments#927
timmc-edx added a commit to timmc-edx/codejail-service that referenced this issue Feb 6, 2025
@timmc-edx
feat: Configure codejail and run safety check at startup
e1ae885 
- Initialize codejail at startup, if `CODE_JAIL` is set
- Run safety checks at startup, locking out the API if the checks fail

If codejail isn't properly configured, it defaults to running code
unsafely. To prevent this from affecting the service, we run a smoke test
at startup to check if there's anything just *drastically* wrong.

If this check does not pass, two things happen:

- The healthcheck endpoint will never return a 200 OK
- The code-exec endpoint will refuse with a 500 error

Supporting changes:

- Define an explicit AppConfig for the api subpackage so that we can hook
  into the `ready()` mechanism
- Wrap `safe_exec` to prevent codejail eagerly setting `UNSAFE=True`
  at module load time. (Not clear why this doesn't affect
  edx-platform; maybe something to do with app vs. middleware load
  order.) Filed openedx/codejail#225 for
  possibly fixing this.
- `safe_exec` wrapper also performs a deepcopy to allow callers to
  reason about the globals dict more easily.

Other changes:

- Clean up healthcheck docstring (mostly just trim it down)
- Lint cleanup

Part of edx/edx-arch-experiments#927
timmc-edx added a commit to timmc-edx/codejail-service that referenced this issue Feb 11, 2025
@timmc-edx
feat: Configure codejail and run safety check at startup
d659920 
- Initialize codejail at startup
- Run safety checks at startup, locking out the API if the checks fail

If codejail isn't properly configured, it defaults to running code
unsafely. To prevent this from affecting the service, we run a smoke test
at startup to check if there's anything just *drastically* wrong.

If this check does not pass, two things happen:

- The healthcheck endpoint will never return a 200 OK
- The code-exec endpoint will refuse with a 500 error

Supporting changes:

- Define an explicit AppConfig for the api subpackage so that we can hook
  into the `ready()` mechanism
- Wrap `safe_exec` to prevent codejail eagerly setting `UNSAFE=True`
  at module load time. (Not clear why this doesn't affect
  edx-platform; maybe something to do with app vs. middleware load
  order.) Filed openedx/codejail#225 for
  possibly fixing this.
- `safe_exec` wrapper also performs a deepcopy to allow callers to
  reason about the globals dict more easily.

Other changes:

- Clean up healthcheck docstring (mostly just trim it down)
- Lint cleanup

Part of edx/edx-arch-experiments#927
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@timmc-edx timmc-edx

Labels
None yet
Projects
Arch-BOM
Status: In Progress
Milestone
No milestone
Development

No branches or pull requests
1 participant
@timmc-edx