How does Qubes protect me from malware IF?

General Discussion
1

How does Qubes protect me from malware IF?

If I am using one of the standard provided Qubes, such as Personal Qube, IF?

The Malware is a "browser ‘drive by install’ while web surfing?
I realize that the rest of my other Qubes are protected, excepting if the malware installs itself into RAM, and lurks waiting for another Qube to occupy that RAM area. Yeah, never heard of it being in the wild, and really unlikely in any case.

What I am thinking is that, if I continue to use the Personal Qube, I am still at risk within that one Qube, as much as any other version of Linux.

Some types of Malware, in a regular Linux system, would require, that I type in my root password. Actually my thought is, I can be stupid enough to do almost anything I know I should not. For most, it is the thought of having some software program do something they want. but we all realize the potential of malware when we install something a Chat, a feature in Chat. If I were someone trying to spy, it would be like offering to add to a video chat, something to change the voice to text. That is over reaching, those who chose to use Qubes, are - aware that there could be serious consequences, repercussions from making poor choices.

The real question is; If I continually keep using the provided “Personal Qube,” How security, protected in the Qubes OS, than I would be in using just a Linux OS?

1 Like
2

Hey,
Look at default settings of qubesOS as reference for basic build, depend on your personal use you may modify it as you wish.

QubesOS by default provide you with solution for isolation of hardware (hvm, sys-net, sys-usb) and isolated work environments Personal, Work, Vault and etc.

2 Likes
3

Even if a malware tries to install it and you type “sudo xxxx”, it can’t be installed permanentely. The complete root filesystem except /home and /usr/local is on the template and cannot be written from your cube.
And templates normally does not have network access, only connection to trusted repositories is possible.
And “lurking in RAM and wait fore another qube” is nearly impossible, the underlying XEN hypervisor separates the memory for each qube from all other qubes.
You can try it and type in your cube “sudo dnf install xxxx”. The sw will be downloaded and installed (it looks so), but after you restart the qube, this sw is gone (without any parts persisted except your home folder and /usr/local, which is private to your qube and is not shared with other qubes, based on the same template).

3 Likes
4

Inside the (let’s say: Personal) Qube there is no additional ‘protection’, moreover there is a passwordless sudo :wink:
However, the point is not to harden the Linux OS, but let you separate you digital life to multiple smaller domains. So even if one is compromised, the other should be not affected.

So ‘not getting a malware’ is still your responsibility, but one mistake is not fatal - in contrast to a normal ‘bare metal’ Linux (or any other conventional OS) workstation.

5 Likes
5

I thank everyone for their responses.

Zrubi expressed more clearly, than I did, how I felt things worked.

Someone suggested the Personal OS reset, the Operating system everytime I started the Personal Qube, App. I realize two things. I had first thought the Linux OS system, excluding my personal data, was set when I first installed the OS. However, that obviously would not allow for the OS -Fedora xfce, to update. And If the App Qube Personal kept browser information, such as Bookmarks, then malware could likely survive the update.

My feeling being that: IF, I used, the aforementioned Personal Qube months in a row, I still have all the risks of it having a continuing MalWare.

I admit that I suspect there would be a huge difficulty for standard Apps to each have their own Encrypted Drives, and to have a root password in terms of doing things like ‘copy and paste’ between Qubes, copying information between Qubes, using a bunch of the Q commands would be more difficult to be implemented. More hassle, maybe no improvement in Security.

Actually, I think I should test things like continuing bookmarks in an App VM, like App Personal Qube, Work Personal Qube in the OS that is being tested, but that would require a fresh install of OS (I might have messed up something if I used the OS at all) I will not do that today. But felt I should thank those for making the effort to point out some details I that were not in my mind. Better context to the issue.

Thanks all

1 Like
6

Depends what you do in that Personal Qube. You should do things (visit websites, read emails, open files) that you trust AND it is related to your personal life.

You should never open any random website from that domain… use diposable VM’s to do so.

1 Like
7

most of the malware infection is actually needs user interaction. Which means the user is still the weakest link.

