Why Horus exists

Nothing is allowed because of who it claims to be.

A conventional kernel keeps a large body of policy in the privileged half, and then special-cases an administrator who may ignore it. Horus takes the other cut. The kernel's job is address spaces, tasks, capabilities, IPC, and an encrypted block store whose keys it does not hand out. Filenames, the session policy and the terminal live in ring-3 servers.

Some of that policy is still in ring 0. The on-disk filesystem, accounts and program loading have not moved yet. That is gap G-14 in the architecture document, and it is open. A defect there is a defect in the kernel.

Identity is not authority. uid 0 does not open a kernel object. SYS_SUDO was withdrawn: it answers SYS_ERR_NOSYS. The user id the kernel will report, when a server asks, is the one on the capability the caller presented, not a field the caller filled in.

A capability can be passed on. It cannot grow.

A capability names one object and a set of rights. Handing it to another task installs a new capability derived from it. The child has a subset of the rights, or the same rights, and never a right the parent lacked. Revoking the parent reaches the derivation tree under it.

There is no ambient file path. A session reaches the filesystem through a capability init minted for that login. Below the session root the kernel bounds only the union of the session's grants. The finer policy is enforced by fs_server, which is in the trusted computing base for that reason. That split is an open limitation, not a finished design.

Each task has a cspace of 256 slots, of which 128 may be occupied.

CNODE_SIZE is 256. MAX_CAPS_PER_TASK is 128. Userspace sees a slot number. It does not see the object pointer. Slot 3 is a decoy, not a grant. Forging a capability word does not install it: the kernel looks the slot up itself.