Jump to content

Qubes OS


NotPike

Recommended Posts

I just started using this OS last week and holy cow dose it have power! It's claim to fame is that it compartmentalizes sessions by running mutable VM's. For example, there's a VM (sys-net) that controls you networking hardware, another VM that acts as a firewall (sys-firewall) which routes all traffic to your working VM. It's based off of Fedora-23 and uses the Xen Hypervisor to manage it's VM's. There's also built in TOR support with Whonix. You can also do more complex tasks like analyze untrusted services using a throw away VM and not worry about effecting the rest of your system.

https://www.qubes-os.org

Screenshot_2017-02-21_15-57-00_zpsgclkaq

Link to comment
Share on other sites

https://www.qubes-os.org/doc/qrexec3/

A little bit of research suggests that this OS isnt more secure than anything else.

Everything passes thru Dom0 which handles all security for any program calls from any of the VMs. So what exactly is the point of segregating it into"VMs"?

Windows operates in a similar fashion. And depending on the types of security imposed, maybe more securely.

Link to comment
Share on other sites

12 hours ago, barry99705 said:

That's like saying until there's a hack for windows ACL procedures that it's secure.

My point is not that it's technically insecure, but that it's not logically any more secure than Windows.  At its core it's not much different.  Operating systems "virtualize" applications and services etc, and they all have methods of segregating them.

Another way of putting it is, compromising a VM "firewall" still gives you privileges of that VM to the Dom0 that compromising the windows firewall application would do for the windows OS.

Edited by IDNeon
Link to comment
Share on other sites

13 hours ago, IDNeon said:

My point is not that it's technically insecure, but that it's not logically any more secure than Windows.  At its core it's not much different.  Operating systems "virtualize" applications and services etc, and they all have methods of segregating them.

This one is both logically and from a design standpoint far more secure than Windows could ever be in it's current state.  Windows is designed with backward compatibility and 3rd party integration in mind, Qubes OS is designed with security first and foremost then ease of usage for the user interface of managing fully virtualized systems in mind.  The segregation and securities built into windows is designed to be worked around and avoided.  A program can be easily written that compromises every portion of a Windows OS from just a single point of execution.  Where in Qubes you may be able to compromise a portion of it with a single execution; it's much more difficult to compromise every portion of it because you have to break out of your confined point of entry first and then execute more once you have broken out of that portion.  While it's not impossible, it's much more improbable.  So for your example "compromising the firewall VM", you have to think about how you are going to even access the firewall VM to compromise it.  Considering the User Interface/setting up VMs is the only portion that has access to compromise that VM, that means you must have something execute in the User Interface portion of the OS, but then considering you don't actually execute anything from the user interface besides VMs really, then that means you must compromise a VM running on the system, break out of that context into the host OS (where the user interface is located), then execute from there a way to compromise the firewall vm.  Taking on top of all of that, those points described have been thoroughly vetted to harden and to try to prevent such attacks (again nothing is impossible but they try to make it as improbable as they can).  So even if Dom0 is compromised from a general standpoint it's possible they have already hardened it where that point of compromise may be moot in their implementation.

I've been following the project since it's very early stages and the team behind it is pretty awesome at what they do.  While I don't use it regularly, because 99.99% of everything I do is based in Windows, I do apply their concepts to my general operation flow.  Meaning I use segregated VMs to perform various operations and take advantage of snapshots routinely to revert whatever I may have just done in that VM.  Comparatively this is still far more insecure then their implementation because I run Windows OS VMs on top of a Windows host and there are a number of known attacks to break out of the VM and then compromise the host in that situation it still makes it more difficult and luckily those type of attacks are not the most common.  Even further if I'm testing malware I actually go the inception VM route where my Windows host launches a Linux based VM and then that VM launches another Windows VM inside of it where I then test the malware.  A situation where it is very unlikely that an attack is designed to circumvent multiple OS's and virtualized systems to attack the actual host system.  There's no such thing as a 100% security in computers, all you can do is make it harder for attackers to achieve their goals. Qubes makes it easy to implement a setup where that is possible to do since it was the original design goal in the first place.

Link to comment
Share on other sites

I'm currently in the middle of something but I skimmed through your post and want to give it more attention at some point in time.  But I wanted to give food for thought.

What I'm referring to is for instance take the concept of the VM itself, how it communicates whether in the hypervisor, or communicates through your own PC.  These are not so secure, they are not like actually separated physical machines.  That's what I've always been curious about and am very interested in getting to examine Qubes more thoroughly from that perspective...when I have more time.

