Trying to break down into concrete questions, if helpful:

  1. Does it mean that if someone guesses your password, they can meddle with your updates or livepatch?
  2. Is there an added authentication process that takes place during livepatch, reliant on this account? if so, why?

That said, it's great to see this type of investment in the product!

  • Wow is it that experimental a feature that nobody knows? – matt Jun 16 '19 at 7:29
  • Never heard of it: livepatch - "Apply critical kernel patches without rebooting." free for 3 machines using an UbuntuOne account. Did you try contacting Canonical as they instruct on that linked page? – pbhj Jun 17 '19 at 13:50
  • 1
    It pops up in 18.04 as if a seamless part of the updates thingy, so it should likely be self-explanatory without going through tears of support (or the solicitation can be removed or made much clearer, if it's not worth documenting). As it stands now in the UI, I'd say it deserves a bit more clarity and a good fit for this Q&A site dedicated to Ubuntu. – matt Jun 17 '19 at 17:59
  • Aye, but if you ask whatever support tier then you could document the answer here for others and that can be used to feed in and create documentation elsewhere. You're right, someone else should have by now. – pbhj Jun 17 '19 at 18:40
  • 1
    Short answer: asking the source is a legitimate way to get a canonical answer that can then be shared. – pbhj Jun 18 '19 at 10:47

Opening an account with any service anywhere only has security implications if you:

  • Re-use login names / passwords
  • Use easy to guess passwords
  • Don't protect your password resets (e.g. by never changing your primary email account's password)
  • Share passwords
  • ...

So beyond basic account security:

No, there is no additional risk opening an account to do live patching.

OTOH: do you really need it as it's great for servers that need to be available 24/7/365, but for your Laptop / PC??? Not really in my personal and totally subjective opinion

  • 1
    Not "only" that. Problems do not come only from user not following best practices. If the service provider stores password un-encrypted and there is a leak, there are security implications for all users, even if the users themselves did nothing wrong per se. One case among many others. – Patrick Mevzek Jun 19 '19 at 17:31
  • LivePatch is run by Canonical for Commercial servers and they give 3 away for free for non-commercial use. You think they store passwords in plaintext??? @PatrickMevzek – Fabby Jun 20 '19 at 7:30
  • 1
    That is besides the point. And you would never know anyway, even big companies do big mistakes, so I never give blanket assessment just based on a name or size. The point was just to illustrate that, no, contrary to your answer, the security is not only in the hands of the user. The provider use has an impact on the security also of its users. – Patrick Mevzek Jun 20 '19 at 7:38
  • It's not: It's exactly the point: I don't trust FaceBook and don't have an account, but do trust Canonical and have a LivePatch account. @PatrickMevzek Also see the note at the end: the most secure account is no account at all (Does OP need one???) – Fabby Jun 20 '19 at 7:44
  • 2
    The bounty expiring will automatically go to this answer, though it's more like a grocery list of what could be the answer to other questions. it doesn't deobfuscate the architecture of the service in analyzing its specific security implications, nor include concrete information. Sorry but had to be honest about it. – matt Jun 20 '19 at 13:36

Contrary to some naive black-and-white views, using any kind of service like that opens you to security problems no matter what and even if you do everything right on your end.

But first a caveat: I am not a user of this product, so I can only offer a personal assessment based on what I read.

TL;DR: the security implications are that you are allowing a third party to directly update your systems without actions from you and hence you are relying on it to do its job properly and securely and also relying on having a good security throughout the network path between you and that provider (which impacts different levels, from IP because of BGP hijacking, up to DNS resolution and X.509 certificates probably).

Kernel livepatching in general

