So I’ve been taking classes in security, and some relevant distros Kali, Qubs, and Tails (etc.) were being discussed. Qubs is especially interesting - it’s linux under Xen and everything you do is in a separate virtual machine. So if a VM gets malwared or ransomwared, you’re totally protected. Then I realized opensuse can easily install Xen - but, for instance, you’re not supposed to do anything (web browsing, email, downloading) into Dom0 on Xen. So I think security oriented distros are a little different from opensuse simply running the Xen kernel in that they prohibit this use of Dom0. Also, I didn’t want to switch away from Virtualbox’s great desktop (VNC is kind of cumbersome compared to VB). So I’m wondering if anyone can point me to a DIY on setting up Xen under LEAP to be a real security distro (like Qubs). And also if there’s a really good alternative to VNC.
I know this sounds a little lame and scattered. I tend to be slow in networking setup, etc., (other than setting up a router with DHCP) required for this sort of setup. VB seems to have made that all pretty much automatic, but it doesn’t protect the pseudo-Dom0 (the host it’s run under).
Thanks in advance :),
Patti
PS: We really need a security forum. This IoT hacking that’s been going on is something we should be able to discuss with respect to opensuse - if these “scattergun” attacks get to you on your home computer system, you’re hosed unless you’re in an appropriately configured VM on an appropriately configured network. https://krebsonsecurity.com/2016/11/san-francisco-rail-system-hacker-hacked/#more-37060
Up to a point. Anything in other VM instances should be protected - if the protection mechanisms actually work, of course - but the VM that you are in? Well that’s another matter.
I know this is not a poll, but I wholeheartedly agree with that. So if my vote counts for anything, you’ve got it.
On 12/06/2016 05:46 PM, PattiMichelle wrote:
>
> So I’ve been taking classes in security, and some relevant distros Kali,
> Qubs, and Tails (etc.) were being discussed. Qubs is especially
> interesting - it’s linux under Xen and everything you do is in a
> separate virtual machine. So if a VM gets malwared or ransom*wared,
> you’re totally protected. Then I realized opensuse can easily install
Care to elaborate on how this works? I could see a system being installed
in such a way (KVM, Xen, or otherwise) that it is basically a VM host on
the bottom and then, upon bootup, starts a VM within that actually shows
up on the monitor, for example, and then that VM has snapshots, or qcow2
backing files that are protected, or whatever, but at the end of the day
the VMs are rolled back (“protecting” them from inter-reboot damage) but
the host system is still there, presumably never accessed, thus never
compromised, at least not easily. The promise of “never compromised”
seems unlikely to be guaranteed, and losing one’s data (by having malware
ship it out over the wire) can be as bad as long it via cryptolocker types
of situations, probably even worse, but at least you’d be able to reboot
and continue minus your previous changes.
> PS: We really need a security forum. This IoT hacking that’s been
> going on is something we should be able to discuss with respect to
> opensuse - if these “scattergun” attacks get to you on your home
> computer system, you’re hosed unless you’re in an appropriately
> configured VM on an appropriately configured network.
> http://tinyurl.com/zqxdxwe
While I agree that Security is a great topic, one of my favorites even,
I’m not sure I agree a separate forum is the right thing; too much
fragmentation in the forums just causes more confusion, and from an
ideological point of view, security should not be something discussed
“over there”, but needs to be integrated into everything else, from the
start. Doing otherwise is part of the reason that windows is an insecure
operating system; baking in security after everything else is done does
not work, and I worry that sectioning off security inadvertently,
subconsciously, leads to that behavior. “Great discussion on SMTP stuff,
but if you want to talk about adding TLS, or whitelists, or anything, that
needs to go over to that security forum.”
Just my two bits.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
Having read about Qubes no for ten minutes (thus making me practically an
expert, of course), there are a few other things that will probably
require research.
First, it looks like all of the applications run in VMs, as believed, and
that those are Xen-based, which is fine, though I see no reason that KVM
could not also be used. One of the intro pages on the site talks about
Type 1 and Type 2 hypervisors, where the latter is an application on top
of an operating system, and the former has the hypervisor as part of the
OS itself. I believe KVM counts as Type 1, since it is entirely in the
kernel, just like Xen. Which you choose is up to you, but I would not
necessarily fight for Xen over KVM simply because of Qubes’ use of Xen.
Second, the desktop shown, from which “applications” are launched and VMs
are managed, is an operating system, so which one? Where is THAT window
manager running? I’m guessing this is the host OS, and is probably just
meant to not have anything run directly in it somehow, but at the end of
the day that system can probably be compromised; it is just a computer
with a window environment, after all. Perhaps it is a dedicated “start
applications from here” VM within the host OS, so it is also able to be
reset when rebooted, but as it also has the ability to access the other
VMs pretty simply, that’s a concern. That access includes copy/paste
((clipboard), the ability to copy files among the other VMs (with a simple
‘Yes’ button to authorize it), and the ability to modify the template VMs
from which the applicatio VMs are instantiated, meaning complete control
of those systems (keyloggers, crypto-whatever, etc.).
Third, some of the magic of Qubes looks like the ability to, very nicely,
present individual windows from the VMs, with the border showing the VM’s
security level (as designated by the user). Launching a new application
(when the VM is already running) is reasonably fast, and even starting an
application from a not-yet-started VM isn’t terrible, considering what is
happening behind the scenes; your mileage will vary a lot depending on
your hardware. Running a full VM for a this “secure” browser, and another
for that “insecure” browser, and another for “work” is a lot of overhead.
To avoid too much overhead one could use a VM for a secure browser as well
as LibreOffice for productivity tasks, or work tasks, but too much
blending of the security levels goes against the model being sought by Qubes.
Fourth, Qubes’ VM manager has some nice work done with the templates and
their spawned VMs. Update the template, and suddenly the spawned VM has a
circular icon indicating a restart is needed to get the template’s
changes; very nice reminder for the end user, though it also should remind
end users that compromise of the template, or anything that can modify the
template (like the user’s main desktop from which everything is started)
means a loss of protection.
Overall, I think some of this would be neat to integrate into openSUSE, in
particular the ability to easily pull out individual windows from VMs;
that could be done now, more or less, with X11’s native forwarding, or
launching applications via SSH’s X forwarding, and then wrapping that in
something that gives the border indicating “secure” or “insecure” or
whatever, but making a nice simple package from all of it has not been
done in openSUSE yet (as far as I know). Pulling some of the packages
from Qubes into the Open Build Service (OBS) and adding them to openSUSE
may be really easy, depending on how those are developed/maintained.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
I hope I can clarify some things you describe in your post…
Security is a vary large and varied topic, and there are many ways to approach it including
Security in Depth - A very important concept that can be applied in software development, networking architecture, system architecture and even in the non-computing world… For example the infamous “Trump’s Wall” might be similar to a firewall but even ideally built would be poor security by itself because there are always ways over, under and around even the best wall. Security in Depth means there are layers behind layers that contribute to, and strengthen the aggregated result. And, we know how well historical walls like the Maginot Line and the Great Wall of China worked at keeping out invaders…
Penetration Testing is important. And similar, like vulnerability scanning. If you don’t run pen testing like Kali and do vulnerability scans with OpenVAS (which is also on the Kali disk), you can’t properly evaluate whether your system is susceptible to malicious hacking.
Tails is a collection of apps that are best run from a LiveCD to avoid any malicious software written to disk. With this disk, a tourist or businessman can travel to highly risky areas where malicious hacking is rampant and have the tools to browse the web safely, bypassing censorship and malicious attacks.
I haven’t followed Qub*s since I saw it in its infancy many years ago. It’s fundamental idea is to run its own version of Linux Containers, but its primary focus then was to provide this capability on other OS like Windows. Isolation, particularly of processes can be a significant security measure and may be the future of all OS where isolation could be automatic and pervasive. But today, isolation is an option that has to be setup, configured and managed manually. Bottom line is if you want this feature on Linux, use something based on Linux Containers instead.
Xen and other paravirtualization are not ordinarily described in the same breath as security, and would likely be controversial if described that way because virtualization is considered mainly a platform technology and little more. As a platform technology, it’s a tool that can be used or mis-used in many ways, both potentially compromising machines and networks or creating partitioned networking due to Network Design, the integrity of the technology (yes, there have been hypervisor bugs), and human error.
Ah, “Dom 0.” Be aware that is an architectural object unique to Xen as a type-1 hypervisor. AFAIK Xen is the only type-1 hypervisor in existence, so be aware that everything you describe or learn in Xen <does not compare directly> with all other “type-2” hypervisors, which is generally everything else (VBox, VMware, KVM, Parallel, Hyper-V, etc). Although sometimes the differences between the two classes of hypervisors might be mainly terminology which they rarely agree upon, the Dom 0 is uniquely type-1 and there is nothing in any other virtualization technology that can compare. So, beware. If you want to learn Xen, then that’s fine. But, unlike everything else you can’t really build on what you’ve learned to learn a different virtualization technology.
Your observation that Dom 0 must be carefully protected, but again you shouldn’t really consider the use of virtual machines as a major security option and there is no magic to installing Xen somehow making your machine more secure.
But, if you do wish to install Xen, there are a multitude of postings in the Virtualization forum and there is openSUSE documentation that describes the proper procedure which is to use YAST. The following openSUSE documentation covers a lot of virtualization(at least Xen. KVM topics are often not the best but I haven’t seen anything that should grossly cause harm) and security issues. Note that because of Xen’s type-1 hypervisor, a special Xen kernel has to be used. If you instead chose something like KVM or Virtualbox, like all other type-2 hypervisors, a mainline Linux kernel can be used.
As for your mentioning VNC, it’s also not considered a “security technology,” it’s simply a remote desktop application.
Actually, the type-2 hypervisor is today distributed as part of the mainline kernel, and can be done so because it’s not-so-different unlike Xen’s type-1 hypervisor. In both cases, the User Tools which include things like management, displaying, and tools that can act on the Guests like start/stop/restart are considered completely separate and ordinarily run in Userland unlike the hypervisor.
And, as I describe in my other post, Xen is uniquely and likely the only type-1 hypervisor in existence. KVM like the rest of the world is a type-2 hypervisor.
Technically speaking, I doubt either hypervisor technology can be considered a part of an OS although today KVM is distributed as part of the kernel (so I think should still be considered not part of the OS).
I’m not an expert - I’m just learning. Qbes installs mainly a Dom0 Xen hypervisor (a simple desktop with no desktop applications to speak of) but also automatically installs some VM “templates” (Fedora, Debian, Whonix, and a “throw away” VM). So you can’t really do much linux-desktop-like when you first boot Qube$. To do stuff (email, etc.) you have to boot a VM. You apparently have to use VNC/ssh/etc. (from within Qube$) to access VMs. This is different from (and less visual than) VirtualBx, but maybe similar to Opensuse+Xen (I haven’t tried that yet).
I have a “mental block” on some of the interchangeable terminology people tend to use for networking - so I haven’t yet figured out how Wube$ handles (isolates) Dom0 networking safely. But the main point is that those hazards presented by personal interaction on the Internet are confined to the VMs (which you can save in backupable containers). Dom0 can’t be compromised. A big deal is if one of your VMs is ransomwared (or otherwise compromised), you just toss it and grab yesterday’s copy of the VM.
This setup isn’t the same as, say Opensuse - you apparently can email, etc., from Dom0 (even after booting the Xen hypervisor kernel) and it can therefore be compromised. I’m not sure how to harden the Dom0 in Opensuse to be as safe as Qub#s, because I haven’t really plumed the depths of Wube$.
PS: I guess you noticed I’m trying to keep the name of that OS out of internet searches, to avoid dumping hackers into this forum…
Hi Tsu - That’s consistent with what I was reading about. I’m not sure Type-2 hypervisors can be made as secure as Type-1 hypervisors. (I see LEAP offers both KVM and Xen for visualization options.) I’ll have to ask for some information on that. I guess the main problem with Opensuse/Xen for security purposes is: how do you harden Dom0? It’s clear one would not want to email/internet/download/run from Dom0, but I’m sure there are many underlying system-level settings, of which I am ignorant, which should be modified to truly harden Dom0 and to only allow VM’s access to the wider world outside the box. That may be kernel-wizard level stuff.
The apparently-random hack (not targeted, just apparently the result of large-scale port scans) of the San Francisco Municipal Transportation Agency (link in my first post) is what got me thinking about this and wanting to understand.
Yes, the professor said Dom0 is only for type-1 hypervisors. You may be right about Xen for linux, but he was mentioning a lot of weird OS’s I’d never heard of. I guess the problem with Type-2 hypervisors (like virtualbox) is the complexity of the interface - the added layer between guest and host. Then there’s the issue of paravirtualization vs full virtualization - it gets kinda fuzzy in my mind, since I’ve never written a kernel (although I’ve coded 8086’s in machine).
I think both type-1 and type-2 hypervisors need special setup, but, for instance, most of my online work now is done in VirtualBox virtual machines (linux or sometimes windows), but there is a concern that malicious code can “sniff out” VirtualBox and attack the host. It’s not clear how hard VB is.
I started this thread because I am thinking of dropping VB and just using Xen under opensuse, but it seems like it would be safer, given the complexity of network/kernel security, to maybe use Xen under a specifically-hardened distro/hypervisor. VirtualBox is convenient. There are some security distros tailored to run under type-2 (I think Wh*nix is the safest). I’ll learn more as the class progresses. It’s easy to install Xen under LEAP, but I’m not really sure how to harden it - when I boot the Xen kernel, the desktop looks the same as when I boot the standard kernel, and I can easily expose Dom0 to the internet.
VNC connections from Dom0 to guest have to be “secured” (ssh?) don’t they? VirtualBox has transparently solved that entire issue of obtaining a fast desktop interface (XFCE/Gnome/KDE/etc.) - it’s automatic. I haven’t tried installing a Xen guest in years, but I’ll try soon… It would be very useful if Xen guest OS’s were as easy to use as guests are in VB, but that would still leave open the “hardening of Dom0” bit…
While we’re on “security” - how about cross-site scripting vulnerabilities? This is as big of an issue as “ransom-ware” - although this one is for the putative opensuse “security” forum I’ve been mentioning. rotfl!
VB seems to have made that all pretty much automatic, but it doesn’t protect the pseudo-Dom0 (the host it’s run under).
