21.3. Sicherheitsüberprüfung
Sobald das Hauptpasswort eingegeben wird, ist die API offen für Authentifizierung configs die auf die Authentifizierungs-Datenbank zuzugreifen, so ähnlich wie funktioniert Firefox. Doch in der ersten Implementierung gibt es keinen Schutz gegen PyQGIS Zugang. Dies kann zu Problemen führen, wenn ein Benutzer ein böswilliges PyQGIS Plugin oder eine Standalone-Anwendung installiert, die den Zugriff auf die Anmeldeinformationen zur Authentifizierung erhält.
Die schnelle Lösung für die anfängliche Freisetzung von Funktion ist nicht nur die meisten PyQGIS Bindungen für das Authentifizierungssystem zu umfassen.
Eine weitere einfache, wenn auch nicht robuste Lösung ist eine Kombobox hinzuzufügen in (Vorgabe ist „niemals“):
"Allow Python access to authentication system"
Choices: [ confirm once per session | always confirm | always allow | never]
Eine solche Einstellung der Optionen müsste an einem Ort nicht gespeichert werden, der für Python nicht zugänglich Python ist, z. B. die Authentifizierungsdatenbank und verschlüsselt mit dem Master-Passwort.
Eine weitere Option kann es sein zu verflogen, welche Plugins der Benutzer speziell hat
erlaubt auf Authentifizierungssystem zuzugreifen, obwohl es schwierig sein kann, abzuleiten welches Plugin tatsächlich abruft.
Sandboxing Plugins, möglich in ihrer eigenen virtuellen Umgebung, würde „Cross-Plugin‘ Hacking von Authentifizierung configs von einem anderen Plugin reduzieren, das autorisiert ist. Dies könnte beudeuten, die Cross-Plugin Kommunikation ist gut, aber vielleicht nur zwischen Plugins von Drittanbietern.
Eine weitere gute Lösung ist, Code-Signing-Zertifikate zu prüfen. Denn dann kann das Zertifikat des Plugins beim Laden validieren. Bei Bedarf kann der Nutzer auch nicht vertrauenswürdige Politiken für Zertifikate einstellen, mit dem Plugin im Zusammenhang mit bestehenden Zertifikatsverwaltungen.
Alternativ, Zugriff auf sensible Authentifizierungssystem Daten von Python
konnte nie erlaubt werden und nur QGIS Kern-Widgets nutzen oder Authentifizierungs-System-Integrationen kopieren, würde es dem Plugin ermöglichen, mit Ressourcen zu arbeiten, die eine Authentifizierungskonfiguration haben, während Hauptpasswort und Authentifizierungs Config im Bereich der wichtigen Bereiche der Hauptapp laden.
Die gleichen Sicherheitsbedenken gelten für C ++ Plugins, obwohl es schwieriger sein wird, den Zugang zu beschränken, da es keine verbindliche Funktion gibt, einfach wie mit Python zu entfernen.
21.3.1. Einschränkungen
Die verwirrende Lizenzierung und Exportierung Probleme sind mit OpenSSL assoziiert. Um mit Qt mit SSL-Zertifikaten zu arbeiten, muss es Zugang zu den OpenSSL-Bibliotheken geben. Je nachdem, wie Qt kompiliert wurde, ist die Standard-dynamische Laufzeit auf OpenSSL-Libs verbunden (Exportbeschränkungen vermeiden).
QCA folgt einer ähnlichen Taktik, wobei durch die Verknüpfung zu QCA keine Einschränkungen entstehen, weil das QCA-ossl (OpenSSL) Plugin zur Laufzeit geladen wird. Das QCA-ossl Plugin ist mit den OpenSSL-Libs direkt verknüpft. Packagers wäre die benötige OpenSSL-Linking Einschränkung, um sicherzustellen, dass erfüllt sind, wenn sie das Plugin versenden. Könnte sein. Ich weiß es nicht wirklich. Ich bin kein Anwalt.
Das Authentifizierungssystem deaktiviert sicher selbst, wenn qca-ossl zur Laufzeit nicht gefunden wird.