First, it is important to understand that "live-patching" is a feature of recent Linux kernels, with multiple implementations. Which also mean that you can profit from it yourself, without relying on any third party (you can see an example here: http://chrisarges.net/2015/09/21/livepatch-on-ubuntu.html). This is of course not simple as you have to master the technology, define what merits to be patched and what can be patched or not, then create the patches, then applying them, etc.

A third party, like Canonical here, just packages all of that experience for now, so then it is an assessment on cost/benefit, the cost not being just the monetary part (for example here, if you use their service for free you might get used as a canary tester, see "Q: How does Canonical test livepatches?" in http://blog.dustinkirkland.com/2016/10/canonical-livepatch.html which has this "it's rolled out on a canary testing basis, first to a tiny percentage of the Ubuntu Community users of the Canonical Livepatch Service." and "Ubuntu Community users of the Canonical Livepatch Service who want to eliminate the small chance of being randomly chosen as a canary should enroll in the Ubuntu Advantage program (starting at $12/month).")

I would however offer this generic statement that applies to many "centralized" technologies that have no specific reason in fact to be centralized: it would be nice to have both on one side an architecture to conduct those live patches easily, irrespective from where the patches come, and, separately from the above, giving a way for the user/customer to be able to easily choose its source of patches, that is the provider(s) it trusts to do that, which can include both commercial and free solutions, but with choice (for example some providers may be more restrictive in what is patched, others with a broader scope, etc.)

Letting the user be able to decide what trust it wants to give and to whom is something missing in many setups.

Here, you are then relying exclusively on Canonical to do its job properly. It is a matter of trust but you almost always do not have any useful indicators from outside on the level of trust you can give. You can decide to trust a company just because of its name, or its size, but you will easily find counter examples on big companies either by name or size that do silly things on purpose and not and fail in some way. This does not mean that you or I should not trust this specific provider, it is just a generic posture of either believing everyone innocent until proven guilty or the exact opposite (and of course proving something negative such as "there is no problem/error/security hole" is impossible, so you just have to live with compromises)

Because your security does not depend on just your actions and if you choose a good password without reusing it anywhere. You could apply all the best security guidelines in maintaining your credentials, but behind you the provider can do silly things like storing it in plain text or MD5. Or exchanging it without HTTPS. Or a million of other problems.

On delivering automated updates

Using a service like that is similar to letting your system be automatically updated without intervention from you. This has both good and bad consequences so a risk assessment has to be conducted.

There are recent examples on what can go wrong nowadays in cases like that:

  1. Mozilla blocked Firefox extensions and updates because of some signing failures (https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/); this is basically a reverse generic DOS attack, by a single failure in one spot (Mozilla servers) everyone using them is negatively impacted. This is very similar to kernel livepatching: your browser has extensions, and they can be set to be automatically updated; but if the mechanism fails it can unfortunately here even block extensions to be run, it is not even just an update problem
  2. ASUS got its update infrastructure invaded by pirates that used it to ship malware to customers (https://arstechnica.com/information-technology/2019/05/asus-cloud-service-abused-to-install-backdoor-on-pcs/)
  3. through BGP hijacking people were able to divert traffic to a known website dealing with crypto-currencies and then make people lose part of their portfolios as they were redirected somewhere else. This is the myetherwallet.com story from 2018: https://www.psychz.net/client/blog/en/theft-of-cryptocurrency-of-myetherwallet-users-by-bgp-hijack--.html Note in passing that the criminals did not even bother to use anything else than self-certificate as people do not seem to care about the warnings displayed then, or operations were happening by automated software that is often wrongly built to not correctly check remote certificate and properly act on those not really validated by a known CA
  4. The more recent "DNSpionnage" saga (https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/) is an evolution of previous case where a combination of BGP hijacks, stolen passwords and automated creations of new DV X.509 certificates for TLS communications, which is then able to thwart even the best software configured to allow only certificates from known CAs.

The above list shows very different cases:

  1. was a provider defeated by its own architecture: an expired certificate render the whole subchain below it as invalidated, this is by design
  2. was a provider seeing its architecture being abused from inside of it by some attackers
  3. was a website not directly attacked, as criminals were able to hijack resources "below" it (the IP address) to make the traffic flow to them instead of the true website (which means that as secure and perfect that website is or could be, there is nothing at that level that could have prevented this attack)
  4. was a wide scale attack on multiple systems, including humans getting errors in their software about changes in certificates or mismatches and still going further

In theory, Canonical LivePatch system like any other, could suffer from the same kind of attacks as outlined in the list above, and others of course.

Canonical LivePatch system

From documentations online, once you start the specific snap service and generate your token, you have nothing more to do, updates (kernel patches) will automatically come to your system and be applied.

In every case, it is always useful to read the fine print and here the terms of service at https://ubuntu.com/legal/livepatch-terms-of-service You can find in them the standard sentences about a service offered as-is without any guarantee, and at the end "Otherwise, Canonical's total liability in contract, tort or otherwise for any claims is limited to £10."

It is my understanding that holding an account is made mandatory to track how you use the system (since there is a free offer for 3 servers), but login in does not permit specifically to "push" some updates. One may guess/theorize that in a "business" setup, such kind of access could allow to view a list of servers concerned, know their livepatch status remotely (having a dashboard), and maybe restrict/pause/force some livepatching.

In fact, not a theory at all it is exactly written in the data sheet at https://assets.ubuntu.com/v1/ef19ede0-Datasheet_Livepatch_AW_Web_30.07.18.pdf :

The On-prem service gives you all the benefits of the Canonical Livepatch, but enables full control of rollouts of patches and easier tracking of the state of registered machines. The On-prem service is available as a site-wide subscription initially deployed by Canonical to the cloud of your choice.


The On-prem Livepatch service allows you to define rollout policy and remain in full control of which machines will get updated and when. To keep your machines up-to-date, the on-prem service regularly syncs with Canonical Livepatch and obtains the latest patches. However, the on-prem server allows you to set the policy for staged releases and apply a new patch to a controlled subset of machines across the data center and after validation, apply the patch to a wider set of machines in as many stages as needed.

(it is not clear to me though how the authentication part is handled, if it remains internal to the on-prem instance or if it is still globally managed by Canonical)

So for your question of:

Does it mean that if someone guesses your password, they can meddle with your updates or livepatch?

the answer is a YES if you take into account all possible use cases.

Another thing to take into account is the fact that the client (the canonical-livepatch snap) is proprietary and hence no source code is available. You thus have no idea what exactly this code does, even if you wanted to study it. You would probably need to install a proxy and meddling with TLS handshakes and DNS records to capture what data is transmitted in both directions.

You can at least congratulate them for their honesty at http://blog.dustinkirkland.com/2016/10/canonical-livepatch.html which is technically right here:

Q: Isn't livepatching just a big ole rootkit?

A: Canonical Livepatches inject kernel modules to replace sections of binary code in the running kernel. This requires the CAP_SYS_MODULE capability. This is required to modprobe any module into the Linux kernel. If you already have that capability (root does, by default, on Ubuntu), then you already have the ability to arbitrarily modify the kernel, with or without Canonical Livepatches.

Secure boot

Note in passing from https://wiki.ubuntu.com/Kernel/Livepatch this part:

Why isn't Livepatch working on my machine?


If you are using secure boot, you will also need to import the livepatch public keys into your keyring.


After this enter a password if necessary for MOK, then reboot. Your BIOS will then guide you through enrolling a new key in MOK. At this point you will be able to verify the module signatures.

I'm not an expert in secure booting nor the exact consequences of adding such a key, but I think a thorough assessment of the technology and its risks will need to review that part of it.

Authentication process

Your question was

Is there an added authentication process that takes place during livepatch, reliant on this account? if so, why?

When you start your service and instance of the process you need to provide a "token". This is obviously tied to your account, but this is the only piece configurable on your system and the snap livepatch daemon uses this to communicate with its servers.

This other question on this site is also relevant: What data are transmitted to Canonical for livepatch?

We learn that the proprietary software exchanges a non-trivial amount of data, which is not necessary technically for livepatching (ex: current uptime) but is part of the Canonical service.

But no information on how authentication works, based on the token given. Is it exchanged as is or are other cryptography materials derived from it? Is the exchange done in a TLS stream? With proper checks on the certificates (and matching of hostnames) and their validity, both regarding times and signatures of upstream CA and which CAs are allowed? Again, you will need to trust (or not) the provider per se because there is no public details on all of that.

You may try to contact Canonical and get back detailed technical replies on your question. If that happens it would surely be of interest to audiences on this site, but there is no guarantee it happens.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.