#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:¶
@sashashura
thank you for your valuable contribution to ReaR
thak makes our GitHub upstream repository more secure!
Sigh!
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
https://github.com/organizations/rear/settings/actions
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
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
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:¶
@sashashura
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
https://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings
[Export of Github issue for rear/rear.]