Cobra's bits (Posts about archlinux)

Backdoor in xz

Cobra — Mon, 01 Apr 2024 11:50:12 GMT

The upstream xz repository and the xz tarballs have been backdoored.

This backdoor is very indirect and only shows up when a few known specific criteria are met. Others may be yet discovered! However, this backdoor is at least triggerable by remote unprivileged systems connecting to public SSH ports.

This supply-chain attack targets .deb- and .rpm-based distributions, but the backdoored versions of xz or xz-utils (5.6.0 and 5.6.1) have made it only into rolling-release distributions such as Fedora Rawhide, Debian Testing/Sid, OpenSuse Tumbleweed, and Archlinux (where it is inactive).

The server of this blog is running Debian Testing and had the compromised version of xz-utils installed since March 17. The backdoor was reported last Friday, March 29. I've installed the patch provided by Debian on Saturday, March 30, and examined the system logs, which do not show any evidence that the system has been compromised in any way. In fact, according to my current understanding, the system did not meet all the requirements for the backdoor to be executed. However, I will remain vigilant and let the users of the server know if further action needs to be taken.

More links (in German): Heise 30.03.2024 09:35, Heise 30.03.2024 22:28, Heise 02.04.2024 17:10

Kernel 6.6.9

Cobra — Fri, 05 Jan 2024 16:24:37 GMT

Yesterday, I've updated my systems to kernel 6.6.9 – two Intel-based desktops and one AMD-based notebook. When rebooting the latter, I immediately noticed that something was wrong. Logging in, for example, seemed to take twice as long, and the desktop needed much longer than the usual two or three seconds to come up. My Intel desktops, in contrast, behaved exactly as before.

To substantiate my feeling that my notebook's performance had degraded significantly since the update, I used sysbench, or, more precisely, the command sysbench cpu run. I would normally see a performance of about 4800 events per second on one core. But with kernel 6.6.9, all I've got were 440 events per second, more than a factor of 10 lower than the Ryzen 5800H in my notebook is supposed to deliver, and even three times lower than my 10-years old Intel desktops. No surprise the notebook felt so sluggish!

I didn't bother to investigate this issue further, and I don't know the underlying cause, like whether it's related to the AMD processor or the maker of the notebook. I just rolled back to kernel 6.6.8 (sudo pacman -U /var/cache/pacman/pkg/linux-6.6.8.arch1-1-x86_64.pkg.tar.zst) and the problem was gone.

I expected problems with kernel 6.6.6, but the devil is in the details.

Update: The performance is back to normal with kernel 6.6.10.

Virtual Arch for the VPN

Cobra — Sun, 05 Nov 2023 14:02:40 GMT

Connecting to a VPN is usually like picking up your device and tossing it into another network, figuratively speaking. All of your network activities – such as browsing, fetching private mails, chatting with a friend on IRC – will take place within this virtual network, or not at all: in its most secure configuration, access to resources on the local area network will not be possible. I thus prefer to separate my real private network activities from those in the virtual private network by using a virtual guest dedicated to nothing but connecting to the latter and doing whatever I need to do within the guest system.

In the present case, I'm fortunate that my employer now uses a gateway whose VPN client (Palo Altos's GlobalProtect) runs even on an up-to-date Arch installation. So my choice for the guest system is an out-of-the-box ArchBang that comes with i3 as (tiling) Window manager. It installs in 10 min, comes with everything I need, and fits in 5 GB of space. I spent another 5 min modifying the wallpaper and the conky instance – my idea was to have a visual indication in form of my IP whether or not I'm connected to the VPN.

After configuring everything to my liking, it turned out that I shouldn't have bothered – our IT guys configured the VPN with split tunneling enabled. This basically means that only traffic destined to the remote location passes through the encrypted tunnel, while everything else uses the standard gateway. Supposedly less secure, but certainly much more convenient. Excellent choice! I'm sure I'll find another use for my virtual Arch – be it for testing or online banking.

Don't worry, be happy

Cobra — Sat, 29 Jul 2023 13:12:40 GMT

It's Friday evening, 18:30. My fourth video meeting in a row has just concluded. Now I could finally work on the revision of a manuscript I wanted to get resubmitted during the weekend. This last revision was purely technical: the production editor requested that we move the present addresses of the authors to the back of the manuscript, instead of leaving them beneath the list of authors on the title page as destined by the LaTeX class from the publisher. Now, any such request that forces me to work around or against the journal style provided by the publisher means that the reputation of the journal (ACS Appl. Nano Mater., in case you are curious) takes a steep dive. But anyway, I had to do it, and I was looking into the footmisc package to get all footnotemarks I needed when I realized that I hadn't done my ritual update in the morning for the lack of time. Starting it, I only peripherally noticed that the update involved TeXLive and brought a new kernel. In any case, this information didn't stop me from compiling the manuscript I was working on during the update. Repeatedly. Incessantly.

