Overwegingen voor beveiliging¶
Als het hoofdwachtwoord eenmaal is ingevoerd, is de API geopend om toegang te verkrijgen voor de configuraties voor authenticatie in de database voor authenticatie, soort gelijk aan de manier waarop Firefox werkt. Echter, in de initiële implementatie, is geen muur tegen toegang door PyQGIS gedefinieerd. Dit kan leiden tot problemen als een gebruiker een schadelijke plug-in of zelfstandige toepassing voor PyQGIS downloadt/installeert, die toegang verkrijgt tot gegevens voor authenticatie.
De snelle oplossing voor de initiële uitgave van deze mogelijkheid is om gewoonweg niet de meeste bindingen voor PyQGIS voor het systeem van authenticatie op te nemen.
Een andere eenvoudige, maar niet robuuste, reparatie is om een combinatievak toe te voegen in (standaard “nooit”):
"Allow Python access to authentication system"
Choices: [ confirm once per session | always confirm | always allow | never]
Een dergelijke instelling voor een optie zou moeten worden opgeslagen op een locatie die niet toegankelijk is voor Python, bijv. de database voor authenticatie, en moeten zijn versleuteld met het hoofdwachtwoord.
Een andere optie zou kunnen zijn na te gaan welke plug-ins de gebruikers specifiek heeft
toegestaan om toegang te verkrijgen tot het systeem voor authenticatie, hoewel het gevaarlijk kan zijn om te bepalen welke plug-in in feite de aanroep doet.
Testen van plug-ins in een zandbak, mogelijkerwijze in hun eigen virtuele omgevingen, zou hacken via ‘cross-plugin’ van configuraties voor authenticatie vanuit een andere plug-in die wel is geautoriseerd kunnen reduceren. Dit zou zou ook de communicatie tussen plug-ins kunnen beperken, maar misschien alleen tussen plug-ins van derde partijen.
Een andere goede oplossing is om gecodeerde certificaten uit te geven aan betrouwbare auteurs van plug-ins. Daarna het certificaat te valideren bij het laden van de plug-in. Indien nodig zou de gebruiker ook direct een beleid voor niet vertrouwd kunnen instellen voor het certificaat dat is geassocieerd met de plug-in met behulp van bestaande dialoogvensters voor het beheren van certificaten.
Als alternatief, toegang tot gevoelige gegevens in het systeem voor authenticatie vanuit Python
kan nooit worden toegestaan, en alleen het gebruiken van bronwidgets van QGIS, of het dupliceren van integraties voor het systeem van authenticatie, zou de plug-in toestaan om te werken met bronnen die een configuratie voor authenticatie hebben, terwijl het hoofdwachtwoord en de configuratie voor authenticatie worden geladen in het gebied van de hoofdtoepassing.
Dezelfde beveiligingsoverwegingen bestaan voor plug-ins van C++, hoewel het moeilijker zal zijn om toegang te beperken, omdat er geen binding voor functies is die eenvoudigweg kan worden verwijderd, zoals met Python.
Beperkingen¶
De verwarrende problemen voor licensering en exporteren die zijn geassocieerd met OpenSSL zijn van toepassing. Om Qt te kunnen laten werken met certificaten van SSL, heeft het toegang nodig tot de bibliotheken van OpenSSL. Afhankelijk van hoe Qt werd gecompileerd, is de standaard om dynamisch te koppelen naar de bibliotheken van OpenSSL tijdens run-time (om beperkingen voor exporteren te vermijden).
QCA volgt een soortgelijke tactiek, waarbij koppelen naar QCA geen beperkingen ophaalt, omdat de plug-in qca-ossl (OpenSSL) gedurende run-time wordt geladen. De plug-in qca-ossl is direct gekoppeld aan de bibliotheken van OpenSSL. Verpakkers zouden degenen moeten zijn die er voor zorgen dat aan de beperkingen voor koppelen naar OpenSSL wordt voldaan, als zij de plug-in distribueren. Misschien. Ik weet het echt niet. Ik ben geen jurist.
Het systeem voor authenticatie schakelt zichzelf veiligheidshalve uit indien qca-ossl niet wordt gevonden gedurende run-time.