So, even if one using Qubes OS, which allows you to separate your digital life, and reduce the risk of a total compromise… still the user decides what they actually do with it.

So Qubes OS not ‘protect’ you, by any means. But it allows you to better protect your data. And the emphasize is on the prevention.

If you already have a malware, then you already failed.

What you need from this point: is a “Lessons Learned” session, then change you online behaviour to prevent the problem happening again.

1 Like
8

Thanks for the effort.

These seem to point more at Windows than Linux.

then more scary.

https://www.pcmag.com/news/malware-that-can-survive-os-reinstalls-strikes-again-likely-for-cyberespionage

Some years ago I was using a Windows system with one of the very best -paid for- Security software. The software blocked me from looking at NBC News. Took me a bit of experimentation to discover it was the Anti-Virus/Security software. Which made clear to me that the Anti-Virus/Security company was monitoring my every web page I visited…

Support for Security software was immediately forthcoming: NBC News was blocked because they had on their site, a lot of Click Bait. Well, there is a reason NBC News is free.

Let my add to my original Question. Would my Security be enhanced if I used a browser installed with a FlatPak? Flatpaks being installed in their own container. How much security is offered wih that Container? Is there another container system that is superior, like Boxes?

Very knowledgeable, computer security types say that they only install software directly from the website that hosts it.

I risk that whoever compiled the Flatpak, if I don’t compile the FlatPak myself. Might not have done so correctly, or had malicious intent. So I am depending on others to check the FlatPak, I choose to use, is the most secure possible.

Edit: “If I compiled the FlatPak, then that is more dangerous to my Security, because I really do not know all the nuances of compiling FlatPaks to be highly secure.”

Yes, the concept of “Drive By Installs” seems to be mentioned as a Windows Security Flaw… Those original Security Flaws, no doubt having been, theoretically been fixed by Updates to Browsers and Operating Systems.

One of the adaptations of, Qubes Isolation by Design Security: Would be have a Different Qube for each possible application of use. Plus only use Temporary, Disp Qubes for Web Browsing. Which for the average user is not very practical. Too much overhead.

But to add to simplifying the use in that case.

I Noticed one of the changes of Windows 11 from Windows 10 user display, is that the start Menu is moved to the lower left hand side to the center. Then rather than requiring I pick the Program/App I want out of one long list. Windows 11 brings up small icons with the uses/purposes of the Programs Apps that one could click on. Such as: Media. Office. Browsers. Easier on my limited brain.

I presume the risks of my getting Malware has gotten worse over time.

I should Assume the worst, even with my best effort.

1 Like
9

Looking from an abstract viewpoint may clarify the situation somewhat.

