Process Security Descriptors

Every process carries a security descriptor that controls who can perform operations on it. This replaces Linux's UID-based process access control (which is a patchwork of UID comparisons and capabilities) with unified SD evaluation.

§5.3.1 Process access rights #

§5.3.2 Signal classification #

Each Linux signal maps to a process access right based on its default action:

§5.3.2.1 PROCESS_TERMINATE — default action: terminate (or terminate + core) #

§5.3.2.2 PROCESS_SUSPEND_RESUME — default action: stop or continue #

§5.3.2.3 PROCESS_SIGNAL — default action: ignore #

§5.3.3 Generic mapping #

§5.3.4 Default process SD #

Processes MUST receive a default SD at creation time:

Owner: <creator's primary token user SID>
Group: <creator's primary token primary group SID>
DACL:
  ALLOW  <process's own user SID>        GENERIC_ALL
  ALLOW  BUILTIN\Administrators           GENERIC_ALL
  ALLOW  SYSTEM                            GENERIC_ALL
  ALLOW  Everyone                          PROCESS_QUERY_LIMITED
SACL:
  SYSTEM_MANDATORY_LABEL  <process's token integrity level>  NO_WRITE_UP

This means:

• The process can do anything to itself.
• Administrators and SYSTEM have full control over all processes.
• Everyone can see basic process info (PID, name, status) -- this is what makes ps and top work for all users.
• Detailed inspection (token, memory, environment) is restricted to self, administrators, and SYSTEM.
• A lower-integrity process running as the same user is blocked from write-category operations (signals, memory write, token replacement) by MIC. This is the foundation of elevation isolation — an unelevated Medium-integrity process cannot tamper with an elevated High-integrity process even when both run under the same user SID.

Services MAY request a custom SD at launch (via the service definition), or modify their own SD at runtime (via kacs_set_sd on their own process, which requires WRITE_DAC -- granted by the default SD to the process itself).

§5.3.5 PIP interaction #

PIP and the process SD are complementary. The process SD controls who can perform operations on the process. PIP controls which trust level is required for invasive access to protected processes. Both checks MUST pass:

1. AccessCheck evaluates the caller's token against the target process's SD for the requested right.
2. PIP evaluates the caller's trust level against the target's pip_type and pip_trust (for operations that cross the process boundary).

A process MAY have a permissive SD (Administrators: GENERIC_ALL) but be PIP-protected -- administrators pass the SD check, but only if their PIP trust level is sufficient. Conversely, a non-PIP process MAY have a restrictive SD that denies even administrators specific operations.

§5.3.6 Thread security model #

KACS does not define per-thread security descriptors or thread-specific access rights. All thread operations are gated by the process SD.

This is an intentional architectural decision. Linux threads share the process address space (mm_struct), so per-thread isolation has limited security value — a thread that can write the shared address space can compromise any other thread in the same process. Per-thread SDs would add complexity without meaningful isolation.

Consequence: kacs_open_thread_token gates access using the process SD (PROCESS_QUERY_INFORMATION). A caller who passes the process SD check can open any thread's impersonation token within that process. If finer-grained token isolation is required, the service should use separate processes rather than separate threads.