Tracking Issue idealized formal model for permissions, process tracking and IPC (signaling etc)

Gotta got formal to be eventually picked up by sel4 instead of not good (underspecified and insufficiently complete) POSIX model.

Why Posix/Linux too with complex API, unspecified and forces solving handle leak problem by user with high performance cost (mutex + 2 calls to set and unset CLEXEC on all intended to be seperataly inherited handlers xor not doing parallel process spawning at all).


existing process has ressources
  handle1(secret)
  handle2(non-secret)

      userspace          │    kernelspace    │   userspace
      ───────────────────┼───────────────────┼───────────────────── 
      thread1 calls fork │                   │   thread2 calls fork
      (or clone)                                 (or clone)
      spawned process 1◄────               ─────►spawned process 2
      high trust         |   does not ensure |   low trust
                         |   handles do not  |   (might not close secret handle1)
                         |   cross trust     |
      intend             |   boundaries      |   intend 
      gets only handle1  |=> no in-memory    |   gets only handle2
                         |   single process  |
                         |   trust storage   |
                         |   possible        |
                         |   (must use other |
                         |    process)       |

Solution uses similar semantics as Windows explicit list of inherited handles, although Windows ones are worse with file handles needing to stay opened or spawning fails. See https://github.com/mikdusan/child-process/issues/1 for the possible Posix fix.

Further, the Linux solution is complex, see http://catern.com/process.html and https://github.com/catern/supervise.

Windows has too comples API and requires even more meta objects with selecting multiple ways of doing the same, but slightly differently. System call filtering is only partially supported (kernel32 + ntdll API with ~400 calls still accessible) with kernel32 being "security by obscurity" as "kernel lib on top of kernel hidden from user". See https://github.com/matu3ba/win32k-mitigation/issues/3, for ntdll and kernel32 restriction https://github.com/matu3ba/win32k-mitigation/tree/master/test/standalone/child_process_ntdll_only, for explicit file handle inheritance (good thing, if there would not be 5 ways of doing it with multiple combinations and its behavior not specified https://github.com/matu3ba/win32k-mitigation/tree/master/test/standalone/child_process_explicit_handles).

Also, async with list would mandate solving the same problem.

Main semantic questions for static scheduling

minimal base system requirements
sel4 model
declarative Kernel API generation? versioning? querying?
performance, synchronization, memory footprint, meta-data extraction and reasoning
kernel as a lib like kernel32 solution with well-specified semantics?

Main semantic questions for dynamic prefdefined scheduling

unclear, probably the same as static + attaching solver?

Main semantic questions for dynamic prefdefined scheduling

unclear, probably the same as static + attaching solver + providing proof for OS selection?

Windows References https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createprocesswithtokenw https://stackoverflow.com/questions/5141997/is-there-a-way-to-set-a-token-for-another-process https://0x00-0x00.github.io/research/2018/10/17/Windows-API-and-Impersonation-Part1.html https://0x00-0x00.github.io/research/2018/10/21/Windows-API-And-Impersonation-Part-2.html https://stackoverflow.com/questions/1533017/dropping-privileges-in-c-on-windows https://raw.githubusercontent.com/fashionproof/EnableAllTokenPrivs/master/EnableAllTokenPrivs.ps1 https://learn.microsoft.com/en-us/windows/win32/secauthz/access-tokens https://learn.microsoft.com/en-us/windows/win32/secauthz/securable-objects

Linux References https://stackoverflow.com/questions/19048015/linux-c-programming-execute-as-user https://cboard.cprogramming.com/c-programming/176823-execute-program-another-user.html

CreateProcessWithTokenW

Creates a new process and its primary thread. The new process runs in the security context of the specified token. It can optionally load the user profile for the specified user.

The process that calls CreateProcessWithTokenW must have the 'SE_IMPERSONATE_NAME' privilege. If this function fails with 'ERROR_PRIVILEGE_NOT_HELD' (1314), use the CreateProcessAsUser or CreateProcessWithLogonW function instead. Typically, the process that calls CreateProcessAsUser must have the 'SE_INCREASE_QUOTA_NAME' privilege and may require the 'SE_ASSIGNPRIMARYTOKEN_NAME' privilege if the token is not assignable. CreateProcessWithLogonW requires no special privileges, but the specified user account must be allowed to log on interactively. Generally, it is best to use CreateProcessWithLogonW to create a process with alternate credentials.

CreateProcessWithLogonW

This function is similar to the CreateProcessAsUser and CreateProcessWithTokenW functions, except that the caller does not need to call the LogonUser function to authenticate the user and get a token.

Both require user account credentials in cleartext.

Linux

tldr; no dedicated API, just privileges to set it and execve.

Conclusions:

1. needless complexity in Windows security model
  - vulnerabilities
  - extreme verbose to write
  - hard to model or argue about correctness
1. fork (or clone) makes resource leak very easy or racy
  - performance limitation
  - limited scalability for parallel process spawn (ie for security)

Linux Problems

1. Leaking file descriptors during parallel process spawning

existing process has ressources handle1(secret) handle2(non-secret)

  userspace          │    kernelspace    │   userspace
  ───────────────────┼───────────────────┼───────────────────── 
  thread1 calls fork │                   │   thread2 calls fork
  (or clone)                                 (or clone)
  spawned process 1◄────               ─────►spawned process 2
  high trust         |   does not ensure |   low trust
                     |   handles do not  |   (might not close secret handle1)
                     |   cross trust     |
  intend             |   boundaries      |   intend 
  gets only handle1  |=> no in-memory    |   gets only handle2
                     |   single process  |
                     |   trust storage   |
                     |   possible        |
                     |   (must use other |
                     |    process)       |

- 2. Process and Signal API has severe design shortcomings

TODO


Windows Problems

- 1.

* Assuming a process Pa with schedule A with deadline a and security level 2.
* Is affecting the scheduler a security problem, because security incidents must be
  processed imminently or with what deadlines?
* What happens, if two processes affect dynamically any security boundaries?
* Any form of async exceptions or signal handling (ie in Linux) kills hard deadlines.
* At least in sel4 all properties are static with statically predefined boundaries only allowed
  for scheduling and all bets are off for abstractions on hard deadline (from what the talks suggested).
* Indications:
  + security is a static system property
  + only allowed via delegating sufficient conditioned process groups/job unit
  + caller must handle (stacking) signals (if its not a simple mask) of
  child processes (or delegated higher security process), if it would be
  allowed at all up to runtime limit.

matu3ba / sandboxamples

Tracking Issue idealized formal model for permissions, process tracking and IPC (signaling etc) #7