# Security

## Reporting

Since Gila is new and not used in any critical settings, vulnerabilities may
be filed as regular issues for the time being. Please ensure to specify that
the issue is a security issue when submitting.

## Foreward

Part of what inspires my design philosophy for Gila is the idea of creating a
new, fast, and safe kernel with security as a central focus.

Much of today's operating system security discourse comes down to "Sure, you
can harden this, this, and this. But *(insert OS)*'s security model is deeply
flawed." This isn't a dig at any one OS- it applies to all of them. Kernels
such as Linux, Mach, and NT were built long before today's most salient
concepts in computing security were established. Great work is being done on
improving what we already have, but it's counterintuitive to try to establish
a secure system on a flawed foundation.

Gila aims to start fresh, using modern theories and models, all in a memory
safe language that lends itself well to formal verification.

## Goals

- Distrustful by default
- Small, simple, and transparent
- Performant
- Capability based
- Highly isolated

## Gila's security model

### Microkernel architecture

Gila is a microkernel. Only the most important functionality runs at Ring 0
(Protected Mode) to reduce attack surface. This functionality includes:

- Modifying and reading kernel configurations
- Process creation and destruction
- Scheduling
- Memory allocation and management
- Inter-process communication
- Minimal IO drivers, only for debugging

Unprivileged user processes perform complex functionality by interacting with
similarly unprivileged server processes via inter-process communication.
Servers can perform many different tasks, such as:

- PCI(e)
- ACPI
- AHCI/SATA
- USB
- Ethernet
- TCP/IP
- Security policy
- Filesystems
- Logins
- Graphics
- Managing resources

Servers do one thing each, and one thing well. If a server needs to do a lot of
the same thing, it should fork into several processes, so inter-process
isolation can improve security. For example, if there are multiple of the same
device in the system, the driver server should fork for each instance. This
ensures that any one server can crash or be compromised without crashing or
compromising all the others.

Another scenario might involve running separate login server processes for
every single user on the system. Running all these servers in one process
introduces a serious security risk, as any compromise or failure of the login
server could result in security failures, resource exhaustion, denial of
service, or other undesirable events, affecting all other users on the system.

### Namespaces

Namespaces will be a critical part of how process isolation works. Details are
still TBD, but I want each process to start in its own empty namespace, unless
the parent process specifies that the child should share the parent's
namespace. As device drivers and protocol drivers are simply processes, and
subject to the same namespace rules as any other process, the kernel can
enforce access to any kind of function or resource for any process arbitrarily.
The same could eventually go for virtual machines.

Namespaces are a way by which the resources available to a process are isolated
and controlled. Mainly, this affects inter-process communication (IPC) as it's
the primary method processes will use to do useful things, but it will also
affect shared memory regions. A process cannot establish IPC unless it is part
of some namespace the target process is also part of.

Being part of a namespace entails holding a capability object referring to
that namespace, and that capability object will encode rights within that
namespace, such as IPC and shared memory.

### Capability based MAC

Namespaces will be enforced using capabilities, where a process holds a
capability object representing the namespace it is in, and the rights it has
within that namespace. By default, processes have no such capabilities, but
a parent process can choose to copy one of its own and delegate it to the
child process.

Details are still a work in progress.