Sicherheit

Add-ins laufen im selben Prozess wie der Host. Das bedeutet: Ein Add-in hat technisch Zugriff auf alles, was der Host-Prozess kann — Dateisystem, Netzwerk, Zwischenablage. Eine echte Sandbox mit Prozess-Isolation ist bei nativen In-Process-Add-ins nicht möglich, und WBASH behauptet das auch nicht.

Stattdessen setzt WBASH auf drei Säulen: Signatur, deklarative Berechtigungen und Fehlerisolierung. Diese Kombination ersetzt keine Sandbox, bietet aber einen pragmatischen Schutz, der für ein Full-Trust-Add-in-Modell mit signierten Drittanbieter-Erweiterungen angemessen ist.

Zurück zur Übersicht.

Jedes Add-in-Paket (.wvdsx) kann eine Prüfsumme der Haupt-DLL im Manifest enthalten:

{
  "dllChecksum": "sha256:a1b2c3d4e5f6..."
}

Der Host verifiziert diese Prüfsumme vor dem Laden der DLL. Wenn die DLL nach dem Paketieren verändert wurde — sei es durch einen Angreifer, einen fehlerhaften Download oder eine unbewusste Manipulation — stimmt der Hash nicht überein, und der Host verweigert das Laden.

Die Prüfsumme ist ein SHA256-Hash im Format sha256:hexwert. Sie wird beim Erstellen des Pakets berechnet und im Manifest abgelegt. Der Build-Prozess sollte diesen Schritt automatisieren.

Diese Prüfung stellt die Integrität sicher: Die DLL im installierten Add-in ist identisch mit der DLL, die der Herausgeber paketiert hat. Sie stellt noch keine Authentizität sicher — dafür wäre eine kryptografische Signatur mit einem Zertifikat nötig, die in einer zukünftigen Version ergänzt werden kann.

Das Berechtigungsmodell basiert auf expliziten Capabilities. Ein Add-in deklariert im Manifest, welche Rechte es benötigt:

{
  "permissions": ["fs.read", "fs.write", "net.http"]
}

Beim ersten Start eines Add-ins zeigt der Host dem Benutzer einen Dialog mit den angeforderten Berechtigungen. Der Benutzer kann einzeln zustimmen oder ablehnen. Die Entscheidung wird persistiert — bei späteren Starts wird nicht erneut gefragt.

Die Capabilities sind bewusst abgestuft. fs.read erlaubt nur den Zugriff auf das eigene Storage-Verzeichnis des Add-ins (GlobalStoragePath und WorkspaceStoragePath). Für Zugriff auf beliebige Dateien ist fs.readExternal nötig — eine deutlich weitreichendere Berechtigung, die dem Benutzer klar kommuniziert wird.

Ebenso unterscheidet das System zwischen net.http (typisch für API-Aufrufe) und net.socket (typisch für Protokolle auf niedriger Ebene). Ein Add-in, das nur REST-APIs aufruft, braucht kein net.socket.

Service-Implementierungen prüfen die Capabilities, bevor sie privilegierte Operationen ausführen:

// Im Add-in: Berechtigung prüfen
if FHost.Permissions.HasCapability('fs.readExternal') then
  Content := FHost.Storage.ReadFile('/pfad/zur/datei')
else
  FHost.Notifications.ShowWarning('Keine Berechtigung für Dateizugriff');
 
// Oder: Berechtigung anfordern (zeigt Dialog)
if FHost.Permissions.RequestCapability('net.http') then
  DoHttpRequest;

HasCapability prüft still, ohne den Benutzer zu stören. RequestCapability zeigt einen Dialog und gibt True zurück, wenn der Benutzer zustimmt. Die zweite Variante eignet sich für Situationen, in denen das Add-in eine Berechtigung erst zur Laufzeit braucht und sie nicht im Manifest deklariert hat.

Jeder Aufruf von Add-in-Code ist in eine Schutzschicht eingebettet. Wenn ein Add-in eine unbehandelte Exception wirft, passiert Folgendes:

1. Der Host fängt die Exception ab.
2. Die Fehlermeldung wird protokolliert (über ILogService).
3. Der Fehlerzähler des Add-ins wird inkrementiert.
4. Der Host fährt mit den übrigen Add-ins fort. Die Anwendung bleibt stabil.

Nach drei aufeinanderfolgenden Fehlern (MAX_ERRORS = 3) deaktiviert der Host das Add-in automatisch:

1. Der Zustand wechselt zu psError.
2. Alle Registrierungen des Add-ins werden aufgeräumt (Commands, Menüs, Toolbar-Buttons, Sidebar-Panels).
3. Der Benutzer erhält eine Benachrichtigung: „Das Add-in 'Name' wurde wegen wiederholter Fehler deaktiviert.“
4. Die DLL bleibt geladen (Entladen wäre unsicher wegen möglicher Interface-Referenzen), aber kein Code wird mehr aufgerufen.

Dieses Verhalten ist bewusst konservativ. Ein einzelner Fehler kann ein Glitch sein — vielleicht ein Netzwerk-Timeout oder eine vorübergehend fehlende Datei. Drei aufeinanderfolgende Fehler deuten auf ein systematisches Problem hin. Die automatische Deaktivierung verhindert, dass ein defektes Add-in die Anwendung dauerhaft belastet.

Es ist wichtig zu verstehen, was dieses Sicherheitsmodell nicht kann:

• Keine Prozess-Isolation — Das Add-in läuft im selben Prozess und kann im Prinzip beliebigen Code ausführen. Die Capability-Prüfung ist kooperativ, nicht erzwungen. Ein bösartiges Add-in könnte die Prüfung umgehen.
• Keine Speicher-Isolation — Ein Add-in kann auf den Speicher des Host-Prozesses zugreifen. Es gibt keinen Schutz gegen Memory-Corruption oder absichtliches Auslesen fremder Daten.
• Kein sicheres Hot-Unload — Ein deaktiviertes Add-in bleibt im Speicher, weil noch Interface-Referenzen existieren können. Erst beim nächsten Start der Anwendung ist das Add-in vollständig entfernt.

Diese Einschränkungen sind bei nativen In-Process-Erweiterungen unvermeidlich. WBASH kompensiert sie, indem es nur offiziell signierte Add-ins zulässt und dem Benutzer die Kontrolle über die Berechtigungen gibt. Das ist ein Full-Trust-Modell mit Transparenz — kein Sandbox-Modell mit Garantien.

• Berechtigungen minimal halten. Nur die Capabilities anfordern, die tatsächlich gebraucht werden. Je weniger Berechtigungen, desto eher wird der Benutzer dem Add-in vertrauen.
• dllChecksum immer setzen. Die Prüfsumme kostet nichts und schützt vor unbeabsichtigter Manipulation.
• Exceptions im eigenen Code fangen, soweit möglich. Die Fehlerisolierung des Hosts ist ein Sicherheitsnetz, kein regulärer Fehlerbehandlungsmechanismus. Drei unbehandelte Exceptions und das Add-in wird deaktiviert.
• Sensible Daten (Tokens, Passwörter) über ISecretStorage speichern, nicht im Klartext auf der Festplatte. Der Host bietet plattformspezifische Implementierungen (Windows Credential Manager, Linux Secret Service).

Weiter zur Lokalisierung oder zurück zur Übersicht.