My point to that though was principally windows does function similarly, but instead of a hypervisor and VM sort of focus, it is done by windows.

An application running for instance isn't running "within" windows persay, it's its own process, its own services, on a CPU, that windows is managing.

Same with Qubes.

Bah...I really don't have the time to sort out the specifics at the moment, but we'll talk, this can be a great thread.  Do a data dump on what you like about it and such I'll get to it by the weekend.

Link to comment
Share on other sites

Windows apps are all run in the same user space.  You get a virus from a "fedex" email, your whole system is most likely borked.  The main gui in Qubes is just xfce on top of the xen(I think) hypervisor.  No programs are actually run in this environment.  Your email app is run in it's own vm, the cryptovirus can't do a damn thing to the dom0 hypervisor.  Any malware that may get installed in any vm goes away when you shutdown the computer for the day, or if you know something happened, restart that vm.  Nothing is persistent except your saved files in your home directory.  It's almost like running a live os from a flash drive with persistence.  Now you can have a personal, work, and fuck-all browser.  Do your shopping and my-face-space in the personal vm.  Work in the work vm, and your late night browsing in the fuck-all vm.  You accidently click on one too many jigglies late at night and your work and personal stuff is still safe.

Link to comment
Share on other sites

4 hours ago, barry99705 said:

Windows apps are all run in the same user space.

Exactly!  That's what I think IDNeion isn't getting, that a process is not the same as a separated virtualized environment.  A process, service aren't really separated from Windows itself, in fact they have clear easy access to actually manage Windows through API calls.  Windows is more an environment that allows things to do whatever they want however they want.  It's not really managing much of anything, quite the opposite considering programs can manage Windows however they want once they gain appropriate permissions.  Which is extremely easy to do in Windows, mainly because of their focus on backward compatibility.  

It's not all Microsoft's fault though, the users complain anytime they actually try to secure the OS because it causes inconvenience or breaks legacy applications, because some company (like the US Defense Department) using Windows still wants to run software from 1989.

Link to comment
Share on other sites

19 hours ago, bored369 said:

It's not all Microsoft's fault though, the users complain anytime they actually try to secure the OS because it causes inconvenience or breaks legacy applications, because some company (like the US Defense Department) using Windows still wants to run software from 1989.

Last time I was in a power plant, (few years, but probably not changed) the scada systems were all windows 98 machines.

Link to comment
Share on other sites

On 2/23/2017 at 3:17 PM, barry99705 said:

Windows apps are all run in the same user space.  You get a virus from a "fedex" email, your whole system is most likely borked.  The main gui in Qubes is just xfce on top of the xen(I think) hypervisor.  No programs are actually run in this environment.  Your email app is run in it's own vm, the cryptovirus can't do a damn thing to the dom0 hypervisor.  Any malware that may get installed in any vm goes away when you shutdown the computer for the day, or if you know something happened, restart that vm.  Nothing is persistent except your saved files in your home directory.  It's almost like running a live os from a flash drive with persistence.  Now you can have a personal, work, and fuck-all browser.  Do your shopping and my-face-space in the personal vm.  Work in the work vm, and your late night browsing in the fuck-all vm.  You accidently click on one too many jigglies late at night and your work and personal stuff is still safe.

If you're getting hosed by a virus that works just with user-level ACLs you got a bigger problem.  Now since your email app HAS to communicate with the hypervisor to use the processor there is a security level that the dom0 and the email app VM share.  That is where this whole thing breaks down.  I think we're talking about two different levels of exploitation of a system.  Also there is a saved-state somewhere for each VM or else you'd have no continuity.  Working from a persistentless state each time would be very annoying.  That may very well be the case for Qubes.

I ask questions through an advocate-adversarial approach so it may seem I'm adversarial but I'm not.  I haven't used Qubes and am genuinely interested in how it works and what's the point.

Link to comment
Share on other sites

On 2/23/2017 at 7:29 PM, bored369 said:

Exactly!  That's what I think IDNeion isn't getting, that a process is not the same as a separated virtualized environment.  A process, service aren't really separated from Windows itself, in fact they have clear easy access to actually manage Windows through API calls.  Windows is more an environment that allows things to do whatever they want however they want.  It's not really managing much of anything, quite the opposite considering programs can manage Windows however they want once they gain appropriate permissions.  Which is extremely easy to do in Windows, mainly because of their focus on backward compatibility.  

It's not all Microsoft's fault though, the users complain anytime they actually try to secure the OS because it causes inconvenience or breaks legacy applications, because some company (like the US Defense Department) using Windows still wants to run software from 1989.

