Generate a full-protection security policy automatically upon exercise creation

[SedaOran]

Feature Proposal

Spec Version 0.0.2
Objective 1 of 3 (thesis: Improving the User Interface of LMS Security Tools for Programming Exercises) Automatic Ares2 Security Policy Generation

Context

Problem

Today, before Ares2 can protect a programming exercise in an LMS, the instructor must manually create and maintain the Ares2 security policy configuration: writing policy files by hand, configuring build-system settings, aligning them with the exercise's test repository, and repeating this for each new exercise. Nothing in the exercise creation/editing UI workflow reflects that this manual work exists or needs to happen; it currently lives entirely outside Artemis, in a disconnected manner. This is the "configuration complexity" problem: securing an exercise correctly requires coordinating policy files, build configuration, repository structure, and test annotations across several disconnected tools, and any mistake in that coordination propagates silently into test failures or security gaps that are hard to trace back to their cause.

Motivation

Instructors, the primary affected role, are subject-matter experts in their course content, not sandboxing specialists. Requiring them to hand-author security policy files creates a real barrier to adopting Ares2 at all: exercises either ship unprotected, or an instructor spends disproportionate time on infrastructure rather than pedagogy. Teaching assistants who help set up exercises inherit the same manual burden without necessarily knowing why the policy looks the way it does. Removing manual policy authoring is Objective 1 of the underlying thesis. When an instructor activates Ares2 for an exercise, a full-protection security policy should be generated automatically, with no manual policy file authoring required.

Requirements Engineering

Existing (Problematic) Solution / System

At present, there is no separate section for Ares2 within the Create/Edit exercise workflow on Artemis. An instructor who wants security sandboxing for an exercise does so by manually placing security policy files in the exercise-tests repository and keeping them in sync with the repository structure defined elsewhere in the exercise (the Language step: test repository URI, build configuration). Ares2 does not read from or write to the template or solution repositories; only the exercise-tests repository is in scope. There is no activation control, no generated default, and no confirmation that the policy actually matches the exercise's current structure. This is entirely undiscoverable to an instructor working only inside Artemis.

Proposed System

I added a single "Activate Ares2" toggle to the Create/Edit exercise wizard, as a Security step positioned between the existing Language step and the Problem step (i.e., after the repository/build structure is known but before the problem statement and tasks are authored). The toggle represents one unambiguous state: on, meaning Ares2 is activated, and off, meaning it is not, with no intermediate or differently worded state anywhere it appears. Turning it on automatically generates a baseline, full-protection Ares2 security policy derived from the exercise's already configured test repository and programming language, with no manual file editing. The instructor sees, in real time, whether the Ares2 framework version is available/compatible, and whether the generated security policy has been committed and synced to the exercise-tests repository. Turning it off cleanly removes sandbox enforcement, with an explicit warning since it is itself a repository-changing action.

Requirements

Each requirement below is scoped to be independent of the others, deliverable and demonstrable on its own, and testable against a concrete pass/fail condition, per the INVEST mnemonic (Wikipedia: INVEST (mnemonic)).

Requirements
FR: Unambiguous Activation State: As an instructor, I can turn Ares2 on or off for a programming exercise from a single "Activate Ares2" toggle in the exercise wizard, where on and off mean exactly "activated" and "not activated" and nothing else, so that I do not need to touch any policy file directly.
FR: Automatic Security Policy Generation: As an instructor, when I turn the toggle on, the system generates a default full-protection security policy (deny-by-default for the file system, network, command execution, and threading) scoped to the exercise's existing test repository, without requiring any further input from me.
FR: Framework Version Surface: As an instructor, I can see which Ares2 framework version will be used and whether it is compatible with the exercise's build tool, via a status indicator next to the "Activate Ares2" toggle, so I can catch incompatibility before relying on the sandbox.
FR: Repository Sync Feedback: As an instructor, I can see whether the generated security policy has been committed to the exercise-tests repository and how recently, so I can trust that the toggle actually took effect.
FR: Safe Deactivation: As an instructor, when I turn the toggle off after turning it on, I am warned that this creates a new commit that removes sandbox enforcement from the exercise-tests repository, so I do not do this by accident.
FR: Consistent Status Language: As an instructor, the same activation state (Ready, Needs Setup, Not Active) is shown identically, same colour, same wording, everywhere this control appears (Create/Edit, Simple/Advanced mode), so I do not have to relearn the meaning per screen.
NFR: Performance: The system must complete security policy generation and commit, or clearly report "in progress," within a UI-acceptable time (target: under 5s for the synchronous part); anything longer must surface as a "Needs Setup" state rather than a blocked UI.
NFR: Usability: The system must make the "Activate Ares2" toggle usable without documentation: state, meaning, and the next action must be inferable from the toggle, badge colour, and one line of helper text alone.
NFR: Reliability: If security policy generation or the repository commit fails, the system must not silently show the exercise as "Active"; it must surface an explicit error/needs-setup state instead, never a false positive.
NFR: Supportability: The system must make every generated security policy commit traceable to the activation action that caused it (commit hash shown in the UI, actor and timestamp recoverable server-side).

