[Qgis-psc] The security project for QGIS

[Julien Cabieces]

Hi Even,

My thoughts on some points

> Vincent,
>
> excellent, and ambitious, initiative.
>
> A few points (they don't necessarily need to all be addressed at that
> earlier stage):
>
> - Regarding putting in place static code analysis (A.1) or dynamic
>   code analysis (B.1), does that cover only putting into places the
>   tools & automation, or also addressing issues that are raised?
>   There's a huge difference in terms of effort. For a project of the
>   size of QGIS I would expect about 1000+ issues (1.7 MLoC * 1 defect
>   per thousand line of code = 1700)  raised for each new analysis tool
>   added. A lot are 5-minute type of fix by knowledgeable
>   developers. Some can be really hard to fix, requiring API or design
>   changes. A very rough estimate could be that it is a 1 man-year
>   level of effort to address 90% of the issues reported, per analyzer
>  added.
>

IMHO we have to fix them, not only raise them. But as you said, that a
lot of work. My strategy here would be to:
- fix the easy ones, the one for which there is a "fix it" for instance,
and made them mandatory in our static analyzer
- For the other ones, we should try avoid adding some in new code (like it's already
done by clang-tidy-diff for instance).

That's kind of the current policy, but I think we should go even further.

We also have to discuss the appropriate set of checks we want to set up.


> - Regarding dynamic analysis, thinking in particular to something like
>   ossfuzz, I agree this enters the "difficulty: hard" since it
>   requires static linking (at least last time I checked). And that
>   also requires writing dedicated test programs for fuzzing purposes,
>   exercising different part of QGIS, like parsing project files, or
>   other identified attack surfaces etc.
>
> - Regarding hardening processes (thinking to items like Developer
>   Certificate of Origin or Access management systems for developers),
>   there's the risk of making QGIS contribution too hard to to the
>   point where it could deter new contributors, particularly if they
>   contribute on their personal time. Our current processes with a
>   strong CI might already discourage the less motivated ones. Some
>   difficult balance to find here.
>
> - Regarding raw pointer elimination, that's going to be hard
>   indeed. The main obstacle I see is that the QT API itself does not
>   use use smart pointers. So the bug surface will move at the boundary
>   where QGIS smart pointers are converted to raw pointers (misuse of
>   .get() vs .release()). Smart pointers also doesn't make code memory
>   safe per se, there are still lots of opportunities to shoot yourself
>   in the foot, so the title "Make Code Memory Safe" is probably too
>   ambitious. It could only achieved by using a language like Rust. I
>   didn't look at the maturity of the Rust bindings for QT ;-)
>

I agree "Make Code more memory Safe" would have been a better name. I
also agree that we would have some unsafe code at the boundary with
other dependencies like Qt (but also proj, gdal, libpq, libora...) but I
do think that if we already use safer code structure in QGIS code, it
would be already something, making the application safer and getting
rid of some unwanted behavior.

Like the static analyzer, this is no silver bullet here. This is more a
way we should heading toward to enforce security (and application
stability in the mean time).

Regards,
Julien