I finally got some time to return to this thread, but unfortunately not to read much documents on the Qubes methodology itself.

In my estimation Qubes would be exposed to the same problems that any virtual-app or VM environment would be exposed to.

Which my adversarial-question is, why is that an advantage?

If we were so concerned it seems to me you could throw together a Qubes using an app-publisher and a VM tool and from your own desktop you just run a VM as your machine and publish apps to your VM from different hosts.

Link to comment
Share on other sites

On 3/2/2017 at 4:05 PM, IDNeon said:

If you're getting hosed by a virus that works just with user-level ACLs you got a bigger problem.  

I take it you're still a student then.  In the 25ish years I've been working in IT, I've only seen a couple networks where the user's didn't have local admin rights.  Not every company has the money to pay someone to go around and update Adobe flash/reader every time it updates.  The whole "don't allow software to run in the user's directory" bullshit causes tons of applications to shit itself.  It's just not worth the headaches, vs the "maybe they will get a crypto virus". Sure you can set up a local admin account that the user's can use, but within a week, they'll just use that account for everything.  At least this way when files on the server get encrypted, we can look at the user profiles and find the user, since it will be encrypted too.  Server files get rolled back to before the trojan, and the desktop gets wiped and reimaged.

 

Which my adversarial-question is, why is that an advantage?

Because in this case, the host can't be compromised.

Edited by barry99705
Link to comment
Share on other sites

On 3/5/2017 at 5:55 AM, barry99705 said:

I take it you're still a student then.  In the 25ish years I've been working in IT, I've only seen a couple networks where the user's didn't have local admin rights.  Not every company has the money to pay someone to go around and update Adobe flash/reader every time it updates.  The whole "don't allow software to run in the user's directory" bullshit causes tons of applications to shit itself.  It's just not worth the headaches, vs the "maybe they will get a crypto virus". Sure you can set up a local admin account that the user's can use, but within a week, they'll just use that account for everything.  At least this way when files on the server get encrypted, we can look at the user profiles and find the user, since it will be encrypted too.  Server files get rolled back to before the trojan, and the desktop gets wiped and reimaged.

 

Which my adversarial-question is, why is that an advantage?

Because in this case, the host can't be compromised.

Virtual machines.  I don't think there's many students out there that would think it's a good idea to have local admin rights to users.

If your environments are still that way then you're dealing with a very slow-to-change large enterprise, or SMBs that are unwilling to invest in virtual machines.

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

I've been busy but I finally got to talk with a friend whose more technical at the engineering level of OS's and he basically confirmed the same idea I had.

Qubes provides an extra layer of user security but that's about it.  We both conceptualized it as essentially being like you were using published apps for everything.

On the hardware it makes no sense for it to function any differently than Windows OS etc.

So anything exploiting something at those levels, kernel/root, bios, would not be affected by the virtualization.

Virtualization to over simplify it is basically different "user_processes" interacting.

Link to comment
Share on other sites

  • 1 month later...

Don't hate on each other guys.  Keep it civil when people have different opinions.

With that said, I will walk the line on this one.  I have tried Qubes for a little bit last year.  It is cool.  I stopped only because at the time USB hardware was hard to configure and it was difficult getting different containers to be able to communicate with each other for testing.

Now, what it is.  It is XenServer.  Dom0 is segregated from other VMs except maybe by a config agent in the VMs that I believe is primarily a push configuration.  Dom0 primary goal is to have access to XenServer to manage the VMs in its own special way.  It is the VSphere client so to speak.  It does not have a network adapter by default.  The VMs are behind a network VM that manages the network devices and then after that is the firewall VM which acts as a software router.

The app VMs are based off of the full machine VM template but is not the full machine template running but like a snapshot.  It can be run in a persistent or non-persistent state and can be backed up with additional snapshots.

If an app VM is compromised, the compromise is only in that app VM.  The malware would then have to figure out how to escape the XenServer sandbox.  Either find an exploit in the hypervisor guest drivers or a misconfiguration on the backend of the firewall.  So, what someone said is right, it is like running your machine in a virtualbox off of snapshots but it still is better than just running the machine bare metal in the sense of security.

So, in summary, the security depends on the software in the guest os that enables feedback to the hypervisor (if there is any, I do not know this) and any other VM you network to it which in default is the firewall VM.  Dom0 can only be gotten to if sandbox is escaped which in that case it makes little sense to get to Dom0 except to maybe further persistence.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...