====== 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 [[start|Übersicht]].

===== Signatur und Integritätsprüfung =====

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

<code javascript>
{
  "dllChecksum": "sha256:a1b2c3d4e5f6..."
}
</code>

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.

===== Berechtigungsmodell (Capabilities) =====

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

<code javascript>
{
  "permissions": ["fs.read", "fs.write", "net.http"]
}
</code>

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.

==== Verfügbare Capabilities ====

| **Capability** | **Beschreibung** |
| ''fs.read'' | Dateien im eigenen Storage-Verzeichnis lesen |
| ''fs.write'' | Dateien im eigenen Storage-Verzeichnis schreiben |
| ''fs.readExternal'' | Dateien außerhalb des eigenen Verzeichnisses lesen |
| ''fs.writeExternal'' | Dateien außerhalb des eigenen Verzeichnisses schreiben |
| ''net.http'' | HTTP/HTTPS-Anfragen stellen |
| ''net.socket'' | TCP/UDP-Verbindungen öffnen |
| ''process.spawn'' | Externe Prozesse starten |
| ''clipboard.read'' | Zwischenablage lesen |
| ''clipboard.write'' | In die Zwischenablage schreiben |
| ''env.read'' | Umgebungsvariablen lesen |
| ''shell.execute'' | Shell-Befehle ausführen |

==== Abstuftung der Rechte ====

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''.

==== Prüfung im Code ====

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

<code pascal>
// 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;
</code>

''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.

===== Fehlerisolierung =====

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

  - Der Host fängt die Exception ab.
  - Die Fehlermeldung wird protokolliert (über ''ILogService'').
  - Der Fehlerzähler des Add-ins wird inkrementiert.
  - 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:

  - Der Zustand wechselt zu ''psError''.
  - Alle Registrierungen des Add-ins werden aufgeräumt (Commands, Menüs, Toolbar-Buttons, Sidebar-Panels).
  - Der Benutzer erhält eine Benachrichtigung: "Das Add-in 'Name' wurde wegen wiederholter Fehler deaktiviert."
  - 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.

===== Was das Modell nicht leistet =====

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.

===== Empfehlungen für Add-in-Entwickler =====

  * 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|Lokalisierung]] oder zurück zur [[start|Übersicht]].