-
-
Notifications
You must be signed in to change notification settings - Fork 6
Investigate further system security hardening #479
Copy link
Copy link
Open
Labels
component: securityAn issue relating to host security (e.g. hardened security preferences). This is NOT critical bugs.An issue relating to host security (e.g. hardened security preferences). This is NOT critical bugs.component: servicesAn issue relating to a Python Discord service (e.g. Bot, Site, Lancebot)An issue relating to a Python Discord service (e.g. Bot, Site, Lancebot)group: ansibleIssues and pull requests related to the Ansible setupIssues and pull requests related to the Ansible setup
Metadata
Metadata
Assignees
Labels
component: securityAn issue relating to host security (e.g. hardened security preferences). This is NOT critical bugs.An issue relating to host security (e.g. hardened security preferences). This is NOT critical bugs.component: servicesAn issue relating to a Python Discord service (e.g. Bot, Site, Lancebot)An issue relating to a Python Discord service (e.g. Bot, Site, Lancebot)group: ansibleIssues and pull requests related to the Ansible setupIssues and pull requests related to the Ansible setup
Type
Fields
Give feedbackNo fields configured for issues without a type.
Projects
Status
Up next
Planning ticket to check out and investigate further possibilities at security
hardening. Ideally these should be contributed upstream if applicable.
Things to consider:
Of course, service-specific hardening strategies implemented in code also play a
role. For Postfix and OpenSSH for instance I am way less concerned than e.g. for
Jitsi. At the bare minimum, all services should run under a dedicated user.
This ticket is not for evaluating resource limits per service (e.g. to prevent
DoS on externally reachable services), although it might also be interesting to
evaluate that.