Analysis

Analysis Object Model

Dynamic Behaviour

System Architecture

Subsystem Decomposition

• Client (Angular): ProgrammingExerciseSecurityStepComponent hosts the Ares2ActivationCardComponent ("Activate Ares2" toggle + shared ares2-status-badge + framework version/tooltip + sync info). Talks to a new Ares2Service (activate(), deactivate(), getStatus()).
• Server (Spring): New Ares2Resource REST controller exposing:
  • POST /api/programming-exercises/{exerciseId}/ares2/activate
  • POST /api/programming-exercises/{exerciseId}/ares2/deactivate
  • GET /api/programming-exercises/{exerciseId}/ares2/status -> Ares2StatusDTO { status, frameworkVersion, lastCommitHash, lastSyncedAt }
• Ares2SecurityPolicyGenerationService: derives a default security policy from the exercise's ProgrammingLanguage and test-repository structure; delegates the actual commit to Artemis's existing repository/VCS service layer rather than introducing a new Git integration.
• Ares2FrameworkCompatibilityService: checks, on demand, whether the configured Ares2 version resolves for the exercise's build tool (Maven/Gradle) by resolving the dependency; this replaces a stored frameworkCompatible flag, since compatibility is derived from whether frameworkVersion is populated and resolvable rather than cached as a separate boolean.
• Clone/import path: when a new exercise is generated, or an existing one is cloned/imported with Ares2 selected, the security policy is injected as part of that clone step ("clone with Ares2"), reusing the same generation logic as manual activation rather than a separate code path.
• DTOs: Ares2StatusDTO (read), Ares2ActivateResponseDTO (returned after activation, includes the new commit hash).

Persistent Data Management

• No new database table. Ares2 activation state is derived by reading the exercise-tests repository directly (whether .ares2/policy.yml and the enforcement hooks are present and committed), rather than being stored in a separate schema; the repository is the source of truth for a policy's existence and content.
• On Create, activation state is held client-side until Generate, then written by the clone/injection step described above.
• On Edit, the status endpoint reads the current state from the exercise's already-checked-out repository copy; the UI shows a loading state while this read is in progress, since it depends on repository access rather than a local database row.
• New configuration option (server-side, environment/property): default/pinned Ares2 framework version, overridable per deployment.

Access Control / Security Aspects

• Activation/deactivation is restricted to users with edit rights on the exercise, the same authorization check already used for exercise editing; no new role is introduced.
• The generated security policy is itself the security boundary for student-submitted code. Hence, a bug in the generator that produces an overly permissive default is a security issue, not just a UX bug. The default must be deny-by-default and covered by dedicated server-side tests.
• Repository commits made by security policy generation must be attributable (service-account or instructor identity, consistent with Artemis's existing commit-attribution conventions), so a policy change is always traceable.

Other Design Decisions

• Security policy generation is synchronous from the user's perspective but designed so that a slow Git operation degrades to a visible "Needs Setup"/retry state rather than a blocked UI thread. Polling GET status after activation is sufficient for this scope; no WebSocket is needed for v1.
• Testing strategy: unit tests for Ares2SecurityPolicyGenerationService (given repository/language input, correct deny-by-default policy output), an integration test for the activate/deactivate REST flow, and a Cypress test for the activation-control -> badge state transition.

UI/UX Design

Screenshots of the final UI mockups (mandatory): Please include screenshots to provide a clear, persistent visual reference for the design.

Link to the design mockup (optional): Additionally, you may include a link to the live design mockup (e.g., Figma, Sketch) for a more interactive view. Note that this link is supplementary and should not replace the required screenshots.