Well, it seems I got my blog back online just in time to write about security vulnerabilities. Well, let’s call it a security weakness in Calamares and the initramfs tools in a lot of distributions.
Two CVE’s were files against Calamares this week, but I’ll only write about lax file permissions on initramfs images here. See the CVE database for more details.
The issue comes down to this: when creating an initramfs (which is done as root), a sensitive file is read. The initramfs file (a cpio archive) is created with lax permissions, and so any user who can read the initramfs file can then extract the contents of the sensitive file.
From the point of view of Calamares, the solution is to make sure that the initramfs is created with less lax file permissions. Simple, hey?
In principle, the umask is responsible for masking out file permissions bits, so a umask of 077 (octal!) would prevent group and other users (i.e. all the non-privileged users) from reading the initramfs. So all Calamares needs to do is set up a good umask before calling the tools, right?
If only it were that simple.
There’s a lot of distro’s out there. Calamares serves them without discriminating on toolset, language, or target audience. I’m really happy to have downstreams that write careful bug reports, who join on IRC to describe problems, who coach users about reporting problems. But there’s a lot of them, and there’s lots of different tools used to create initramfs out there.
Here are the tools I know about:
- dracut (Fedora derivatives) doesn’t seem to be vulnerable, it has had a safer umask since 2012 (with a CVE and fix for a special case in 2016). So dracut does the right thing, always: sets umask 077 and the initramfs is not world-readable.
- update-initramfs (Debian derivatives) has a
configuration item for
the umask in
initramfs.conf, but this isn’t set in the Calamares-using Debian derivatives I looked at. Setting umask in the environment has no effect, because the tool actively resets the umask, to a lax value unless configured otherwise.
- mkinitcpio (Arch derivatives) doesn’t seem to have anything at hand. It obeys umask, but only when the initramfs file doesn’t exist yet; it does not reset file permissions on an overwritten file.
Personally I feel the tools need to be fixed.
Debian derivatives should install an
Users of mkinitcpio should make sure the umask is set right
when generating the initramfs for the first time.
But what I think, personally, doesn’t directly affect distro’s, so Calamares is getting another (security-oriented) release today, with the following changes which are very unusual for an installer that doesn’t have many opinions:
- Distro’s that use the initramfs module in Calamares will get a
configuration snippet that sets
- Distro’s that use the initcpio module in Calamares will get all their initramfs’es set to safe permissions during installation.
After installation there’s not much I can do; those that have a safer configuration snippet will keep using it, while mkinitcpio users are dependent on having a safe umask when a kernel update happens.
These distro’s have a very very different approach to a Live CD and what ends up installed; Chakra gives you a full and wonderful KDE Plasma experience with all the bells and whistles (and latte dock too). ArcoLinux gives you a minimal XFCE-based Live experience, even as it installs a KDE Plasma environment to your hard disk. Lubuntu is fast and light-weight but I notice it’s not-Plasma all the time because I have so many KDE Plasma shortcuts in my muscle memory. So it’s a nice place to visit, but I wouldn’t want to live there.
I can heartily recommend some distro-shopping every now and then.
.. and after that I can get back to KDE-on-FreeBSD.
Look for a new Calamares release friday the 5th, with fixes, but it will take a while for that to get through to distro’s.