sharpetronics/QGIS
1
0
Fork 0
mirror of https://github.com/qgis/QGIS.git synced 2025-10-04 00:04:03 -04:00
Code Issues Packages Projects Releases Wiki Activity

Transfer security matters of the authentication system

Browse Source 
from the user manual (refs https://github.com/qgis/QGIS-Documentation/pull/8985#issuecomment-2017822488)
This commit is contained in:
Harrissou Sant-anna 2024-03-25 15:09:16 +01:00 committed by Nyall Dawson
parent 94bef546b2
commit b5cbcbd9d4
1 changed files with 62 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
src/auth/README.md Normal file
View File

@ -0,0 +1,62 @@
_Originally available in the [user manual](https://docs.qgis.org/3.28/en/docs/user_manual/auth_system/auth_considerations.html)_
# Security Considerations
Once the master password is entered, the API is open to access authentication
configs in the authentication database, similar to how Firefox works.
However, in the initial implementation, no wall against PyQGIS access has been defined.
This may lead to issues where a user downloads/installs a malicious PyQGIS plugin
or standalone app that gains access to authentication credentials.
The quick solution for initial release of feature is to just not include most
PyQGIS bindings for the authentication system.
Another simple, though not robust, fix is to add a combobox
in Settings --> Options --> Authentication (defaults to "never"):
```
"Allow Python access to authentication system"
Choices: [ confirm once per session | always confirm | always allow | never]
```
Such an option's setting would need to be saved in a location non-accessible to Python,
e.g. the authentication database, and encrypted with the master password.
* Another option may be to track which plugins the user has specifically
allowed to access the authentication system, though it may be tricky to deduce
which plugin is actually making the call.
* Sandboxing plugins, possibly in their own virtual environments,
would reduce 'cross-plugin' hacking of authentication configs from another plugin
that is authorized.
This might mean limiting cross-plugin communication as well,
but maybe only between third-party plugins.
* Another good solution is to issue code-signing certificates to vetted plugin authors.
Then validate the plugin's certificate upon loading.
If need be the user can also directly set an untrusted policy for the certificate associated
with the plugin using existing certificate management dialogs.
* Alternatively, access to sensitive authentication system data from Python could never be allowed,
and only the use of QGIS core widgets, or duplicating authentication system integrations,
would allow the plugin to work with resources that have an authentication configuration,
while keeping master password and authentication config loading in the realm of the main app.
The same security concerns apply to C++ plugins, though it will be harder to restrict access,
since there is no function binding to simply be removed as with Python.
## Restrictions
The confusing [licensing and exporting](https://www.openssl.org/docs/faq.html)
issues associated with OpenSSL apply.
In order for Qt to work with SSL certificates, it needs access to the OpenSSL libraries.
Depending upon how Qt was compiled, the default is to dynamically link
to the OpenSSL libs at run-time (to avoid the export limitations).
QCA follows a similar tactic, whereby linking to QCA incurs no restrictions,
because the qca-ossl (OpenSSL) plugin is loaded at run-time.
The qca-ossl plugin is directly linked to the OpenSSL libs. Packagers would be the ones
needing to ensure any OpenSSL-linking restrictions are met, if they ship the plugin.
Maybe. I don't really know. I'm not a lawyer.
The authentication system safely disables itself when ``qca-ossl`` is not found at run-time.