Bullseye Security

0 views
Skip to first unread message

Fairy Dawdy

unread,
Aug 3, 2024, 10:50:16 AM8/3/24
to fooranseci

[update]: This post initially noted 'buster', when it should have been 'bullseye'. I've updated it by changing all instances of 'buster' to be 'bullseye'. Note also that the Debian security repo format has changed since buster!

First up, you can use TKLBAM locally as well. Although it still will require you to sign up to the Hub to get the backup profile (or generate a profile yourself). But as Hub signup still requires an AWS account, you'll likely prefer not going that path.

As for a "Debian style upgrade", yes that's a totally legitimate path to follow. It sounds like you were heading in the right direction, however, you will need to also update the TurnKey repo keys (as per the error you noted).

The keys can be downloaded from keyservers, but in recent times, they're a bit broken, so it's probably easier to just pull them from GitHub. The easiest way is to update them would be via the commandline. Here's a script that you can copy/paste. It will download and convert the keys to the required format for all 3 repos (if you warn't using 'testing', downloading the key won't cause any issue):

Then the only other thing you should need to do is update the TurnKey repo key paths in the relevant sources.list files (/etc/apt/sources.list.d/security.sources.list & /etc/apt/sources.list.d/sources.list). E.g. your security soruces file contents should look like this:

But you can run it from a script too if you want. Judging from the fact that the script is erroring at the bashism on line 4, my guess is that it's guessing from the filename and just running with /bin/sh (not /bin/bash). If you want to run it as a script it needs to be explicitly run by bash. You could just run it with bash, like this:

Having said that, your work around looks fine to me (and not really any worse than mine...). So thanks tons for sharing. Having an alternate path documented is a bonus for anyone else that hits the same issue.

There are probably more .list files in the folder /etc/apt/sources.list.d, with entries that still point to the buster repos. Change these entries from buster to bullseye and run sudo apt update && sudo apt dist-upgrade

Or this should also work as far as I understand it: The value 'bullseye-security' is invalid for APT::Default-Release as such a release is not available in the sources Issue #1437 nextcloud/nextcloudpi GitHub

For Intel GPUs available with Broadwell and newer, the Video AccelerationAPI (VA-API) implementation now defaults tointel-media-va-driver for hardwareaccelerated video decoding. Systems which haveva-driver-all installed willautomatically be upgraded to the new driver.

The legacy driver package i965-va-driveris still available and offers support up to the Cannon Lake microarchitecture. To prefer the legacy driver over the new default one, setthe environment variable LIBVA_DRIVER_NAME toi965, for instance by setting the variable in/etc/environment. For more information, please seethe Wiki's page onhardwarevideo acceleration.

Support for the barrier andnobarrier mount options has been removed fromthe XFS file system. It is recommended to check/etc/fstab for the presence of eitherkeyword and remove it. Partitions using these options will failto mount.

If your APT configuration also involves pinning or APT::Default-Release, it is likely to require adjustments as the codename of the security archive no longer matches that of the regular archive. An example of a working APT::Default-Release line for bullseye looks like:

The default password hash for local system accounts has been changed from SHA-512 to yescrypt (seecrypt(5)). This is expected to provide improvedsecurity against dictionary-based password guessing attacks,in terms of both the space and time complexity of the attack.

Yescrypt is not supported by Debian 10 (buster). As a result,shadow password files (/etc/shadow) cannot becopied from a bullseye system back to a buster system. If thesefiles are copied, passwords that have been changed on the bullseyesystem will not work on the buster system. Similarly, passwordhashes cannot be cut&pasted from a bullseye to a buster system.

The DNS resolver unboundhas changed the way it handles configuration file fragments. Ifyou are relying on an include: directive tomerge several fragments into a valid configuration, you shouldread theNEWS file.

The rsync parameter--noatime has been renamed--open-noatime. The old form is no longersupported; if you are using it you should see theNEWS file. Transfer processes between systems running differentDebian releases may require the buster side to be upgraded to a versionof rsync from the backportsrepository. The version of rsync in the initial release ofbullseye also deprecated --copy-devices infavor of --write-devices, but version3.2.3-4+deb11u1 (included in bullseye point release 11.1)reverts this deprecation and supports both options.