At a certain point, the build command of Sublime Text didn't produce any reaction. No error message, nothing. I began to have a bad feeling. Indeed, while I could still move the mouse around, the entire Window system was unresponsive, and the update process – which was just about to build the fmt files – was hanging. I started to suspect that I had just committed the greatest blunder of this year, and indeed, when I rebooted, the system greeted me with the message that the kernel could not be found:

Loading Linux linux...
error file /boot/vmlinuz-linux not found
loading initial ramdisk
error: you need to load the kernel first

Well, I knew that this SNAFU looked worse than it actually is. But since I was suddenly very tired, I decided to call it a day and do the repair on Saturday morning.

On Saturday, I first needed a live Arch installation on a USB stick. The ISO ist just 813 MB (as of release 2023.07.01) and downloaded in 30 s. There are several options to write the ISO to the stick, but I prefer dd:

dd bs=4M if=archlinux-archlinux-2023.07.01-x86_64.iso of=/dev/sdd conv=fsync oflag=direct status=progress

Note that the stick must not be mounted, and one writes to the stick (sdd), not a partition (sdd1).

After booting from the thus created live media, I was just a few commands away from a restored system. I first wanted to have my WiFi working:

iwctl --passphrase PASSPHRASE station DEVICE connect SSID

After that, I just needed to mount my drives (have a look with lsblk before), delete the stale lock file from the previous failed update, and do an update in the mounted root directory:

mount /dev/nvme01p2 /mnt
mount /dev/nvme01p1 /mnt/boot
mount -t proc /proc /mnt/proc
mount --rbind /sys /mnt/sys
mount --rbind /dev /mnt/dev

rm /var/lib/pacman/db.lck

pacman --sysroot /mnt -Syu

Took all in all half an hour, but I would still have preferred to avoid this situation altogether. The lesson is: avoid working on the system when you're all stressed out. Particularly on Friday night.

A new VPN

Cobra — Sun, 21 May 2023 14:32:31 GMT

The institute I'm with has offered a VPN solution for its employees for about 15 years. Well, at least for the Windows users of our staff. The Cisco we've used in the first years came with the abysmal 'vpnclient', which I've said one time to be a clear winner of the worst-software-on-this-planet contest. It would run only on CentOS and Debian OldStable (meaning Sarge at that time!), and there was no way to get it running in any reliable way on a halfway modern Linux. I've thus ended up by connecting to the VPN via a virtual Windows XP, until I discovered openconnect, which worked perfectly on modern Linux distributions. Still, I was delighted when we finally kicked out the Cisco and got a Checkpoint instead, only to learn that the promised Linux client was still in development. It actually never materialized, but I was content with the browser-based solution they offered. Now the Checkpoint license has expired, and instead of renewing the contract, we've gotten ourselves a Palo Alto firewall – much to my surprise, as Palo Alto is not known for being a bargain. But in any case, we now – after 15 years – have a VPN client that can be installed on a fully updated Arch system and actually works.

Jonas, a fellow Archer and colleague of mine, figured out the best way how to install the client. I'm' adding his instructions here so I find them when the next version is released. 😄

Install the AUR package 'globalprotect-bin' (which will fail, but gets the necessary 'PKGBUILD' file and 'globalprotect.install' script).

From /software/VPN/VPN_Client_GlobalProtect get the latest version of the archive with the client binaries for Linux: 'PanGPLinux-u.v.w-...tgz'. From this archive, you only need the files 'GlobalProtect_tar-u.v.w.x-yz.tgz' and 'GlobalProtect_UI_tar-u.v.w.x-yz.tgz'.

Place the two files in the AUR build-folder, e.g. '.cache/yay/globalprotect-bin/'

Check that in PKGBUILD the correct 'pkgver' (u.v.w.x) and 'pkgrel' (yz) are set. If you need to change these, you also need to adapt the 'sha256sums'.

Run makepkg -si.

Start gpd.service using systemctl enable --now gpd.service (check status with systemctl status gpd) and restart the system.

Import the certificate (I had to use an absolute path): globalprotect import-certificate --location /home/user/...

To update the client to a new version, you need to repeat steps 2–5 and restart the system.

Now you are ready and you can

Start the connection using globalprotect connect --portal vpn.foo.bar.de

Disconnect using globalprotect disconnect

