Trusted Projects and Folders

[m-kuhn]

QGIS Enhancement Proposal: Trusted Projects and Folders

Date

2024/03/23

Author

Matthias Kuhn

Contact

matthias@opengis.ch

Version

To be determined

Introduction

When opening a QGIS project containing Python or other executable code (such as macros, feature actions , or expression functions), the user is currently prompted with a security warning. The options available are to "allow once," "always allow" (which generates a warning as it means completely disable protection for the current profile), "deny once," or "deny always." These options, while providing basic security measures, lack flexibility and sophistication in managing trusted environments, especially in enterprise settings.

Proposal

This QEP proposes the introduction of "Trusted Project" and "Trusted Folder" options to enhance security measures and user convenience in QGIS. This system would allow users to designate specific projects or entire folders as trusted, significantly reducing the frequency of security prompts for known safe content and streamlining workflow efficiency.

Features and Benefits

• Trusted Projects and Folders: Users can mark individual projects or entire directories as trusted, which suppresses security warnings for Python code execution within those contexts.

• Visual Studio Code-like Warning System: A warning system, akin to that used by Visual Studio Code, will be implemented. This will inform users of the potential risks involved in executing Python code from untrusted sources, enhancing awareness and control over security settings.

• INI File Configuration for Enterprises: For enterprise environments, it will be possible to pre-configure trusted paths through a global INI file. This feature will allow system administrators to set up a secure, controlled environment by specifying trusted projects and folders, thereby simplifying configuration for end-users.

• Improved Usability and Security: By providing clearer options for managing trusted content, this proposal aims to improve the overall user experience. Users will have greater control over their security settings, allowing for a more organized and controlled access to projects containing executable code.

Implementation Considerations

• User Interface: The implementation will include UI enhancements to manage trusted projects and folders easily. This could involve a new section in the QGIS settings and project properties dialogues.

• Backward Compatibility: The introduction of this feature will be designed to be backward compatible, ensuring that existing projects and security settings are not adversely affected.

Conclusion

The introduction of Trusted Projects and Folders in QGIS represents a significant step forward in enhancing the security and usability of the software. By allowing users and administrators to designate trusted environments, this feature will streamline workflows and provide a more intuitive and controlled approach to managing project security. This proposal aligns with the broader goals of improving QGIS's flexibility and robustness as a GIS platform, catering to both individual users and large-scale enterprise environments.

[m-kuhn]

For the record: this is too late for the 2024 year grant round, but if there's popular demand for it, I'd be happy to pursue it further.

[m-kuhn]

@timlinux would be nice to align this with #284
in particular the color code on the button (you proposed red and gray, this proposes blue and white as done in vs code)

[rouault]

When opening a QGIS project containing Python code (such as macros, feature actions, or expression functions), the user is currently prompted with a security warning.

I don't get any security warning for Python expression functions. Presumably because they are not contained themselves in the project, but in a file under the user profile.

And the "prompt" is dependent on which actual feature trigger it. In "Ask" mode for project macros, this is just a message bar notification. For the "Python init code configuation" of attribute forms, this is a message box.

Visual Studio Code-like Warning System:

I'm not familiar with VS. Any screenshot of such warning? I'm also wondering: when you open a "random" project and are asked if you want to activate macros, how can you take your decision rationally without actually inspecting the content? Currently, you have to know in the UI where to look at. One could potentially imagine to present the risky code to the user. Of course only users with a minimum of coding skills could actually be in a position to assess if it is harmless or not. That could potentially be something only shown if the user requests to inspect it.

Is this concept of trusted project and folder something that exists in other software?

