pyroniasys / libpyronia Goto Github PK

Need clear documentation on how to use the API:

• memdom allocation
• context switches
• memdom policy changes

Many applications and their dependencies spawn child processes for additional functionality. To provide seamless access control across such an execution boundary, the child procoesses should run inside a Pyronia sandbox. Two types of subprocesses are supported: Python and native executables.

API to implement:

• spawn_in_sandbox(library, command, is_python): Query the kernel for the permissions of the library, generate a sandbox policy with the library permissions and subprocess type from a policy template, load the policy into the kernel, and exec the command.

The stack tracer thread is a means to ensure that the interpreter does not lie about the call stack, but a malicious library could still tamper with the callstack before the SI thread collects the information to send back to the LSM.

Questions that need to be answered to solve this problem:

• Can we use type safety as our main protection method? Idea: prevent native code from getting pointers to stack frame objects
• Can we use memory protection domains to only allow the interpreter itself to modify the stack frame?

Corresponds to pyronia-lsm/#3

• Look at apparmor_parser code in apparmor userland API
• Translates the high-level Pyronia permissions (e.g. CAM_PERM currently defined in pyronia-lsm/lib_policy.h) into corresponding path and file access rules
• Sends the serialized lib policy to the kernel

To protect data flows within an application end-to-end (from source to sink), we need to create library function sandboxes for those functions that need to operate on sensitive in-memory data objects. To implement this feature, we leverage the existing memory domain mechanism to place sensitive data objects into memory domains. Then in the interpreter, whenever it's about to execute a sandboxed function, it adjusts the access privileges to the appropriate memory domains before entering the sandbox.

Per our design document, the Python interpreter will allocate any security critical state (internal interpreter state and stack frames) into a separate memory domain interpreter_dom, and revoke the main thread's access to interpreter_dom, unless the interpreter is allocating new stack frames or editing internal state.

API to implement:

• Setup for SMV usage and interpreter_dom
• Grant permissions to write to interpreter_dom: wrapper around memdom_priv_add() from libsmv
• Revoke permissions to write to interpreter_dom: wrapper around memdom_priv_del() from libsmv

Whenever an application spawns a child process, starts a new thread, or handles operations asynchronously, the function call context of the parent process is lost for system calls. Therefore, the language runtime must have a way of preserve the calling context of the parent by attaching the context to the child process, thread or asynchronous operation. This will then enable the kernel to make access control decisions with sufficient context.

API to implement:

• Register context with the kernel for child process
• Register context with the kernel for a subthread
• Register context with the kernel for an asynchronous operation

There are several execution scenarios in which the callstack context is lost due to "segmented" execution (subporocess exec, new thread, asynchronous function call). In these scenarios, the runtime saves the callstack proactively by sending it to the LSM so that the kernel may use the saved callstack as well as the newly collected callstack (if applicable) to make its access control decision.

Corresponds to pyronia-lsm/#4

• Stack inspection thread constructs the callgraph at runtime
• SI thread generates the callgraph upon request from the LSM (e.g. at the time of a file open); callgraph includes the called module and any data tags at each stack frame
• SI thread registers with LSM at startup and sends the collected callgraph via the LSM-communication channel

API to implement:

• Callstack data structure: module name, filename, parent frame, child frame
• Callstack serialization to send to kernel via netlink socket

The Pyronia kernel module communicates with userspace via a Netlink socket (see pyroniasys/pyronia-linux#8).

API to implement:

• runtime-to-kernel messages to send
• kernel-to-runtime messages to receive
• channel initialization
• listener
• message_send
• channel teardown
• callgraph serialization

Moved from pyronia-lsm/#7

Some language features are considered dangerous in the context of library-level MAC, and should no longer be supported by the language.

• Monkey-patching (dynamic function pointer reassignment) --> forbidden (check function pointer at compile time)
• Reflection library --> trigger security check
• Stack frame manipulation (via stack tracer) --> forbidden

Isolating each native extension into a separate memory domain protects its internal states against other potentially malicious native extensions running in the same address space.

To implement this, the language runtime must allocate each native extension into a separate domain at import time, and run native extension functions in separate SMVthreads. Since native extensions and their dependencies are most commonly dynamically loaded, the import system must instead create separate copies of each shared library and load them as part of an extensions memory domain, to guarantee full isolation of native extensions.

API to implement:

• Map of memory domains to native libraries
• Allocation of a native library and its dependencies into its own memory domain
• Run a native library function as a separate SMVthread