#2855 PR merged: GitHub Workflows security hardening

Labels: enhancement, fixed / solved / done, critical / security / legal, ReaR Project

sashashura opened issue at 2022-09-01 16:28:

This PR adds explicit permissions section to workflows. This is a security best practice because by default workflows run with extended set of permissions (except from on: pull_request from external forks). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an injection or compromised third party tool or action) is restricted.
It is recommended to have most strict permissions on the top level and grant write permissions on job level case by case.

jsmeix commented at 2022-09-19 09:44:

@rear/contributors @pcahyna
if there are no objections
I intend to blindly merge it tomorrorw afternoon
(bindly because I know basically nothing about GitHub workflows).

jsmeix commented at 2022-09-21 07:46:

thank you for your valuable contribution to ReaR
thak makes our GitHub upstream repository more secure!

I do not understand why the GitHub workflow
default permissions are not sufficiently secure.
Why must each and every GitHub user manually adjust the
workflow permissions to make things reasonably secure?

sashashura commented at 2022-09-21 20:10:

I guess because granular permissions were not introduced from the very beginning and then they didn't want to break things. I also recommend changing this - https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#preventing-github-actions-from-creating-or-approving-pull-requests

jsmeix commented at 2022-09-22 09:24:

@gdha @rear/contributors
I changed now in
the section "Workflow permissions"
so that it looks now as in the
"Preventing GitHub Actions from creating or approving pull requests"
section in the GitHub documentation

I.e. now the ReaR "Workflow permissions" are
no longer Read and write permissions
instead only Read repository contents permission
and no longer Allow GitHub Actions to create and approve pull requests

Please speak up if this changes cause regressions
for this or that existing GitHub Actions in ReaR
so we can evaluate if we could adapt the specific Action
or if we really must have so permissive defaults in ReaR.

jsmeix commented at 2022-09-22 09:31:

thank you for your additional info.
It is much appreciated.

Too permissive defaults are a security nightmare
because one cannot notice it (because things "just work")
unless it is too late (after a repository was compromised)
or by luck when a mindful person kindly informs one.

In contrast too restrictive permission defaults are OK
because one notices it when things do not "just work"
and then one can think about if more premissive settings
are really needed or if somewhat reduced functionality
that works with reasonably restricted permissions is sufficient.

By the way - cf. "Security: Make Things Not Just Work" in

[Export of Github issue for rear/rear.]