I was just wondering what would happen if I downloaded a game that was infected by a computer virus and ran it in Linux using Proton.
Has this happened to anyone? How would the virus behave? What files, connections or devices would it have access to? Could it be as damaging as running in in Windows?
Proton isn’t designed to be a security layer and afaik doesn’t go out of its way to sandbox applications. I’d expect a lot of viruses will fail to do anything, but there’ll also be some able to do things like steal your browser or discord passwords.
There’s no reason to risk it; don’t run anything in Proton that you don’t feel safe running on Windows.
Depends on what the virus is built to do.
I read someone intentionally infected their Linux system with a Windows virus, and they lost the home directory.
I was just wondering what would happen if I downloaded a game that was infected by a computer virus and ran it in Linux using Proton.
Depends on the mechanism. Some viruses will target stuff that WINE doesn’t emulate – like, if it tries to fiddle with Windows system files, it’s just not going to work. But, sure, a Windows executable could look for and infect other Widows executables.
Has this happened to anyone?
I don’t know specifically about viruses or on Proton. But there has been Windows malware that works under WINE. Certainly it’s technically possible.
How would the virus behave?
Depends entirely on the virus in question. Can’t give a generic answer to that.
What files, connections or devices would it have access to?
WINE itself doesn’t isolate things (which probably is reasonable, given that it’s a huge, often-changing system and not the best place to enforce security restrictions). On a typical Linux box, anything that you, as a user, would, since Linux user-level restrictions would be the main place where security restrictions would come into play.
I do think that there’s a not-unreasonable argument that Valve should default to having games – not just Proton stuff – run in some kind of isolation by default. Basically, games generally are gonna need 3d access, and some are gonna need access to specialized input devices. But Steam games mostly don’t need general access to your system. But as things stand, Steam doesn’t do any kind of isolation either.
You can isolate Steam as a whole – you can look at installing Steam via flatpak, for one popular option. I don’t use flatpaks, so I’m not terribly familiar with the system, but I understand that those isolate the filesystem that Steam and its games have access to. That being said, it doesn’t isolate games from each other, or from Steam (e.g. I can imagine a Steam-credentials-stealing piece of malware making it into the Steam Workshop). On the other hand, I’m not totally sure how much I’d trust Valve to do a solid job of having the Steam API be really hardened against a malicious game anyway – that’s not easy – so maybe isolating Steam too is a good idea.
Could it be as damaging as running in in Windows?
Sure. If it’s not Linux-aware, it probably isn’t going to do anything worse than deleting all the files that your user has access to, but in general, that’d be about as bad anyway. If it is Linux-aware, it could probably do something like intercept your password next time you invoke sudo, then make use of it to act as root and do anything.
Ah see I didn’t think of the flatpak aspect. But if you download a game from some shady source and want to run it via flatpak Steam, how would you go about it?
I only use Steam as a regular deb install.
Yeah, I use Steam as a deb too.
I haven’t done it, but as long as Steam itself is isolated – as I expect flatpak Steam is – anything it launches will be too, and you can add arbitrary binaries. AFAIK, that works with Windows binaries in Proton.
https://help.steampowered.com/en/faqs/view/4B8B-9697-2338-40EC.
Referring to your response to dillekant, I’m not sure how much Steam buys you in terms of security, though, unless you’re buying from Valve. The flatpak might provide some isolation by virtue of being flatpak (though I dunno how many permissions the Steam flatpak is granted…I assume that at bare minimum, it has to grant games access to stuff like your microphone to let VoIP chat work).
https://docs.flatpak.org/en/latest/sandbox-permissions.html
Steam, itself as of today, doesn’t provide isolation, at all.
Adding a non-Steam game to Steam lets you launch from Steam, which might be convenient. Maybe use Proton, which has a few compatibility patches.
If I wanted to run an untrusted Windows binary game today on my Linux box, if it needs 3d acceleration, I don’t have a great answer. If it doesn’t, then running it in a Windows VM with qemu is probably what I’d do – I keep a “throwaway” VM for exactly that. It has read access to a shared directory, and write access to a “dropbox” directory. I wouldn’t bring Steam into the picture at all. I don’t want it near my Steam credentials (Steam credentials have been a target of malware in the part) or a big software package like Steam that may-or-may-not have been well-hardened.
It does get network access to my internal network – I haven’t set up an outbound firewall on the bridge, so a hostile binary could get whatever unauthenticated access it could get from my LAN. And it could use my Internet connection, maybe participate in a DDoS of someone or such. But it doesn’t otherwise have access to the system. It isn’t per-app isolation, but if the VM vanished today, it wouldn’t be a problem – there’s nothing sensitive on it. It doesn’t know my name. It can’t talk to my hardware, outside of what’s virtualized. It doesn’t have access to my data. There are no credentials that enter that VM. Unless qemu itself has security holes, software in the thing is limited to the VM.
I have used firejail to sandbox some Linux-native apps, but while it’s a neat hack, and has a lot of handy tools to isolate software, I have a hard time recommending it as a general solution for untrusted binaries. I don’t know how viable it is to use with WINE, which it sounds like is what you want. It has a lot of “default insecure” behavior, where you need to blacklist a program for access to a resource, rather than whitelisting it. From a security standpoint I’d much rather have something more like Android, where firejail starts a new app with no permissions, warns me if it’s trying to use a resource (network, graphical environment certain directories) and asks me if I want to whitelist that access. It requires some technical and security familiarity to use. I think the most-useful thing I’ve used it for is that it mostly can isolate Ren’Py games, cut network access, disk write access, and a number of games (though not all; arbitrary Python libraries can be bundled) can work with a reasonably-generic restrictive firejail renpy profile. It just requires too much fiddling and knowledge to be a general solution for all users, and “default insecure” is trouble, IMHO.
I do wish that there was some kind of reliable, no-fiddling, lighter-weight per-game isolation available for both Windows binaries and Linux binaries out-of-box. Like, that Joe User can use and I could recommend.
I did see something the other day when reading about an unrelated Proxmox issue, talking about Nvidia apparently having some kind of GPU virtualization support. And searching, it looks like AMD has some kind of “multiuser GPU” thing that they’re billing. I don’t know how hardened either’s drivers are, but running VMs with 3d games may have become more practical since last I looked.
EDIT: Hmm, yeah, sounds like QEMU does have some kind of GPU virtualization these days:
https://ubuntu.com/server/docs/gpu-virtualization-with-qemu-kvm
Need native performance, but multiple guests per card: Like with PCI passthrough, but using mediated devices to shard a card on the host into multiple devices, then passing those:
-display gtk,gl=on -device vfio-pci,sysfsdev=/sys/bus/pci/devices/0000:00:02.0/4dd511f6-ec08-11e8-b839-2f163ddee3b3,display=on,rombar=0
You can read more about vGPU at kraxel and Ubuntu GPU mdev evaluation. The sharding of the cards is driver-specific and therefore will differ per manufacturer – Intel, Nvidia, or AMD.
I haven’t looked into that before, though. Dunno what, if any, issues there are.
EDIT2: Okay, I am sorry. I am apparently about four years out of date on Steam. Steam didn’t have any form of isolation, but apparently in late 2020, they added Pressure Vessel, some form of lxc-based per-game containerization.
I don’t know what it isolates, though. I may need to poke more at that. Pretty sure that it doesn’t block network access, and I dunno what state the container gets access to.
If you don’t use steam because it’s a shady source, I guess Bottles would be your go-to. I think parent is talking about if you bought a game off steam.
No no, I mean if someone downloads an infected pirated game from some shady website. I consider Steam to be very secure.
Linux is not really comparable like this because the distribution matters along with the bootloader configuration.
If you have an immutable distro with SELinux configured and your own UEFI keys or a shim with secure boot, you’ll have a very different set of vulnerabilities from someone running Mint with secure boot turned off.
For a short time Microsoft marketed an upgrade path the a full Unix like operating system for Windows. It was widely known that some of the Windows shell differences from Unix were just arbitrary aliases for the Unix commands.
If you ever get the chance, try using an old Android device you do not use, enable the developer options for the ADB bridge and try hacking around, if you have an interest in understanding how Linux security works in practice when it is done right. The Linux side of Android is an interesting case study if you understand the premises of Android. It is a Linux system that is secure for people with absolutely no understanding of Linux or networking. This is enabled by allowing the app developer to become something like a full Linux user on the Android device. All of the Linux kernel binaries that could modify the kernel in any way are removed and there is no administrative account present. When the hardware manufacturer logs out for the last time, all the administrative and modifying binaries are deleted. This secures the remaining files that are all marked as read only. Android also has a very robust SELinux implementation in place. Every location present has a defined security context. So there are places where you can create temp files and store data, but the things that can be added and manipulated are very limited in their access to other parts of the system. If you mess around with this the way these tools work will become much more tangible.
By comparison, most distros ship with a very open and unconfigured security context. The SELinux configuration is still extremely permissive in distros with SELinix integrated, like Fedora. This is nothing like Android’s setup. The primary reason for a lot of the ROM community on Android and how they have root access is because of exploiting CVE vulnerabilities in the kernel that were found after the kernel was shipped. Android works with orphan kernels that only the manufacturer can update because they retain the source code for the kernel modules that they add at the last minute. This is the depreciation mechanism used by the hardware manufacturer to steal ownership with Android devices.
If you understand how exploiting CVE’s works on a simple abstract level, and why it is necessary in order to bypass the immutable system (read only file system without tools to modify Linux kernel binaries), and how SELinux adds further restrictions based on the context of who is accessing the directory or command/executable, you should better understand the complexity of the question you’re asking. The app developer on Android is like your equal on the device. They can do what you can do, and that is why you are so restricted too. Your measures of control on Android are very limited and just in the app environment spaces.
Once I learned the basics of this system, it has become the way I view all software systems intended to enable ignorant consumers. Tremendous power to alter systems is included in these platforms, platforms like Windows.
Those that are trying to make the Windows games work on Linux are likely completely focused on functionality. When people talk about things like sandboxing, they are almost always talking about library dependencies and not any kind of security context. It is likely that any malware that targets Windows binaries will not work on Linux directly, but something that targets Linux specifically is another matter entirely; it is security through obscurity, which means no security at all. Unless you’ve taken active measures to limit the PID/GID/security context of the process that is running the software, it has all the same permissions of the user that called it. It can delete, view, and write anywhere that you can with the user/group/sc that launched it.
When people talk about things like sandboxing, they are almost always talking about library dependencies and not any kind of security context
Uh. I don’t think I can agree with you on this. Sure, Steam has a mini-Ubuntu distro, and there are a few packaging techniques to bundle libraries, but I’d say that that’s much less-common of a topic of discussion than security context.
Wikipedia talks about security context:
https://en.wikipedia.org/wiki/Sandbox_(computer_security)
The top hits on Kagi for “linux sandbox” are about security.
Well, there’s this study from 2018: https://link.springer.com/article/10.1007/s11416-018-0319-9
Given that Priton / Wine / … try to simulate a Windows environment, it’s certainly possible. But I’ve never heard this happened to anyone. And the discussions on the internet seem very theoretical.
Surely it highly depends on the exact kind of malware and what it tries to do. And it doesn’t really seem to happen in the wild. But I see no reason why it wouldn’t theoretically work.
