shibedrill/gila
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
main
gila/SECURITY.md
shibedrill 2eccf91884
Licensing and docs
2025-03-29 00:44:54 -04:00

2.1 KiB
Raw Permalink Blame History

Security

Part of the design philosophy that drives my inspiration for Gila is the idea of creating a new, fast, and safe kernel with security as a central focus. Kernels such as Linux, Mach, and NT have been around for too long to work perfectly with today's system security model. Gila is brand-new, and built almost exclusively in Rust for the utmost memory safety.

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
  • Hardware communication interfaces

User processes perform complex functionality by interacting with server processes. Servers perform many different things:

  • PCI(e)
  • USB
  • Security policy
  • Filesystems
  • Logins

A user process can be registered as a server by any process with the ServerRegister capability. The kernel takes the process's ID and a functionality type as arguments to the registration function. Registering is important, because it allows processes to discover the PIDs of server processes for IPC.

Capabilities

Every process in Gila has a set of capabilities. These capabilities define the ways it may interact with the kernel's limited functions, and do not govern what it can do with any other userspace process.

Access control

Access control will be accomplished by means of a "policy server" process, which is registered as a system server by the init process, and is given the authority (by means of its registration with the kernel being readable) to allow or deny specific resource accesses. The relevant server will submit the PID of the requesting process & the resource it desires to the security server, which will check the request against the process's rights, and return a verdict to the issuing server.