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:
- 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
- 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/)
- 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
- 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:
- was a provider defeated by its own architecture: an expired certificate render the whole subchain below it as invalidated, this is by design
- was a provider seeing its architecture being abused from inside of it by some attackers
- 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)
- 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?
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.
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.
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.