[QGIS-Developer] Enhancing QGIS Development and Security Features Proposition

Fri Nov 3 16:21:02 PDT 2023

Hi Rhea,
Adding some points to the very good answers above.

QGIS is already deployed in very security sensitive organizations and has
been assessed against vulnerabilities. I obviously can't list them publicly
here. Some are public, like the NSA, that even publishes some plugins, but
also funded some parts of the authentication system.

Its desktop component stays however a generic desktop tool, and as such
will be able to interact with the OS it is installed on. Just like blender
or FME or Arcxx that also have python scripting.
I have seen deployment in sanboxes through virtualization tools that can
help too. Like QGIS served through web streaming or as a remote app (
VMware stuff or vnc or similar stuff)

There are several ways of addressing your concerns in QGIS itself.  Most
will rely on creating a specific configuration for your organisation. You
will be able to deploy a preconfigured QGIS that can almost handle all this

 A few examples

- configure QGIS with a dedicated user agent name and have the IT team
filter the trafic they allow using their firewall
- audit the plugins you will use and ship them with your install packages,
or deploy an internal repository
- use the awesome "constrained settings" script funded by a french ministry
to prevent users from drifting away from this configuration
- you can customize the UI so that average user just can't launch the
python console. Any advanced user will be able to circumvent this, but it's
a good start.
-if you are really into security, don't focus on your customer's fears, but
on the real criticity of a GIS infrastructure.  Securing the data source
connections, configuring mandatory encrypted keyrings is often the weakest
part. Python scripting capabilities us present in most software.and must be
secured by the OS and the IT. You can secure QGIS and have user send QGIS
projects by mail with plain text credentials if you don't handle this. This
should fear your customer more than potential python scripts.

Another point. I have seen over constrained QGIS based deployments for
"security reasons" .  They showed  up some side effects:
- user were too constrained, when GIS work supposes to be able to handle
quite complex tools (SQL queries, cli tools, heavy geospatial computing).
They were so locked that they ended up in really trying shadow IT
solutions.
- the configuration work was too heavy and done as a one time project.  the
IT department could not follow the security updates of QGIS and it's
dependencies , leading to severely outdated software in production.
Security is also a matter of being able to update frequently to fix
vulnerabilities, which we offer in every monthly release.

I've conducted a few of such enterprise wide deployment and I confirm you
that you can find professional support in the commercial companies that
provides such services. You can find them listed on our website.
(Disclaimer, I have no direct interest here and speak as a steering
committee member)

Best regards , and let us know how it goes

Régis

Le ven. 3 nov. 2023, 10:11, B. De Mezzo via QGIS-Developer <
qgis-developer at lists.osgeo.org> a écrit :

> Hi Rhea,
>
> same as Johannes "I am in no way able to officially answer but maybe I
> can give some thoughts and rhetoric questions":
>
> * QGIS is not designed to handle such security restrictions, it is not
> its purpose
>
> * the best way, IMHO, is to limit its network accesses by using
> dedicated security software as selinux for linux or advanced firewall
> configuration for windows
>
> * the best to discuss these features is "to create QGIS Enhancement
> Proposals at https://github.com/qgis/QGIS-Enhancement-Proposals/issues."
>
> Regards.
>
> Le 03/11/2023 à 09:35, Johannes Kröger (WhereGroup) via QGIS-Developer a
> écrit :
> > Hi Rhea,
> >
> > I am in no way able to officially answer but maybe I can give some
> > thoughts and rhetoric questions:
> >
> > To me those improvements sound like good ideas. I am not sure how far
> > you could lock down Python extensibility considering the existing API.
> > And I am not sure if you are aware of the many ways that a QGIS
> > environment might use network calls, e.g. a tool like Proj might
> > download grids from the internet in some cases, GDAL might try to
> > fetch schemas specified in local files, etc. Sandboxing the system
> > from the outside is probably much easier and secure.
> >
> > Are those 40 extensions existing extensions? Are you aware that you
> > can strip out the official repository and use your own instead?
> >
> > It would probably be best to create QGIS Enhancement Proposals at
> > https://github.com/qgis/QGIS-Enhancement-Proposals/issues.
> >
> > And it would be good to proof commitment to maintaining the new
> > features in some way or enter the sustaining membership program with
> > significant, recurring contributions so that other developers paid by
> > the QGIS project can maintain them.
> >
> > Cheers, Hannes
> > _______________________________________________
> > QGIS-Developer mailing list
> > QGIS-Developer at lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20231104/c3638e79/attachment.htm>