Would there be some protection regarding the setting of trusted projects/folders? There might be similar concerns as in the authentication system (#278) about what plugins could do regarding that.

More generally, as for all security oriented features, I believe it is important to try to clearly present their limitation, so I play a bit the devil advocate, to understand scenarios they try to cover, and those which are out of scope or considered not a threat. So don't take any of the following as a rejection, but really more as brainstorming from someone without a formal security background.

Regarding "trusted path", this implies that content put in there is indeed (more) trusted than something found elsewhere. In case of a network share, you thus assume that all users who have write access are trusted to put safe content there. They could put unsafe content either by being malicious themselves or unintentionally copying a unsafe project not knowing it is unsafe.

For enterprise contexts, wouldn't an administrator potentially wish to strongly lock users, so they can only open trusted projects / from trusted paths, or if they open untrusted projects, then no Python/shell/etc. code may be run from it?

Have you considerer cryptography based solutions to check the provenance & integrity of a project? That is when you create a project (or save a project you created, but perhaps not when saving a untrusted project you opened), a hash of the project file, encrypted by the key of the user, would be added into the project file. On opening, if QGIS can verify the authenticity with the public key(s) it trusts, no warning would be generated if Python/shell/etc code is found in it. For enterprise contexts, you would probably want to have a store with the keys of other users you're collaborating with and which are assumed to be trusted. But if you want to do that properly, you may also need to handle revocation of a user certificate if he's found to have been compromised, so his past projects signed with his revoked key are no longer trusted.
In practice, it could also be tricky to ensure the trust chain if the threat model takes into account the fact that a user may have loaded a malicious plugin that would modify a project behind the back of the user to add malicious code into it. Such a risk already exists currently, but as there's no concept of trusted project/folder, users in theory should inspect projects with macros when asked about it. With the trusted project/folder functionality, a compromise in a trusted project could actually broaden the extent of the compromise.

At that stage, my own position is that I've no clear opinion if the proposed concepts are a good step forward or not. In any case, we may need to be prudent in choices of words so users really understand the limits of the "trust" we promise, and besides the code clear documentation in the user manual should be part of the task (in that respect, we should certainly aim at doing better that current https://docs.qgis.org/3.34/en/docs/user_manual/auth_system/auth_considerations.html since 90% of the 25.3 paragraph is a brainstorming of what should ideally be implemented... just filed qgis/QGIS-Documentation#8983 about that)

[m-kuhn]

Thank you for the thorough comments

When opening a QGIS project containing Python code (such as macros, feature actions, or expression functions), the user is currently prompted with a security warning.

I don't get any security warning for Python expression functions. Presumably because they are not contained themselves in the project, but in a file under the user profile.

Correct, sorry for the confusion we recently planned to implement that but didn't start so yet. Let's just keep this in mind for a potential future use case.

And the "prompt" is dependent on which actual feature trigger it. In "Ask" mode for project macros, this is just a message bar notification. For the "Python init code configuation" of attribute forms, this is a message box.

... which I think should be harmonized

Visual Studio Code-like Warning System:

I'm not familiar with VS. Any screenshot of such warning?

I have added a mockup in the proposal now

I'm also wondering: when you open a "random" project and are asked if you want to activate macros, how can you take your decision rationally without actually inspecting the content? Currently, you have to know in the UI where to look at. One could potentially imagine to present the risky code to the user. Of course only users with a minimum of coding skills could actually be in a position to assess if it is harmless or not. That could potentially be something only shown if the user requests to inspect it.

We ask them if they trust the "authors". This is applicable regardless of the technical skills of the person.
What I would typically expect to happen is: you have your own / organisation provided projects in a folder which is trusted but you will still get a warning when opening a project you receive by mail or download from the internet.

Is this concept of trusted project and folder something that exists in other software?

VS Code does it for instance :-)