Alternatively, run the gui (which then appears in the system tray) using: globalprotect launch-ui and use the connect/disconnect button

I have little to add to these instructions. I don't recommend the GUI: it is outdated and does not work in a high-dpi environment such as my notebook. But that's fine with me; I like the CLI better anyway. Following my habits, I've just defined aliases for the two commands most frequently used:

alias vpnon='globalprotect connect --portal vpn.foo.bar.de'
alias vpnoff='globalprotect disconnect'

Perhaps I will install a minimal virtual Linux guest to run the client and to connect, while still being able to use my other connections in the host system. I'll post an update if I do that. 🤠

20th anniversary

Cobra — Thu, 17 Mar 2022 18:29:21 GMT

I've missed it by a few days, but nevertheless: the first version of Archlinux (Homer) was published 20 years ago. The German computer magazine iX published a well-deserved tribute.

It took some time for me to discover this unique Linux distribution, but when I did in 2009 (a shocking 13 years ago), I was sold. Since more than 8 years, Arch runs all my desktops and notebooks, and only servers are still powered by Debian.

To the next 20 years! And in any case: happy anniversary, happy anniversary, happy anniversary, HAPPY anniversary!

Maxi

Cobra — Sun, 26 Sep 2021 12:45:37 GMT

I've retired my veteran netbook Mini after 10 years of service and 7 generations of Debian in 2018. The SSD was becoming corrupted, and in view of its low performance and advanced age, I decided that it wouldn't be worth the time and money needed to replace it.

In the meantime, I've been using the Fujitsu Lifebook I acquired in 2011. As a matter of fact, I gradually used this low-end notebook in favor of my desktop until I was basically working exclusively with it. From March 2020, I've used it day in, day out. During this time, it became painfully obvious that the lifebook's performance is no longer adequate for my needs. About a year ago, I've thus started to look for a successor, but considering my recent change in preference, I was looking for a notebook with higher performance and display resolution, as well as a backlit keyboard.

There were several contenders, all armed with processors of the Cezanne series of AMD. But my favorite was the Ideapad 5 Pro 16 because of its comparatively large screen real estate with a WQHD resolution and 16:10 form factor. When it was offered for €899 by Lenovo in a bargain sale, I didn't hesitate to accept the offer.

The Ideapad 5 Pro 16 comes with a gun-metal grey (“storm grey”) metal case with an excellent finish. Despite its slightly larger display diagonal, it is significantly smaller, lighter, and, particularly, thinner than my Lifebook. At the same time, it leaves it light years behind in terms of performance:

Fujitsu Lifebook AH530

Lenovo IdeaPad 5 Pro 16ACH6

Processor

Intel P6200

AMD Ryzen 7 5800H

Lithography (nm)

32

7

Frequency (GHz)

2.13

3.2–4.4

L2/L3 cache (MB)

0.5/3

4/16

# cores/threads

2/2

8/16

Weight (kg)

2.5

1.9

Display (inch)

15.6 (1366×768)

16 (2560×1600)

RAM (GB)

4 (DDR3-1066)

16 (DDR4-3200)

Mass storage (GB)

500 (SATA HDD)

1000 (PCIe SSD)

TDP (W)

35

45

Battery life (h)

3

8

iperf (Mbit/s)

40

360

Cinebench R23

336/641

1445/12969

hdparm -t (MB/s)

70

2300

Price (€)

299

899

	Fujitsu Lifebook AH530	Lenovo IdeaPad 5 Pro 16ACH6
Processor	Intel P6200	AMD Ryzen 7 5800H
Lithography (nm)	32	7
Frequency (GHz)	2.13	3.2–4.4
L2/L3 cache (MB)	0.5/3	4/16
# cores/threads	2/2	8/16
Weight (kg)	2.5	1.9
Display (inch)	15.6 (1366×768)	16 (2560×1600)
RAM (GB)	4 (DDR3-1066)	16 (DDR4-3200)
Mass storage (GB)	500 (SATA HDD)	1000 (PCIe SSD)
TDP (W)	35	45
Battery life (h)	3	8
iperf (Mbit/s)	40	360
Cinebench R23	336/641	1445/12969
hdparm -t (MB/s)	70	2300
Price (€)	299	899

For comparison, my 9 years old desktop achieves 820/3650 points in the Cinebench R23 single/multi benchmark, and Dell's 17″ high-end notebook XPS 17 in a comparable configuration (processor graphics, 16 GB RAM, 1 TB SSD, 2.2 kg) with an Intel® Core™ i5-11400H for €2098.99 (1920×1200 non-glare) or €2398.99 (3840×2400 glare) scores 1467/9017 points according to c't 21/2021.

