Hi all,

I like the *idea* of sandboxing.

And we all know and agree it's a complex topic. Hard to impossible to
get right (let's admit also that security is always something gray and
not black and white - unless the network plug is removed and the room
isolated with tin foil). This on the other hand doesn't mean that there
are some approaches which are just wrong by design.

There is also the question about the level on which sandboxing should
happen. E.g. distributing the app with flatpak and relying on its portal
mechanism [1] might at one point in the future be a way to get sandboxing.

One can also run the app inside some other virtualized environment or
even separate physical machine already now for isolation.

Maybe Pypy is a way to get there as well from the python side. I don't
know. But Nathan is absolutely right that the API offered by Qt builds a
big attack surface for which someone has to first bring up a sensible
idea for how to lock attackers down without restricting possibilities
offered for plugins. Or how to safely decide if running code from
external shared libs like the processing lwgeom provider does [2] is
something safe to do or not.

If someone seriously wants to follow this route:

Be prepared to work with specialists in this area and do serious
research about possibilities and feasibility first.

Be prepared to maintain a separate distribution of QGIS with restricted
python access and reduced plugin functionality.

Be prepared to get a very big sponsor to back the effort.


[1] https://github.com/flatpak/flatpak/wiki/Portals
[2] https://plugins.qgis.org/plugins/processinglwgeomprovider/
Qgis-developer mailing list
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Reply via email to