Would there be some protection regarding the setting of trusted projects/folders? There might be similar concerns as in the authentication system (#278) about what plugins could do regarding that.

I don't think this would improve security. If you have code running on a target system, it's already game over.

More generally, as for all security oriented features, I believe it is important to try to clearly present their limitation, so I play a bit the devil advocate, to understand scenarios they try to cover, and those which are out of scope or considered not a threat. So don't take any of the following as a rejection, but really more as brainstorming from someone without a formal security background.

Regarding "trusted path", this implies that content put in there is indeed (more) trusted than something found elsewhere. In case of a network share, you thus assume that all users who have write access are trusted to put safe content there. They could put unsafe content either by being malicious themselves or unintentionally copying a unsafe project not knowing it is unsafe.

For enterprise contexts, wouldn't an administrator potentially wish to strongly lock users, so they can only open trusted projects / from trusted paths, or if they open untrusted projects, then no Python/shell/etc. code may be run from it?

That's not covered by the proposed implementation. Any user will have the possibility to declare any project as trusted. What administrators can do is to pre-configure trusted paths.
This is an improvement over the current situation, as if you are an admin and you need python code in a project, you need to either completely disable all protection via "allow all" or train your users to click "allow once" every single time they open the project which is effectively training them to just click away the obtrusive warning.

Have you considerer cryptography based solutions to check the provenance & integrity of a project? That is when you create a project (or save a project you created, but perhaps not when saving a untrusted project you opened), a hash of the project file, encrypted by the key of the user, would be added into the project file. On opening, if QGIS can verify the authenticity with the public key(s) it trusts, no warning would be generated if Python/shell/etc code is found in it. For enterprise contexts, you would probably want to have a store with the keys of other users you're collaborating with and which are assumed to be trusted. But if you want to do that properly, you may also need to handle revocation of a user certificate if he's found to have been compromised, so his past projects signed with his revoked key are no longer trusted. In practice, it could also be tricky to ensure the trust chain if the threat model takes into account the fact that a user may have loaded a malicious plugin that would modify a project behind the back of the user to add malicious code into it. Such a risk already exists currently, but as there's no concept of trusted project/folder, users in theory should inspect projects with macros when asked about it. With the trusted project/folder functionality, a compromise in a trusted project could actually broaden the extent of the compromise.

A cryptography based approach has a couple of implications. It's harder to setup and maintain (setup ca, keys etc), so if we enforce it, python code in projects will become unavailable for many. In a typical context there will be multiple people (qgis installations) working on a project and save it often (adding layers, change some symbology, ...) which will make that setup very hard to handle.

At that stage, my own position is that I've no clear opinion if the proposed concepts are a good step forward or not. In any case, we may need to be prudent in choices of words so users really understand the limits of the "trust" we promise, and besides the code clear documentation in the user manual should be part of the task (in that respect, we should certainly aim at doing better that current https://docs.qgis.org/3.34/en/docs/user_manual/auth_system/auth_considerations.html since 90% of the 25.3 paragraph is a brainstorming of what should ideally be implemented... just filed qgis/QGIS-Documentation#8983 about that)

A good documentation about potential threats and best practices for handling project macros / python code in project will help a lot, agreed.

There were a lot of questions and points in your comment. Please don't hesitate if you want me to elaborate more on something specific.

[m-kuhn]

For reference, the vs code documentation about this feature: https://code.visualstudio.com/docs/editor/workspace-trust

[rouault]

Thanks for the clarifications. shouldn't the scope of trusted/untrusted be widen to all executable code (namely actions with Windows/Linux/Mac code), not just Python ?

[m-kuhn]

Good point, I clarified on the first line.

[nyalldawson]

I have a thought about trusted projects -- I gather this just storing the path to the project in the user's local profile?

If so, I think that we need to go a step further (although not necessarily to the level of individually signing a project as @rouault describes). Rather I think at a minimum we should store a hash of the project along with the trusted status in the local profile, so that the user can be reprompted whether to trust the project IF it is changed at all. (This would help alleviate the concern of a malicious change being made to a previously trusted project by someone internally, eg a fired staff member)

I.e. it should be a particular version of a project which is trusted, not the path to the project alone.

[nyalldawson]

Also -- I don't think there's any way we can offer a "I trust the AUTHORS" option without @rouault 's proposed project signing. Rather this needs to be reworded "I trust this PROJECT FILE " / "I trust this version of the PROJECT", as it's trivial to spoof the authoring information of a QGIS project via editing the xml...

[m-kuhn]

I don't think trusting project versions is the right level of abstraction in every case (editing a project with several profiles locally, a trusted shared folder on an internal drive) and in many cases we will again start to bother users and train them to "just click on trust this" when the dialog opens again.

When referring author of the project file in this context, we are not referring to the XML (this is not visible on the dialog at all) but to where did you get that project from .

[nyalldawson]

@m-kuhn what about hashing just the python code from the project? So we'd only ask again if that's changed...

[m-kuhn]

This will not be compatible with trusted folders, and I think a managed shared organization folder where a well defined group of people manages projects for a larger audience is a common use case where the end user never ever should see a confirmation dialog. Also I am slightly worried about the added code complexity and I'd rather see this as a seperate follow up project if deemed reasonable.