Additional Ubuntu Hardening
-
I'm planning to colo a small server to host my cloudron, and want to make sure I've got it secure enough without getting in the way of Cloudron. I'm going to follow most of the advice in the Cloudron security guide. Beyond that, there are a few other things I can think of:
- Enable livepatch
- Run something like this Ansible hardening role. I need to know if any of these things would conflict with Cloudron:
- Allowing only signed packages
- Removing a few packages
- Removing setuid bits from a few binaries
During setup, does Cloudron already do any of those steps anyways, and / or would they conflict with Cloudron (e.g. does it rely on any unsigned PPAs)? As much as possible, I'd love to rely on Cloudron to handle this so I don't have to think about it.
-
Generally doing any additional system configuration or removing/adding other ubuntu packages to the system is not supported, since we cannot test such variations for updates.
Cloudron already only installs signed packages. Enabling livepatch should be ok to do.
For all the other things happening through that ansible role, we would have to go through them one by one and test accordingly. We will not support running such hardening scripts automatically, there are too many of these out there. So if there are really good reasons to disable/configure system components for security we can investigate. Often security roles don't even apply to Cloudron if the corresponding components are not even used.
-
Generally doing any additional system configuration or removing/adding other ubuntu packages to the system is not supported, since we cannot test such variations for updates.
Cloudron already only installs signed packages. Enabling livepatch should be ok to do.
For all the other things happening through that ansible role, we would have to go through them one by one and test accordingly. We will not support running such hardening scripts automatically, there are too many of these out there. So if there are really good reasons to disable/configure system components for security we can investigate. Often security roles don't even apply to Cloudron if the corresponding components are not even used.
@nebulon is there any recommendations on reboot frequency with livepatch enabled?
-
G girish has marked this topic as solved on
-
@girish it does, but it's about minimizing reboots, not removing a necessity to reboot altogether (https://ubuntu.com/security/livepatch/docs/faq).
That's why I'm asking if there are any best practices...
-
@girish it does, but it's about minimizing reboots, not removing a necessity to reboot altogether (https://ubuntu.com/security/livepatch/docs/faq).
That's why I'm asking if there are any best practices...
-
On Ubuntu, if a reboot is required, then the file at
/var/run/reboot-requiredexists. This is also what Cloudron uses to raise the reboot required notification. -
@nebulon thank you.
I don't believe it's exactly that way with livepatch enabled, as a reboot flag (file) is created within dpkg that is not aware if livepatch is enabled and if it covers the flow that it patched...@potemkin_ai I personally haven't used ubuntu live patch anywhere so far, but according to https://askubuntu.com/questions/1248091/why-am-i-being-asked-to-restart-system-even-though-i-have-canonical-livepatch it seems that this is to be expected if other packages besides the kernel require a reboot.
Maybe someone here in the forum has more hands on experience with what canonical has built there?
-
@potemkin_ai I personally haven't used ubuntu live patch anywhere so far, but according to https://askubuntu.com/questions/1248091/why-am-i-being-asked-to-restart-system-even-though-i-have-canonical-livepatch it seems that this is to be expected if other packages besides the kernel require a reboot.
Maybe someone here in the forum has more hands on experience with what canonical has built there?
@nebulon thank you, hope to hear some wisdom from the community
-
N necrevistonnezr referenced this topic on
Sorry, not aware of any best practices around this.