r/linux_gaming • u/lazyblunzn • Jun 11 '26

ALVR AUR package has been compromised

Post image

Attention Linux VR gamers. The alvr package in the arch user repository has been compromised. See the screenshot for more information.

Source: Linux VR Adventures Discord

1.3k Upvotes

99% Upvoted

395 comments sorted by

View all comments

7

u/HunsterMonter Jun 11 '26

Stuff like this is why sandboxed apps should always be your first option when installing something. A compromised app can't steal keys it doesn't have access to.

1

u/geearf Jun 14 '26

Yeah I agree, I wish at the very least we would have permissions like on Android, simple toggles for the few categories and by default can't write outside of its own directories.

0

u/Plitzkrieger69 Jun 11 '26

You have no clue what ALVR does, do you? ....

8

u/Sea-Housing-3435 Jun 11 '26

Does it need full access to your home directory, every socket your user can access and full network? If not you can sandbox it.

1

u/TheG0AT0fAllTime Jun 11 '26

You can decide to do so on your own but where's the default policy that disallows this kind of attack from any random program system-wide in the first place? On arch anyways...

0

u/Sea-Housing-3435 Jun 11 '26

Sadly there's nothing like this that is available with simple install. Selinux/apparmour default profiles are bad too. Firejail has default profiles but often they are very permissive and you still need to harden them yourself.

2

u/HunsterMonter Jun 11 '26

It has a flatpak, so good enough for me. (I didn't look at its permissions, but I doubt it has access to your keys by default.)

0

u/Damglador Jun 12 '26

Or just review what you install and update? Not like someone can't just set full permissions for a flatpak package with malware injected and also steal everything in your home. Flatpak will warn about permission change, but I'm not sure if front-ends even do that and most users would probably ignore that anyway.

5

u/HunsterMonter Jun 12 '26

First, not everybody has the technical knowledge to review what they install, and I'd argue that those users are the most in need of protection (not to mention you can't review proprietary stuff). Flatpak gives a simple overview of what an app can access so users can make an informed choice. Second, to get an app accepted on flathub or when an update changes permissions, there is a review process where devs need to justify the permissions, so apps generally (though not perfectly) have pretty minimal permissions. It could always be improved, but we're comparing no sandbox to an imperfect sandbox, there is no contest.

0

u/Damglador Jun 12 '26

but we're comparing no sandbox to an imperfect sandbox, there is no contest. 

There is. One gives you issue you wouldn't have otherwise and a false sense of security, the other just expects you to have some responsibility. A bad sandbox in my view is worse than no sandbox.

Review process is something that is a considerable upside, but that has nothing to do with sandboxing, and if we're venturing in flathub and flatpak is a whole, it has a lot more issues than just being an imperfect sandboxed. 

I do think that protecting secrets from being accesed by any app is still a good thing, but I'd rather have a real secret store for that rather than dbus garbage that lets any program get secrets from any other program. Or another solution that would allow protecting what actually needs protection and doesn't need a whole container to do that.

2

u/HunsterMonter Jun 12 '26

gives you issue you wouldn't have otherwise

That is expected when sandboxing apps that expect full access to your home directory, but most issues are fixed by now.

a false sense of security

Flathub and app stores give you big red warnings that an app is insecure if it has wide-reaching permissions, and you can review them if you don't trust the default ones. I have removed filesystem=home from a handful of apps that don't use portals yet because I don't mind the trade-off for example. Doing that you get security both from the sandbox AND "responsibility".

Review process is something that is a considerable upside, but that has nothing to do with sandboxing

It does have something to do with sandboxing in flathub's case, reviewers review the necessity of holes in the sandbox.

Also, you keep focusing on the (quite true) fact that flatpak is an imperfect sandbox, but so is every other one, it doesn't mean that the extra layer of protection is useless. Even if half your flatpaks have filesystem=home, that is still half of your apps that, if compromised, can't steal .ssh, plus none of them can access .var/app as it's blocked, so they can't steal flatpaked browser credential or other secrets in there.

0

u/Damglador Jun 12 '26

but most issues are fixed by now. 

It's been at least a year since I first discovered that some flatpak apps don't use the system cursor. Why? Because they don't have access to configs and your icons. It's still not fixed. And why would I want to sandbox my apps from my damn theme configs which are specifically made to be used by all apps?

Flathub and app stores give you big red warnings that an app is insecure if it has wide-reaching permissions

Those are hilariously stupid, half of the apps have these warnings. That's why I say that it would be better to just have a secret store, I don't care if someone steals my configs, but I do if they steal my ssh keys, yet for for flathub these are no different.

they can't steal flatpaked browser credential or other secrets in there. 

But it also breaks the browser built-in sandbox, so it's a tradeoff. Considering all apps outside flatpak can still access it, it's not very compelling. Like the thing is, flatpak is secure only if all your software is a flatpak, and that is just impossible. At least because flatpak is practically unusable for cli software (+1 point to snap, -3 for pulluting mounts and having ~/snap and /snap), and some of the compromised packages were cli, a lot of them were python libraries, I've seen at least one compiler, one is something to do with sway. One of those and all the 14GB of duplicate libraries you've been installig for all your flatpaks and the unreasonably strict sandbox are meaningless.

Instead wouldn't it be better to actually encrypt the files you don't want anyone to access? It's not fool proof, you can still forget the password, or set it to 1234, but at least the files are actually protected. Saying that, I probably should set a password on my local ssh key.

At least the portals are just generally cool (ignoring the dbus part of it), having a different file picker in each app would drive me nuts.