Thunderbolt connections may provide DMA access to the host and pose a security risk. There are two mechanisms to mitigate against Thunderbolt DMA attacks in Linux, and you would probably want to verify at least one of them is active.
IOMMU DMA Protection
This uses IOMMU to explicitly allow what memory Thunderbolt devices can access via DMA. This is the prefered way to protect against Thunderbolt-based DMA attacks. It is available on recent hardware (~2018 and forward) and requires Kernel >= 5.0. You can verify IOMMU DMA Protection is enabled using:
Value of 1 means it is enabled. This setting is controlled through UEFI. At least in Lenovo systems it is named cat "Kernel DMA Protection" (like the Microsoft name for this feature). You can find it under the Security tab.
Thunderbolt protection
This is the old style of protection, that preceded IOMMU protection. If configured properly, it allows the user to explicitly authorize Thunderbolt devices before granting them DMA access.
none means no protection at all (that will also be the case if you have IOMMU DMA protection enabled). user requires the user to authorize a Thunderbolt device each time it’s connected. secure is like user but devices authorized in the past do not require re-authorization. dponly only allow DisplayPort pass-through.
Enabling HTTP/2 in nginx is quite simple. You need to add the http2 parameter to the listen 443 directive. So find the line that looks like:
listen 443 ssl;
and change it into
listen 443 ssl http2;
And reload your nginx configuration:
$ sudo systemctl reload nginx.service
Few notes:
You only need to enable http2 in one of your server blocks. You don’t need to do so for every virtual server (unless they use a different port). See here.
What is the quickest way to generate lots of random data on the command line? Usually when I had to wipe hard-drives I would simply use dd to copy from /dev/urandom over the device. However, `/dev/urandom is quite slow and wiping hard-disks can take a long time that way. So, I decided to benchmark a few methods to generate long random streams that are usable in such scenarios.
The benchmark is based on the dd command. For example:
$ dd if=/dev/urandom of=/dev/null bs=4k count=1M
This command will copy a 4GB of random bytes from /dev/urandom over /dev/null. This is probably the simplest method to create a large stream of random bytes, and as it turns out, also the slowest.
The second construct I tried is to use OpenSSL to create a stream of random data which I can read with dd and then write to the target. For example the following would use AES-128 with a random key:
Let’s breakup this command: openssl rand -hex 32 will generate a random encryption key to be used by the AES encryption. openssl enc -aes-128-ctr -in /dev/zero -pass stdin -nosalt does the actual encryption. It reads the (random) key from stdin and then uses it to encrypt /dev/zero using AES-128 in counter mode. As /dev/zero in an endless stream of zeros, it will simply output an endless stream of (pseudo-)random data. We can also repeat the same command only swapping aes-128-ctr with aes-256-ctr. For most (all?) usage scenarios it doesn’t provided any added security benefits but does have a (small) performance penalty.
Apart from AES, which is a block cipher, we can also try to use actual stream ciphers like the old rc4 and the modern chacha20.
Additionally, many new CPUs come with AES-NI extension which speeds up AES operations considerably. We can repeat the benchmark while disabling AES-NI to see how the different methods will perform if used a CPU that doesn’t support AES-NI.
Finally, I’ve repeated the test with /dev/zero as input, just to have an upper-limit in terms of performance to compare against.
Benchmark results
AES-NI
No AES-NI
/dev/zero
0.42609
/dev/urandom
18.8967
chacha20
2.69306
3.79217
aes-128-ctr
2.04106
14.9022
aes-256-ctr
2.24756
18.9014
rc4
7.77392
Benchmark results, time (in seconds) to create 4GB of random data
Conclusions
The results clearly show that you should avoid /dev/urandom. It’s simply not suitable for this task and doesn’t perform well. The various methods of using OpenSSL perform much better. The best performance is achieved by the two AES variants, with aes-128-ctr being the fastest. However, if AES-NI is not supported by the CPU, AES takes a huge performance hit, and is even slower than the (not-so-)good and old RC4. However, ChaCha20 (a modern stream cipher) performs within 30% of AES if AES-NI is available, but if AES-NI is not supported ChaCha20 outperforms the AES variants. So, unless you know AES-NI is supported ChaCha20 is the safe choice.
It looks like digiKam installed on a default Gnome environment has missing icons. For example the "pick" icons (the little flags for Rejected/Pending/Accepted) are missing. The reason is that the default Gnome icon pack, Adwaita is missing some of the icons used by digiKam.
The solution is to install the Breeze icon theme and then select it in digiKam:
$ sudo apt install breeze-icon-theme
and then in digikam Settings -> Configure digiKam -> Miscellaneous -> Appearance -> Icon theme and select "Breeze". Actually you can leave it as "Use Icon Theme From System" and it will use Adwaita and only fall back to Breeze for missing icons. However, I do find it more pleasant to have a consistent icon theme.
This short tutorial will guide you in encrypting a drive with cryptsetup and LUKS scheme.
Before starting, if the device had previous data on it, it’s best to delete any filesystem signatures that may be on it. Assuming that the drive we operate is /dev/sda you can use the following command to remove the signatures:
$ sudo wipefs --all /dev/sda --no-act
Remove the --no-act flag to actually modify the disk.
The next step is to actually format the drive using LUKS. This is done using the cryptsetup utility.
$ sudo cryptsetup luksFormat --type=luks2 /dev/sda
WARNING!
========
This will overwrite data on /dev/sda irrevocably.
Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sda:
Verify passphrase:
The command will prompt you to enter a passphrase for the encryption and should take a few seconds to complete.
The next step is to add an appropriate entry to crypttab which will simplify starting the dm-crypt mapping later. Add the following line to /etc/crypttab:
where the UUID is obtained through lsblk /dev/sda -o UUID or a similar command. The archive_crypt is the name for the mapped device. It will appear as /dev/mapper/archive_crypt when the device is mapped. The none parameter specifies that no keyfile is used and the system should prompt for an encryption passphrase instead. The noauto, means not to attempt to load the device automatically upon boot. discard should be used if the underlying device is an SSD.
You can test everything works so far by opening and loading the LUKS device:
$ sudo cryptdisks_start archive_crypt
While the device is now encrypted, there is a possible leakage of metadata such as used blocks as an attacker can discern used vs unused blocks by examining the physical drive. This and other side-channel leaks can be mitigated by simply wiping the contents of the encrypted device.
My boot process was pretty slow in a new setup I had. It would stop for about 30 seconds and then give the following error:
Gave up waiting for suspend/resume device
Turns out I had a resumable device listed in /etc/initramfs-tools/conf.d/resume even though my swap is both encrypted with random keys and too small. Editing that file and setting RESUME=none and running sudo update-initramfs -u fixed the issue.
Zoom has a native Linux client which supports screen sharing in Wayland, at least on some platforms. Today when I tried to start a Share Screen I encountered the following error:
Error when trying to start Share Screen
Can not start share, we only support Wayland on GNOME with Ubuntu 17 and above, Fedora 25 and above, Debian 9 and above, CentOS 8 and above, OpenSUSE Leap 15 and above, Oracle Linux 8 and above, Arch Linux, AnterGos, Manjaro. If your OS is not on the list, please use x11 instead.
The feature works for me when I’m using Debian Stable (Buster), and also worked for the short while I’ve used Debian Testing (Bullseye). So, I guessed that the feature is broken due to wrong OS version detection. The fix is easy: Remove /etc/os-release (which is by default a symlink to /usr/lib/os-release) and append to the original contents the following lines:
When I first encountered the error, I guessed Zoom doesn’t actually attempt the Share Screen, but relies on a pre-configured list of supported distros and (minimal) versions. It worked for me with Debian Stable (10) and Testing (11), but what version number is Unstable? Debian Unstable doesn’t have a version number associated with it, so it must be the problem.
A quick strace revealed how Zoom retrieves the current distro name and version:
As you can see Zoom reads (and probably later parses) the entire /etc/os-release file. This file contains identification data for the current running distro including name and version. Because Debian Sid doesn’t have the version variables set, Zoom erroneously misinterpret it as an old version instead of the newest. Thus, it refuses to enable the Share Screen feature. Adding the relevant version variables solves this issue.
By default, PulseAudio allows an application to change the max volume output to be louder than the one set by the user. I find it annoying that some apps tend to set volume to 100% which ends up increasing the system volume to unreasonable levels. You can prevent it by setting flat-volumes to no in ~/.config/pulse/daemon.conf.