Linux security: your questions, answered

At Canonical, we often get questions about open-source security and of course, Linux security is a common topic. Based on a recent webinar hosted by our security team and an accompanying blog post, we put together the most common questions we receive. This is by no means an exhaustive list, but it should give you a general idea about Ubuntu’s approach to security vulnerability management, livepatch, IoT, and its compliance and hardening tools.

If you are still curious about Linux security and would like to know more, or to put additional questions to our team, reach out here: https://ubuntu.com/security/contact-us

Ubuntu and security vulnerability management

Am I secure if I use 20.04.5 LTS even with ESM if my desktop can handle it? Because I really like 20.04 so far!

Yes, absolutely. ESM with Ubuntu Pro gives you 10 years security maintenance on all Ubuntu packages, and it’s free for personal use on up to 5 machines. Find out more at https://ubuntu.com/pro

How many CVEs are integrated in each Ubuntu release?

Patching security vulnerabilities (CVEs) is an ongoing process for the lifetime of the supported release. Canonical publishes OVAL data, available on the Ubuntu website, which contains details of all the security fixes that have been released: https://ubuntu.com/security/oval

For example, according to  the latest OVAL data for the 22.04 (Jammy) LTS release, at the time of writing we have published 249 CVEs since Jammy was released in April 2022.

My old Unix OS Internals professor told us that most system administrators didn’t apply patches and upgrades immediately because the patches would sometimes have unforeseen bugs in them?

This is an outdated approach and the industry statistics are quite clear:  almost all hacks and system compromises occur because people haven’t patched their systems despite the fixes being available. Today, the risks of a system breach far outweigh the risks of instability.

Are there plans to allow sysadmins to turn off auto updates for snap packages to maintain system stability?

Turning off auto updates is not recommended, as we mentioned earlier about systems being compromised when attackers exploit known vulnerabilities that have not been patched. If you follow a stable track for your snaps then you should only receive important security updates that won’t compromise stability.

Open source software and linux security

Does open source nature of Linux create  more vulnerabilities?

The short is no, absolutely not. It’s discussed in depth in episode 185 of the Ubuntu Security Podcast (no registration required). Bute will also tackle this very topic in an upcoming post, so make sure you are subscribed to our blog newsletter to hear about it! 

Is Ubuntu more secure than the underlying Debian?

We don’t compare Ubuntu security directly to Debian. Ubuntu is based on the Debian packages, but Ubuntu includes many more software packages that aren’t in the Debian ecosystem. Canonical provides full security maintenance for these packages for 10 years with Ubuntu Pro.

Ubuntu security, compliance and hardening

Can you discuss the Ubuntu Pro CIS benchmark compliance tools with report and hardening features?

With Ubuntu Pro you get access to tools which can harden your operating system to CIS benchmark standards. We also just released a new guide with all you need to know about system hardening which you can find here. 

Is there a native way to use hard drive encryption that doesn’t need a PIN to be manually entered at reboot, so it’s just tied to a TPM module?

This is a very valid concern, and we are working on this. 

Is the Ubuntu Security Guide available for Ubuntu v22.04?

We are working on this right now and hope to have it available by the end of April 2023.

In the world of immutable and ephemeral, and Infrastructure as Code, why are we still talking about patching and rebooting? Shouldn’t we encourage folks to automate and stop treating infrastructure as a pet or something beloved?

The industry is certainly moving in this direction, but the security primitives that we have been discussing still apply just as much to containers and IaC – software needs to be patched, and containers must be updated when vulnerabilities are discovered.

The method of deploying the infrastructure (manual or automated) doesn’t change the need to keep components secure. And when it comes to immutable containers, there is an increased risk that out-of-date software will be running for years – even if software is running in a container it still needs to be patched, and an updated container deployed.

Livepatch: Patch your kernel while it is running

How easy is it to join communities that contribute to the Kernel Patching process? Do I need to be based in a specific region? 

You don’t have to be based anywhere specifically in the world, as the internet enables everyone to collaborate – just join the Ubuntu community, starting here: https://discourse.ubuntu.com/

How does Canonical test Livepatches?