Malware infecting a system, that is, in the Qubes context, a VM, does this by modifying some parts of that system:

  • The infection may just modify the RAM. In this case, it can harm only as long as the VM is running, and will disappear when the VM is shut down.

  • The same situation exists if the VM is disposable, because any storage containing the malware will be destroyed when the disposable VM is shut down, causing it to be completely deleted.

  • Malware storing its parts completely in the system part of the storage of an AppVM will also be completely destroyed on shutdown of this AppVM, because this part of the storage is lost, too, on shutdown and will be completely replaced by a new copy from the corresponding template on the next boot of the AppVM.

  • The situation is more complicated if the malware stores parts of itself in the system area and other parts in the private area (/home, etc.) of an AppVM. In this case, those parts in the system area will be destroyed on shutdown, and after the next boot of the AppVM, only the parts in the private area will still be present. In many cases, this will be only data and not executable code. As the code using this data is removed after a reboot, they will have no more effect. On the other hand, if the surviving parts of the malware contain executable code, as is the case with a macro virus in an office document, the malware will be reactivated when this code is executed, for instance, when the document containing the macro virus is opened again.

  • If the malware is stored completely in the private storage area, it will survive any reboot of the AppVM and get active as soon as it is executed, even after a reboot. This is a strong argument against storing any executable code in the private area of an AppVM, because it compromises the protection that Qubes provides by its separation of templates and AppVMs. And it is also a strong argument against allowing any macros in documents!

  • If the malware infects a template, you have bad luck, because now all AppVMs based on that template will be infected, too (unless the malware is completely contained in the template`s private storage area). But this can only happen if you ignore any rules for using Qubes correctly!

But no matter how you get an infection of a disposable VM or an AppVM, this infection will always be limited to just that VM and cannot spread anywhere else, especially not to dom0.

5 Likes
10

Once again, thanks to all. I did not recall the specifics of which blocks of information were written over on reboot.

Let us take this a step further.
Hypothesize I am the IT guy for a business company using Qubes.
My company has competitors which could benefit themselves by getting into my companies information and data. And that benefit to the other company would be worth quite a bit financially. so our competitor is well motivated to spend large sums of money to break into our computers. Anyway, since some malware hacks are might be free. As would be typical, most of those using computers are not experienced or knowledgeable about avoiding Malware.

What would be the plan for instructing the average employee how to avoid malware inside an App Qube that they use?

I could clone up a copy of the App Qube. Use it. Then copy the information into a “block device” or even into a RAM only Qube, while in transit to an offline Qube, which would be used to read files/emails. Which brings up a question I have never read up on, How Secure are “Pass Through” Qubes, as are used for decrypting. and might be utilized in a similar way?

I don’t like this way of doing things. I know ordinary people are going to rebel and – revert to just using the one App Qube for everything.

1 Like
11

I dont know, why do you not read the answers, that has given in this thread specially the one from https://forum.qubes-os.org/u/GWeck.
An Qube has only the content of your home folder, all system relevant data comes from the template and the Qube get a copy of that data from the template every time, the Qube starts. If the Qube stops, all written bytes to any system folder are gone.
And it exists no such a thing like “Pass Through” Qubes. You can open files or mails in an disposable qube, that qube has (in addition to “normal” Qubes) even no own home folder. All content from disposable qubes are copied from the (network isolated) template, when the qube starts and are gone, when the Qube stops.
All, with no exception.
A Template on the other side has no network connection, so it exists basically no way for malware, to get into the template (except, you copy that over to the template).
But that copy process can only be initiated from dom0, which has even no network or connection to anything.
It exists simple no way for a malware to get from a qube into an template, except you intentionally copy that over.
Please read the documentation of Qubes OS and specially the description, how Qubes OS works.

2 Likes
12

Murdock Your reply is accurate.

but The goal is to create a flow of information for individuals who are not computer experienced, knowledgeable, and may not be much motivated. and not for everyone using Qubes to become their IT department. Like a secretary who comes into work. That is, to keep the Secretary from making mistakes in the flow of information.

He Makes the the case, that Malware can slip into the middle of an App Qube, reside there, and thereby continue to provide my companies information to someone who should not have it.

1 Like
13

You should be fine.

If you also use the work qube for work, the untrusted qube for running your browser, keep your sensitive information in the vault, etc.

1 Like
14

Trying to get people to use the computer in a secure way by giving them instructions is likely to fail, as I have often observed. But with Qubes, it is possible to set up an environment that forces users to avoid many dangerous actions, and you can do this with a moderate effort by creating an appropriate set of AppVMs for many standard tasks in an office environment:

  • For surfing, use a Linux-based AppVM, e.g., untrusted, providing the browser and file manager, but no other application, especially no office software. If someone wishes to look into a downloaded document, they can do so in a disposable VM, which will cause no harm.

  • For Email, use a similar approach by providing a Linux-based AppVM, say personal, containing the mail client and a file manager, but nothing else, and restrict its internet access to the configured mail server(s). Looking into any received document has to be done, again, in a disposable VM.

  • For working with any documents, provide an AppVM, e.g., work, with office software, but do not give network access to this VM. Any malware in a document will not be able to break out and perhaps download more malware. To make any document-based malware ineffective, you could provide the function to change it to a trusted PDF, perhaps using Dangerzone for Qubes, which will make this PDF even usable as a text source. This AppVM may even be based on a Windows template, but then you have to decide how you will cope with Microsoft’s desire to catch you in their nets.

  • You may even decide to create one or more of these AppVMs as disposable VMs, so that they will not retain any data on reboot. For permanent storage, you could provide an AppVM without network access, containing only a file manager as its only software, so that there is little probability of executing any software of dubious quality. Documents to be kept have to be moved there from the other AppVMs, and documents to be viewed or edited have to be copied or moved to the work VM, but they cannot compromise the storage VM.

  • In a similar way, any other applications needed by the “dumb” user could be encapsulated in special AppVMs providing just these applications but nothing more, and having no network access if they don’t need it.

  • To provide only the dedicated applications in these AppVMs, you may just put these applications into the menus of these AppVMs. A more secure way to achieve this would be to base any of these AppVMs on minimal templates, where just the needed software is installed and nothing else.

At first glance, such a structure might seem intimidating, but it can be mostly hidden from the user. You could put icons calling the individual applications in their AppVMs on the desktop or into a second taskbar. Then the user just has to click on the Firefox, Email, Office, or so, icon, and it will start the application in its AppVM without the user noticing that. So, all the user has to learn is to copy files from one VM to another and, possibly, to send something to a disposable VM. People who have suffered the UI of Windows 10 or 11 should be able to do that! :innocent:

4 Likes
15

but The goal is to create a flow of information for individuals who are not computer experienced, knowledgeable, and may not be much motivated. and not for everyone using Qubes to become their IT department. Like a secretary who comes into work. That is, to keep the Secretary from making mistakes in the flow of information.

That is quite different from what you started with:

How does Qubes protect me from malware IF?

While Qubes provides great tools for protection, there is no way it can protect a layman from all possible malware or attack scenarios. It is simply not designed to do that.

2 Likes
16

Appropriate time to mention the “The App-oriented UI Model and its Security Implications” blog post by Joanna Rutkowska and how that paradigm might be more user-friendly than e.g. using multiple instances of the same file manager, differentiating it only through colors of the window borders and the unspoofable domain prefix.

1 Like
17

That is a good approach, but often important functions like export or moving to another device are lacking in applications. Then you’d still need a file manager, but it would suffice if it just allowed file managing; the double-click to start an application could - and, in the interest of security, should - be missing.

2 Likes
18

No, thats not correct.
You can as often type as you wish “sudo install_malware.sh”, you will never get any success.
All folders except your own home (as it is completely writable for you already) and /usr/local (which is per default persistent) are not persisted at all.
So passwordless sudo is not any problem at all, because no change in any system relevant folder (even in /etc/…) will be there after restart of that qube.

2 Likes
19

Yes, that’s correct, QubesOS is in that not so much better than all other OS. No OS can block any unexperienced user from doing stupid things. But if in doubt, follow the old (and unchanged true) rule “don’t touch anything before you have understand (at least in the basic parts), how it works and what it is designed for.”
“Provide practical and almost secure processes” is the only point. that every system (and computer OS also) can do for you in that topic.
And QubesOS is reasonable good in that task, but that does not mean, that there is no space for improvements.
It is not a system-for-everyone and it is not designed for that use-case. Required are some basic understandings about security and how computers works (and some linux experience on top will not hurt too much :wink:).

1 Like
20

what exactly ‘not correct’ from my answer!?

because what you say is at least questionable:

You can as often type as you wish “sudo install_malware.sh”, you will never get any success.

That’s heavily depends on the content of that imaginary script… :slight_smile:
and in practice, most of such sript WILL succeed for sure. Especially if it would on the same OS on a non Qubes setup.

So passwordless sudo is not any problem at all

And who said if it is a problem!?
Actually I do explained why it doesn’t matters. - in that same post.

The whole point of my post was - and still is:

So ‘not getting a malware’ is still your responsibility, but one mistake is not fatal - in contrast to a normal ‘bare metal’ Linux (or any other conventional OS) workstation.

1 Like