> - I see GDAL, PROJ, GEOS being mentioned in the scope of the
>   initiative. What are your thoughts regarding this? My assessment is
>   that PROJ and GEOS have a low to medium attack surface from a
>   security point of view. By its own nature (reading hundreds of file
>   formats), GDAL one has a huge one obviously. I'd tend to think we
>   are rather in a good shape though, having taken steps for many years
>   putting in place static & dynamic analysis, and fixing most
>   issues. That's a never ending fight though. Regarding fuzzing, I
>   know that some drivers are in blind spots of fuzzing tools since
>   they would require dedicated fuzzers to be written to exercice
>   them. Not to mention that vulnerabilities might belong to lower
>   level components, some of which have no willingness/capacity to
>   address such issues or even consider contributed fixes.
>
> - I don't know if it is a real risk or if I'm a bit paranoid, but one
>   side effect of displaying a focus on security could be that
>   "parasite" actors, thinking here to bug bounty chasers, developers
>   of new analysis tools, could see QGIS as a new playground for their
>   feats, so the security team might be overwhelmed by reports of
>   varying relevance and quality...
>
> Even
>
>
> Le 29/11/2024 à 11:12, Vincent Picavet via QGIS-PSC a écrit :
>> Hi PSC,
>>
>> Oslandia will be launching soon the "Security project for QGIS". I
>> explain the project in details below.
>>
>> New European regulations like NIS2 and CRA, as well as other
>> international or local regulations ( e.g. CISA ) will be activated
>> within the next couple of years. They require software and software
>> producers to rise their cybersecurity practices. OpenSource
>> softwares, while usually having a special treatment, are concerned
>> too.
>>
>> As for QGIS, we consider that we are behind what would be sufficient
>> to comply with these regulations. We also do not fulfill
>> requirements coming from our end-users, in terms of overall software
>> quality regarding security, processes in place to ensure trust in
>> the supply chain, and overall security culture in the project.
>>
>> We have been discussing this topic with clients having large
>> deployments of QGIS and QGIS server, and they stressed the issue,
>> stating that cybersecurity was one of their primary concerns, and
>> that they are willing to see the QGIS project move forward in this
>> area as soon as possible.
>>
>> Oslandia, with other partners and backed by some of its clients,
>> intends to launch the "Security project for QGIS" soon : we
>> identified key topics where improvements can be done, classified
>> them, and created work packages to work on, with budget
>> estimations. We intend to do a call for funding for this project, in
>> order to get actual improvements over 2025 and 2026.
>>
>> We intend to work closely with the QGIS community, QGIS.org,
>> interested partners and users. Part of the work are improvements
>> over the current system, other require changes to processes or
>> developer's habits. Working closely with the user and developer's
>> community to raise our security awareness is fully part of the
>> project.
>>
>> You can see the current draft of the proposal here :
>> https://pad.oslandia.net/vas3e9TUTQKJVSjTseVXrQ?both#
>>
>> Please do not share this URL publicly, as it is still a draft, and
>> will be moved to an official web page soon.
>>
>> We know that this is an ambitious project, and that some parts will
>> be difficult to achieve, but we think that QGIS cannot ignore the
>> current trend in cybersecurity enforcement, and we know that
>> regulations and clients requirements will force us to move forward
>> anyway. Planning ahead and taking the issue seriously with the right
>> amount of resources and efforts seems a better way to go than being
>> constrained to do things in a hurry later on.
>>
>> We intend to launch the project soon, as some clients want to be
>> able to fund it on 2024 budgets, and start working as early as
>> January. We will first have a direct approach to potential funders
>> and partners though, before making a public call for funding ( most
>> probably before end of 2024 ).
>>
>> Sponsors for this project will be QGIS users directly funding the
>> project.
>>
>> Partners for this project will be :
>> - organizations officially supporting the project and help
>> communicate and raise funds
>> - organizations contributing time, effort, expertise to help the project
>> - subcontractors for parts of the project
>>
>> As for subcontracting, some items are already identified and
>> dedicated to partners, most of them will still have to be defined
>> after.
>>
>> As for now, apart from Oslandia, OPENGIS.ch is already an official
>> partner.
>>
>> We wanted to let the PSC / QGIS.org know about the project before
>> enlarging the audience, so that :
>> - A. you can give us feedback on the project globally, and the
>> content specifically
>> - B. raise any questions you would like to be answered privately or
>> publicly
>> - C. indicate your thoughts on how QGIS.org would want to be
>> integrated into the project
>> - D. validate project name, logo and URL
>>
>> As for C, we will state clearly that this project is not a QGIS.org
>> initiative, but a project initiated by Oslandia and
>> partners. QGIS.org could be a partner though, and we would be
>> pleased if it is, but it is clearly not mandatory. Your decision,
>> without any pressure ( can be later on too ).
>> As for budget as well, we do not ask for any contribution from
>> QGIS.org, but QGIS.org could allocate some funding, either as
>> sponsor for items already included in work packages, or for
>> additional complimentary items ( I would rather opt for this option,
>> e.g. everything related to external reviews, community meetings,
>> legal stuff…).
>> Also, we will recommend for any sponsor willing to contribute less
>> than 5000€, to fund QGIS.org instead through donations, as we do not
>> want to deal with small contributions for this project ( admin
>> burden too high ).
>>
>> As for D, what we need from PSC ASAP is a validation for us to be
>> allowed to use the following :
>> - the project name "Security project for QGIS". Note that we avoided
>> naming it "QGIS Security project", to better identify that the
>> project is not initiated by QGIS.org. As said above, we will be
>> clear in the project presentation about affiliation.
>> - the project logo
>> : https://pad.oslandia.net/uploads/68ed0fc7-a6e3-4a93-8b6a-34ba2335c7dc.png
>> - the url we intend to use : security.qgis.oslandia.com . Again, it
>> makes no doubt on affiliation.
>>
>> Should you have any remark on these items, do not hesitate to raise them.
>>
>> Next step are :
>> - [x] contact QGIS PSC to present the initiative
>> - [ ] integrate feedbacks into the project presentation
>> - [ ] finish project presentation material
>> - [ ] contact some more potential partners
>> - [ ] get first pledges from users for WP1
>> - [ ] launch public call for funding
>>
>> I am available to discuss the matter, do not hesitate to contact me
>> for further info or discussion.
>>
>> Best regards,
>> Vincent
>>
>>
>>

-- 

Julien Cabieces
Senior Developer at Oslandia
julien.cabieces at oslandia.com