Livepatching the kernel is a delicate engineering effort. In order to minimise the risk of a bad livepatch impacting your machine, we rely on a gradual approach for testing and deploying livepatches:

• When Canonical detects a high or critical vulnerability on the Linux kernel, our kernel engineers create a livepatch to address the vulnerability.
• The livepatch is first tested in Canonical’s internal server farm.
• It is then promoted for gradual deployment as per the following order:
  • Internal deployment
  • Free subscription users
  • Customers
• If a faulty livepatch is detected at any particular stage, then of course we stop rolling it to the rest of the machines.

For customers who chose to deploy livepatch on-prem, they can take this tiered deployment one step further. Instead of rolling the livepatch to all of their estate’s machines at once, they can also adopt a gradual tiered deployment strategy. In fact, they can configure their livepatch server to have as many tiers as you want. In this context, tiers can be defined as containers that patches are put into.

Customers can then map their machines/ livepatch client instances to a specific tier. The server comes with a default tier list: edge, beta, candidate and stable. This list can be modified using the livepatch administration tool.

Have you ever had an incident with rolling a bad livepatch in production?

Even with thorough testing, there is still a risk of deploying a defective livepatch. This is what happened in 2021 for a livepatch which was meant to address a Medium severity CVE (CVE-2020-29372) on kernel 4.4 in Ubuntu 16.04 LTS (Xenial).

The defective livepatch was not caught in internal testing processes because the defect was a race condition, triggered by workload-specific behaviour, under load. The livepatch would cause the madvise system call to block indefinitely, and thus cause lockup to the processes using the call. These conditions were not replicated in our test environment.

The defective livepatch passed our testing, because we had only tested it on newly provisioned systems, and the conditions of reaching the lockup required a running system that had processes with the offending lock on a different state.

You can read more about it here:https://canonical.com/blog/livepatch-2021-03-24-incident-investigation-report

How can you recover from a bad livepatch?

There are multiple ways to recover from a bad livepatch, and all of them get you to temporarily disable livepatch services, as the defective livepatch would otherwise be reapplied after you reboot.

If the system is running:

• Disable livepatch
  • snap stop –disable canonical-livepatch
• Remove the offending livepatch by issuing the following commands:
  • sudo rm -rf /var/snap/canonical-livepatch/common/payload
  • Reboot

If you can only access the kernel command line:

• Turn off the livepatch service from the kernel command line by adding:
  • systemd.mask=snap.canonical-livepatch.canonical-livepatchd.service
• Remove the offending livepatch by issuing:
  • sudo rm -rf /var/snap/canonical-livepatch/common/payload
  • Reboot

If you only have access to the grub2 boot menu:

• Select and boot your backup kernel
• The livepatch client will remove the failed patch, and pick up the most recent livepatch for your backup kernel.

IoT

Does Canonical have any offerings related to IoT, its management, patching, deploying? What are my options?

Ubuntu Core is the solution here: Core is a version of Ubuntu designed for IoT and devices which is built entirely with snaps – snaps are a secure-by-default containerised and constrained software runtime and deployment mechanism that update themselves with the latest security fixes. Read more about the security of Ubuntu Core here: https://assets.ubuntu.com/v1/66fcd858-canonical-ubuntu-core-security-2018-11-13.pdf

For more information, you can read about the Ubuntu security and sandboxing primitives, our whitepaper on Embedded Linux: Yocto or Ubuntu Core and our insights into the question of building or buying embedded Linux.

Other

How will computer security affect our lives in the next decade?

We cannot answer this without gazing into the future.  But one thing we can say for sure: with Ubuntu Pro you can get 10 years of security maintenance, free for personal use, on up to 5 machines!

When will there be a ‘built-in’ multi-device cloud drive like iCloud, OneDrive, or GDrive, without having to go through complicated mounting procedures? This would improve UX and make storage more secure.

We can’t say what the future will look like, but we tried Ubuntu One storage some years ago and that was not successful, so while there are workarounds, a new version is not likely any time soon.

Conclusion

If you still have any outstanding questions or concerns about Ubuntu or Linux security, contact us at: https://ubuntu.com/security/contact-us

We publish new Linux security – related content regularly, so sign up for blog updates to keep up to date.