Capabilities (LCBS)

Lyx bindet jedes Programm an ein Capability-Modell: Der Compiler erzeugt aus den deklarierten Berechtigungen einen seccomp-Filter, der zur Laufzeit jeden nicht angeforderten Systemaufruf hart abbricht. Das Modell ist Zero-Privilege mit Default-Deny — was nicht ausdrücklich gewährt wurde, ist verboten.

Ohne Deklaration läuft ein Programm ungehärtet: der Compiler meldet Capability-Modell: NONE und erzeugt keinen seccomp-Filter.

→ Module und Importe · FFI · DO-178C

@capabilities steht vor allen anderen Deklarationen der Datei:

@capabilities([system.exit, system.memory.heap])
import std.io;

fn main(): int64 {
    PrintLn("Hallo");
    return 0;
}

Mehrere Berechtigungen werden mit Komma getrennt. Alternativ erlaubt @capabilities(dynamic) die Auflösung zur Laufzeit.

Ein unbekannter Name ist ein Compile-Fehler:

@capabilities([zzz.erfunden])
→ sema error: unbekannte Capability

Das sind alle 25 gültigen Namen. Jeder andere wird mit unbekannte Capability abgewiesen.

Drei Capabilities sind implizit gesetzt, weil ohne sie kein Programm startet:

Jeder import kann angeben, welche Berechtigungen die eingebundene Unit erhalten soll. grant zählt auf, was weitergegeben wird, restrict nimmt zurück:

@capabilities([system.exit, system.memory.heap, fs.read])
import std.io grant [system.exit];
import std.fs grant [fs.read];

Beides lässt sich am selben Import kombinieren, und mehrere Imports stehen wahlweise in einer Deklaration:

import std.io grant [system.exit], std.string grant [system.exit];

Eine Unit kann nur bekommen, was das aufrufende Modul selbst besitzt. Diese Prüfung greift zur Übersetzungszeit:

sema error: grant enthält Capability die nicht in Parent-Capabilities ist

Eine Funktion, die eine Berechtigung des Aufrufers benötigt, deklariert das ausdrücklich. Geprüft wird gegen die aufrufende Funktion — diese muss die Berechtigung selbst per @capabilities tragen. Die Angabe am Dateikopf genügt dafür nicht:

@capabilities([system.exit, system.memory.heap, fs.read])
import std.io;

@uses_caller_cap([fs.read])
fn LiesKonfiguration(): int64 {
    return 0;
}

@capabilities([fs.read])
fn main(): int64 {
    PrintLn(IntToStr(LiesKonfiguration()));
    return 0;
}

Fehlt das @capabilities an main, wird der Aufruf abgelehnt:

sema error: Caller hat nicht: fs.read (benötigt von @uses_caller_cap)

Das gilt auch für implizite Capabilities: @uses_caller_cap([system.exit]) verlangt ebenfalls ein ausdrückliches @capabilities([system.exit]) an der aufrufenden Funktion.

extern fn ohne passende Capability wird abgewiesen — nicht gewarnt, sondern abgelehnt:

sema error: extern fn: unbekanntes FFI-Symbol erfordert @capabilities([...])
            (FFI-Sandbox Fail-Closed)

Ein FFI-Aufruf ist damit immer eine bewusste, sichtbare Entscheidung.

Jeder Build gibt eine Bewertung aus. Sie zeigt unmittelbar, was die Deklaration bewirkt:

# ohne @capabilities
Capability-Modell: NONE (kein @capabilities -- keine LCBS-Haertung)
Sicherheits-Score: 33/45
  + 0: seccomp fehlt
  +8: Grant-Modell -- 1 Import(e) ohne grant (-2 pro fehlendem grant)

# mit @capabilities und vollständigen grants
+ seccomp (SECCOMP_RET_KILL_PROCESS, 53 Regeln)
Sicherheits-Score: 45/45
  +10: Grant-Modell -- alle Imports haben explizites grant
  + 5: seccomp aktiv

Weitere Posten: W^X (getrennte PT_LOAD-Segmente), RELRO, und der Nachweis, dass keine Klasse-3-Extern-Funktion ohne system.unsafe.format_string verwendet wird. PIE ist derzeit nicht implementiert (+0).

Der erzeugte seccomp-Filter arbeitet mit SECCOMP_RET_KILL_PROCESS. Ein nicht gewährter Systemaufruf beendet den Prozess sofort:

@capabilities([system.exit, system.memory.heap])
import std.fs;

fn main(): int64 {
    if (FileExists("/etc/hostname"c)) { return 1; }
    return 0;
}

$ ./programm
Ungültiger Betriebssystemaufruf (Speicherabzug geschrieben)
$ echo $?
159

Mit fs.read in der Liste läuft dasselbe Programm durch.

Eine Capability kann Argumente tragen, die ihren Geltungsbereich einschränken:

@capabilities([system.exit, system.memory.heap, fs.read(path: "/tmp")])

Der Argumentname wird geprüft — ein Tippfehler wie pfad: wird mit unbekanntes Capability-Argument abgewiesen.

path: an einer fs-Capability wird seit lyxc 1.0.15E durchgesetzt. Der Compiler legt je genanntem Pfad eine eigene Landlock-Regel an, mit genau den Zugriffsarten der Capability, zu der das Argument gehört. Ein Lesen außerhalb schlägt zur Laufzeit fehl:

@capabilities([system.exit, system.memory.heap, fs.read(path: "/tmp")])
// ReadFile("/etc/hostname"c, …) -> -1;  mit fs.read(path: "/etc") -> gelesene Bytes

Zwei Regeln dazu:

• Die pauschale “/„-Regel entfällt genau dann, wenn alle fs-Capabilities einen Pfad tragen. Trägt auch nur eine keinen, bleibt sie stehen — ein einzelnes fs.write ohne path: hebt die Beschränkung der übrigen also faktisch auf.
• Existiert ein genannter Pfad nicht, wird keine Regel angelegt und der Zugriff bleibt verboten (fail-closed).

Weiterführende Seiten:

• Module und Importe — grant/restrict im Kontext
• FFI — externe Funktionen einbinden
• Attribute und Pragmas