I have a client who’s been getting worried by recent news reports about AI-discovered vulnerabilities, and they want reassurance that they are getting security updates as soon as they are available.
There was some question/concern when they do a package upgrade and get the “the following packages have been kept back” message.
I would like to reassure them that this never happens for security updates.
Can I? I couldn’t find anything in the articles about phased updates that discusses whether the phased-update system includes security updates.
Relatedly, is there a command-line invocation I can use that will list/upgrade only the security-related upgrades?
You can turn them off ( at the risk of getting bugs that are supposed to be catched via phased updates indeed):
I’d also suggest to your clients to turn on Canonicals Live-Patch service, that will make sure that kernel vulnerabilities are fixed on the spot without reboot… (and indeed also enable Ubuntu pro if they use any packages from the universe repository and want security updates for these)
I don’t know what has come of that discussion, though, but it looks like there aren’t any security updates on weekends anyway, for instance, which one might want to be aware of.
Yes, and whether I do this is based on the answer to my main question, re-worded here:
Are security updates (i.e. packages downloaded from a -security suite) included in the phased-update system?
(new, related question) Or, if they are, can I configure things so that security updates are excluded from the phased-update system, while leaving the phased-update system active for non-security updates?
Security updates are typically not phased. Most security updates are immediately available to all users.
But that’s not a law. The Security Team can use Phased Updates if they feel doing so would be wise.
The default settings of unattended-upgrades for a stock install of Ubuntu are indeed for security updates only.
The actual setting is in /etc/apt/apt.conf.d/50unattended-upgrades, for users who might wish to change it (or revert a change).
Most users don’t need to do anything. A stock Ubuntu system will check for security updates twice daily, including often immediately after booting. By the time a human gets round to checking, all available security updates are usually installed already.
(This confuses some humans, who misunderstand “No new updates available,” not realizing that updates installed seconds ago are indeed no longer “available”. They are “installed” now. )
The easiest way to manually check and install security updates is to simply run
sudo apt update
unattended-upgrades # using the default settings, of course
If you REALLY want to manually specify only security upgrades, you’re already most of the way there. This is wasted effort for most users, but it won’t break anything so go right ahead:
apt list --upgradable | grep -i ‘security’ # List the security packages
sudo apt upgrade package1 package2 package3 packageN # Upgrade the list of packages
Your client being concerned about vulnerabilities in the platforms which they run is commendable and an increased concern with the recent rapidly increased rate of discoveries and less-than-ideal reporting is reasonable.
While it would be more than glib to tell your client that for them nothing has changed, this remains true. Implicit in running a platform which is packaged, distributed and managed by an organisation such as Canonical is the acceptance that they will follow a process which involves many choices and stages[1], none of which require input or action from the client, whose only job (which probably becomes your job) is keeping the platform updated and mitigating any actual vulnerabilities in their environment.
The challenge has always been and, alas, remains that “the news” reports problems with upstream software, often including versions which are vulnerable and fixed. Consequently, the client who knows that they use some software, hears that version 3.2.1 is vulnerable and fixed in 3.2.2, but don’t understand that the latest stable version 3.1.8 is not even vulnerable and that this is the version packaged for their platform and running on their system. This is just one example in a broader category.
This problem gets so much worse when their Enterprise™ quality vulnerability scanner picks up example, calculates that 3.1.8 is less than 3.2.2, and declares that the system is vulnerable and out of compliance.
Good luck with your communications.
Including, but not limited to, which version of a software product to package for a given platform version, what changes to the distributed software to make, what configuration and build options to use, which updates to adopt, what fixes to backport, and what inconsequential changes to ignore. ↩︎
Have you explained to your clients that Linux/Ubuntu is Open Source?
This means that the source code is available for anyone to download and examine. Which is what people do. If they find flaws in a code sequence that could be put to malicious use it is reported. These vulnerabilities are often fixed/patched before anyone has made malicious use of the flaw. And before the criminals know the vulnerability exists.
This has been the pattern for decades and why Linux is a very secure operating system. Not only that but commercial rivalry between distributions of Linux does not prevent software engineers from different Linux distributions from working together to fix serious vulnerabilities. It is to the benefit of all.
What has changed? Someone is using computer programs to search software source code for code patterns that identify a vulnerability. It speeds the process up. Like virus scanners which need a database of code to recognise a virus. These AI agents need a database of code that is classed as vulnerable. In my opinion.
Now compare the situation of users of proprietary software. The only people allowed to examine the source code are employees of the organisation owning the software. No AI agents searching the source code for vulnerabilities and publicly reporting what is found.
“Ignorance is bliss.” Until you get a ransom demand. Or, your clients want know how it is that their identity has been stolen.
It is also said that: “A little knowledge is a dangerous thing.” Add more knowledge to identify hazards and assess the level of risk. Then reduce the level of risk.