There wasn't any question about the Linux distribution I would install on the Ideapad (Arch, of course), but I debated with myself whether I should install a desktop or stay with Openbox as on all my other systems. In view of the medium-high display resolution of 189 ppi, I finally settled for Budgie, a Gnome-based desktop known for its gracious handling of high-dpi displays. And so far I like what I see: the desktop has an unobtrusive, rational, and no-nonsense quality about it.

The Ideapad is officially specified to have an Intel AX200 wifi chip, which works perfectly under Linux. But I had been warned by posts in the interwebs that it may instead be delivered with a Realtek RTL8852AE chipset, which is not yet supported. And that's what happened of course also in my case. I thus installed over a LAN connection (using an USB/ethernet adapter) and installed the driver for the 8852 provided on the AUR right after. The driver works fine except when the notebook goes into hibernation, after which there's no wifi device any more – it simply vanishes. I haven't found a solution for this inconvenience, but hope that the official support of the rtw89 driver by the mainline kernel will solve this issue, and will hopefully materialize with Linux 5.15. Alternatively, I could replace the wifi module as others have done.

Other than that, everything works as intended, and lightning fast.😂 Oh, I've replaced pulseaudio by pipewire-pulse to use my bluetooth headset, which would otherwise be without microphone. And I've installed rofi, which I still prefer as a program launcher over anything a desktop can offer...

I can haz IP?

Cobra — Sat, 22 May 2021 16:31:40 GMT

I have the strange habit to look up my external IP and to display it in the conky instance on my desktop (see here for an example). So far, I've got this IP directly from my Fritz!Box 7170, but the command I've used doesn't work with the new box (a 7590). I thus had to find a new way to get my IP.

There are plenty of websites returning the IP upon a simple connection by curl:

curl icanhazip.com
curl ifconfig.me
curl ipecho.net/plain
curl ifconfig.co
curl ipinfo.io/ip
curl -s checkip.dyndns.org | sed -r 's#(.*: )([0-9.]*)(<.*)#\2#'

There's also at least one DNS server offering this service:

dig +short myip.opendns.com @resolver1.opendns.com

But I would very much prefer a local solution as before. And it turns out that this solution exists: The package miniupnpc “enables applications to access the services provided by an UPnP ‘Internet Gateway Device’ present on the network. In UPnP terminology, MiniUPnPc is a UPnP Control Point.”

This package contains a command that retrieves the external IP from current Fritz!Boxes:

cobra at blackvelvet in ~
↪ external-ip
85.212.90.227

Bingo!

Better annotations

Cobra — Mon, 29 Mar 2021 15:57:52 GMT

A significant part of my daily work consists of critically reading drafts of publications or project proposals. I usually place hand-written comments on a printout of the respective document and discuss them with the author in my office, but that isn't such a good idea in the time of SARS-CoV-2. We hold these discussions now in video meetings, with the document in question being looked at together by sharing someones screen showing an annotated pdf. Now, I'm using evince to annotate pdfs, and didn't like the fact that all annotations seem to come from ‘Unknown’. In principle, that can be changed by editing the author in the annotation's properties, but I certainly would not have enjoyed doing that for each of the 80+ comments I had made for the present manuscript.

Alas, the official help told me that setting a different default author would not be possible. And that seemed final, since it came from the most authoritative source – the developers themselves. But I finally found a surprisingly simple solution in the place where, at this time, I had expected it least: the ArchWiki.. Shouldn't the developers know that evince looks into /etc/passwd? In any case, a simple

usermod -c “Deus ex machina” cobra

ensured that my comments would be now easily distinguishable from those of the other coauthors.

Missing my notifications

Cobra — Sat, 17 Oct 2020 12:43:50 GMT

It took quite some time until I realized that I don't get notifications anymore on any of my Arch-based installations, but when aarchup didn't chime up even after days, I've finally noticed that there must be something wrong.

The culprit is the new autostart file coming with xfce4-notifyd 0.6.2:

[Desktop Entry]
Type=Application
Name=Xfce Notification Daemon
Exec=/usr/lib/xfce4/notifyd/xfce4-notifyd
Icon=org.xfce.notification
OnlyShowIn=XFCE;

Only show in XFCE? As OpenBox user, I feel seriously excluded and discriminated. Well, actually, we can just delete this line in a user context and thus continue as before:

cp /etc/xdg/autostart/xfce4-notifyd.desktop /home/cobra/.config/autostart/
vim /home/cobra/.config/autostart/xfce4-notifyd.desktop
G dd ZZ

😉