Following upstream's recommendations, OpenStack Victoria as released in bullseye switches the OpenStack API to use the new YAML format. As a result, most OpenStack services, including Nova, Glance, and Keystone, appear broken with all of the API policies written explicitly in the policy.json files. Therefore, packages now come with a folder /etc/PROJECT/policy.d containing a file 00_default_policy.yaml, with all of the policies commented out by default.

To avoid the old policy.json file staying active, the Debian OpenStack packages now rename that file as disabled.policy.json.old. In some cases where nothing better could be done in time for the release the policy.json is even simply deleted. So before upgrading, it is strongly advised to back up the policy.json files of your deployments.

From Linux 5.10, all users are allowed to create user namespaces by default. This will allow programs such as web browsers and container managers to create more restricted sandboxes for untrusted or less-trusted code, without the need to run as root or to use a setuid-root helper.

The previous Debian default was to restrict this feature to processes running as root, because it exposed more security issues in the kernel. However, as the implementation of this feature has matured, we are now confident that the risk of enabling it is outweighed by the security benefits it provides.

From Linux 5.10, Debian disables unprivileged calls to bpf() by default. However, an admin can still change this setting later on, if needed, by writing 0 or 1 to the kernel.unprivileged_bpf_disabled sysctl.

The package redmine is not provided in bullseye, as it was too late migrating over from the old version of rails which is at the end of upstream support (receiving fixes for severe security bugs only) to the version which is in bullseye. The Ruby Extras Maintainers are following upstream closely and will be releasing a version via backports as soon as it is released and they have working packages. If you can't wait for this to happen before upgrading, you can use a VM or container running buster to isolate this specific application.

Please consider the version of Exim in bullseye a major Exim upgrade. It introduces the concept of tainted data read from untrusted sources, like e.g. message sender or recipient. This tainted data (e.g. $local_part or $domain) cannot be used among other things as a file or directory name or command name.

This will break configurations which are not updated accordingly. Old Debian Exim configuration files also will not work unmodified; the new configuration needs to be installed with local modifications merged in.

to the Exim configuration (e.g. to /etc/exim4/exim4.conf.localmacros) before upgrading and check the logfile for taint warnings. This is a temporary workaround which is already marked for removal on introduction.

Due to changes in the Linux kernel, the probing of SCSI devices is no longer deterministic. This could be an issue for installations that rely on the disk probing order. Two possible alternatives using links in /dev/disk/by-path or a udev rule are suggested in this mailing list post.

The network protocol of versions 1 and 2 of rdiff-backup are incompatible. This means that you must be running the same version (either 1 or 2) of rdiff-backup locally and remotely. Since buster ships version 1.2.8 and bullseye ships version 2.0.5, upgrading only the local system or only the remote system from buster to bullseye will break rdiff-backup runs between the two.

Version 2.0.5 of rdiff-backup is available in the buster-backports archive, see backports. This enables users to first upgrade only the rdiff-backup package on their buster systems, and then independently upgrade systems to bullseye at their convenience.

The intel-microcode package currently in bullseye and buster-security (see DSA-4934-1) is known to contain two significant bugs. For some CoffeeLake CPUs this update may break network interfaces that use firmware-iwlwifi, and for some Skylake R0/D0 CPUs on systems using a very outdated firmware/BIOS, the system may hang on boot.

If you held back the update from DSA-4934-1 due to either of these issues, or do not have the security archive enabled, be aware that upgrading to the intel-microcode package in bullseye may cause your system to hang on boot or break iwlwifi. In that case, you can recover by disabling microcode loading on boot; see the instructions in the DSA, which are also in the intel-microcode README.Debian.

Packages that depend on libgc1c2 in buster (e.g. guile-2.2-libs) may be held back during the first full upgrade run to bullseye. Doing a second upgrade normally solves the issue. The background of the issue can be found in bug #988963.

The fail2ban package can be configured to send out e-mail notifications. It does that using mail, which is provided by multiple packages in Debian. A security update (needed on systems that use mail from mailutils) just before the release of bullseye broke this functionality for systems that have mail provided by bsd-mailx. Users of fail2ban in combination with bsd-mailx who wish fail2ban to send out e-mail should either switch to a different provider for mail or manually unapply the upstream commit (which inserted the string "-E 'set escape'" in multiple places under /etc/fail2ban/action.d/).

c80f0f1006
Reply all
Reply to author
Forward
0 new messages