jntesteves

joined 1 year ago
 

PSA: Bluetooth vulnerability and PS3 Controllers on Linux in 2024

In late 2023 a Bluetooth vulnerability CVE-2023-45866 was discovered and patched in Bluez. By now, this vulnerability should be fixed on all Linux distributions. The fix has one compatibility implication: support for insecure legacy devices is now disabled by default. The Sony PlayStation 3 Controller (AKA DualShock 3 or DS3) is probably the most notable device affected by this change.

What to do if you have a PS3 Controller

The PS3 Controller should still be plug-and-play on Linux when used wired, this change only affects wireless use.

Wireless use is now disabled by default. It should still be possible to use the controller wirelessly with a configuration change, but that will make your PC vulnerable when Bluetooth is in discoverable mode — that's when you're pairing a device; in GNOME that's when you just have the Bluetooth settings open; easy to have on by accident.

It's painful for me to say this (I own several PS3 Controllers), but the DS3 is reaching its end-of-life, and we should start to consider moving on from it as a gamepad for PC.

How to re-enable Bluetooth support for the PS3 Controller

This is insecure: It will make your PC an easy target for remote code execution attacks from anyone in close proximity whenever your Bluetooth is in pairing/discoverable mode. It's usually hard to notice when Bluetooth is in discoverable mode, and it's very easy to accidentally leave it on. You have been warned.

TL;DR: The following commands should do it, tested on Fedora 39:

sudo sed -Ei~ -e 's/^#ClassicBondedOnly=.*/ClassicBondedOnly=false/' /etc/bluetooth/input.conf
sudo systemctl restart bluetooth

Long version: Use the configuration file at /etc/bluetooth/input.conf, under the [General] section, add the option ClassicBondedOnly=false, then restart the bluetooth service or reboot the computer. Your config file should look like the following:

# Configuration file for the input service

# This section contains options which are not specific to any
# particular interface
[General]

# Set idle timeout (in minutes) before the connection will
# be disconnect (defaults to 0 for no timeout)
#IdleTimeout=30

# Enable HID protocol handling in userspace input profile
# Defaults to false (HIDP handled in HIDP kernel module)
#UserspaceHID=true

# Limit HID connections to bonded devices
# The HID Profile does not specify that devices must be bonded, however some
# platforms may want to make sure that input connections only come from bonded
# device connections. Several older mice have been known for not supporting
# pairing/encryption.
# Defaults to true for security.
ClassicBondedOnly=false

# LE upgrade security
# Enables upgrades of security automatically if required.
# Defaults to true to maximize device compatibility.
#LEAutoSecurity=true

I'm posting this PSA on [email protected] and [email protected]. Please forward this message to other interested Linux communities.

 

With PIpeWire hitting its 1.0 release we speak with project lead Wim Taymans about what has been achieved and where we go from here.

[–] [email protected] 4 points 9 months ago (1 children)

SELinux in Podman works pretty much the same way it works on Docker, so if you are having problems with Podman, you should also be having problems with Docker, so I don't see how that's impeding your migration. You need to be more specific about the issues you're having to get a good answer.

The post by Chris Smart you linked on your comment below is a good start, but everything there also applies to Docker, so if you still didn't know those basics, you shouldn't be able to use Docker on Fedora either.

About your question of how to set it up, use-case is an important consideration, there is no generic answer that covers all use-cases. I've even found out that for some use-cases (like ad-hoc containers), disabling SELinux within the container (with --security-opt=label=disable) seems to be the most secure option. That's what I've done in contr (see this commit message). I've been meaning to blog about that, but never did because I'm in the process of migrating my blog but too lazy to finish it.

I've put a lot of links about SELinux in containers in this issue.

[–] [email protected] 5 points 10 months ago (1 children)

Although that link exists, that's not what is being used by default. [[ is a shell builtin in ash/busybox, so that takes precedence.

On Alpine:

❯ which [[
/usr/bin/[[

❯ command -V [[
[[ is a shell builtin
[–] [email protected] 2 points 11 months ago (1 children)

gog galaxy through wine is not an option...

That's the primary way I install and play GOG games. It's easy to set up using Bottles. Galaxy used to run horribly on Wine, but it has improved recently. I help maintain the Galaxy installer in Bottles, and earlier this year we increased its grade from silver to gold, meaning all functions work with minimal glitches now.

It isn't perfect yet, it lags for about a minute right after launch, and I'd recommend going into settings and disabling the "Cloud saves" and "Overlay" features as these can cause crashes sometimes. Other than that, everything works well and performance is good.

[–] [email protected] 1 points 1 year ago* (last edited 11 months ago) (1 children)

Here's the update, I've got the USB-C/HDMI adapter today. Connected it to the port that connects directly to the dGPU and even during boot Plymouth was already outputting video to the TV. I also tested hot-plugging and it just works as expected.

Now for the problems, I ran benchmarks and the performance was as expected, but frame delivery didn't look as good as when using the HDMI port on this device. It doesn't show on the performance metrics, but looking at the screen, the frametimes looked off, stuttering. I'm still figuring out where the issue might be to report it to upstream. EDIT: For people reading this in the future, I've found the issue to be in GNOME's compositor, Mutter: https://gitlab.gnome.org/GNOME/mutter/-/issues/3070#note_1865351

[–] [email protected] 1 points 1 year ago

I hear you, I have a Legion laptop with a GTX 1060 mobile and I keep the dGPU as primary all the time because I just can't be bothered by NVIDIA optimus anymore. That's the reason I decided to upgrade to AMD, even though the performance of the 1060 was still appropriate for me and I wouldn't have upgraded yet otherwise.

I don't have any issues with the Strix G15 on Fedora Silverblue. Talking to other owners of the same model and also other Asus AMD laptops on Reddit, I didn't hear any complaints about that.

The G15 has the HDMI port connected to the iGPU, and the USB-C (DisplayPort Alt Mode) connected directly to the dGPU. I've only used HDMI to connect to a TV, I haven't tested the USB-C output because I don't have a monitor with DisplayPort. So I can't really answer your question.

Tell you what, I've just ordered a USB-C to HDMI adapter, as soon as it arrives I'll test the output that's connected directly to the dGPU and update you on that. I'd bet on it being plug-and-play, but we'll see. 😉

[–] [email protected] 5 points 1 year ago (4 children)

You shouldn't generalize your bad experience with NVIDIA's proprietary driver to Mesa. Graphics device switching just works on Mesa, hence laptops with an AMD dGPU are great on Linux.

Typing this from a 2021 Asus ROG Strix G15 Advantage Edition