Re: [zones-discuss] Security through virtualization is a failure:
Ok, this allowed-adress seems interesting. It allows me to tie one single IP adress to a NIC, and no other IP adresses are allowed. http://docs.sun.com/app/docs/doc/821-1479/chapter5-2?l=sva=view (I must use exclusive-ip, because several SunRay users can not simultaneously access my network, unless VirtualBox is using bridged NIC (this requires exclusive-ip). NAT does not allow several SunRay users to access my network. I must use shared-folders when using NAT.) So, I will use something like this picture: http://docs.sun.com/source/821-1458/images/example_virtual_network.gif I will not surf from the global zone. I will install VirtualBox inside each local zone, and install WinXP in each local zone. So, how do I use allowed-adress here? I use it to tie a vnic to a local zone? Or can I use allowed-adress to tie the global zone to the SunRay thin clients, and allow no internet traffic to reach the global zone, because it is tied to the SunRay clients? I would like my local zones, separated from the global zone. So, hacker attempts to my local zones, does not reach the global zone. (I have also considered installing Sunray software in a local zone, but that means all SunRay users are collected into one local zone. And they all run software in the same local zone. Which is not really what I want. I want separate local zones, with virtual machines in each.) -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Security through virtualization is a failure:
In message 1012850535.101293547415032.javamail.tweb...@sf-app1, Orvar Korvar writes: (I have also considered installing Sunray software in a local zone, but that m eans all SunRay users are collected into one local zone. And they all run soft I assume there's documentation for load balancing Sun Ray users across servers. But as a rule you should learn to walk before trying to run. ware in the same local zone. Which is not really what I want. I want separate local zones, with virtual machines in each.) Do you have any additional physical NICs in your system? Does SRSS run in a non-global zone? John groenv...@acm.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Security through virtualization is a failure:
On Tue, Dec 28, 2010 at 06:45:00AM -0800, Orvar Korvar wrote: My advice to the paranoid regarding regarding VMs would be to disable extensions allowing the guest broader communication channels to services on the host... I didnt understand. You mean, for each local zone: disabling ssh and all other connections to the outside world? No, I mean don't enable too many features that involve the guest talking to the host. For example, in VBox, don't enable display sharing, nor file sharing between the gues and the host. In LDoms-type architectures I'd avoid the use of shared memory for inter-guest, cross-backplane communications (this might mean having to use NICs to communicate between the guests, which is rather inefficient). In Zones this pinciple is harder to apply because the g-z's kernel is shared with all guests. For example, not using VNICs isn't likely to reduce the attack surface all that much. But g-z user-land services for ngzs could still be avoided. Nico -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Security through virtualization is a failure:
On Tue, Dec 28, 2010 at 11:31:20AM -0800, Octave Orgeron wrote: I would argue that even with VMware you have certain risks to consider when you're depending on an underlining kernel or hypervisor that can actually see into a guest memory or I/O space. And while there are add-ons like vSafe for VMware, there are other products that allow you to examine and even record what's happening in your guests. So there has to be methods for attacks if someone can gain access to the console vm. There is always some attack surface on the host. Para-virtualization like LDoms and LPARs are safer in my opinion by having the hypervisor in the firmware and depending more on hardware features. Like with [...] In general it does seem safer to trust hardware than software, but it's not necessarily the case that hardware is bug free, much less firmware. [...] Of course the question here would be if it's possible to hijack a guest and send LDC messages that could corrupt data or cause performance issues in a denial-of-service type of scenario. In any analysis of the security of the _host_ you must assume that one or more guests have been compromised. Regardless of what virtualization technology you use, you still have to protect your VMs using firewalls, intrusion detection, restricted access, accounting, auditing, etc. Exactly. Good management practices are needed no matter what, whether you virtualize or not. BTW, even if you reboot your control domain in LDoms, your guests will remain up and wait until the virtual I/O services return, kind of a nifty feature of having the hypervisor in the firmware. Yes, quite. At the end of the day, I'd bank my money on Containers and LDoms. Just have to use common sense on configuring them and securing them to reduce your security risks down to point where someone would have to know the Solaris kernel or the UltraSPARC hypervisor really well. Me too, but paired with best practices. Nico -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Security through virtualization is a failure:
On 12/27/10 05:34, Orvar Korvar wrote: Ok, so virtual machines for x86 (VirtualBox, VMware, etc) does not necessarily give you additional security. Security by virtualization is a failure: http://www.serverwatch.com/tutorials/article.php/3905096/Use-Virtual-8086-Mode-to-Secure-Virtual-Servers.htm I wonder, how does the Solaris Zone VM model compare to these? Can you use the same type of exploit on Zones? Are Zones vulnerable to what he talks of, are Zones more secure? Or, are all VMs insecure, no matter what model? It's a completely different model. It doesn't actually run an OS instance on top of another instance, and Virtual 8086 Mode has nothing to do with it at all. Instead, you can think of zones as being like an extended UID plus chroot and networking features. In the same way that UIDs and PIDs keep processes separate, zone IDs keep the per zone processes and data separate. It's still a single instance of a kernel. Again, it's not multiple OSes run one atop another (as you see with VirtualBox, VMware, Xen, et cetera). All of the processes still run on the same system. (And that's why you can't have your zones at different kernel patch levels.) It's at least as secure as allowing multiple users in chroot jails on the same system, and actually more so, because of the way Least Privilege is used to prevent escalation. Even if a user gets ahold of a setuid binary, he can only make himself UID 0 inside the same zone, and he still can't touch the kernel. As for that article, I'm sure Oracle will have some sort of answer, but I'd just say this: all systems have bugs. Whether those bugs allow exploits or not -- and if so, what sorts of exploits -- is extremely difficult to determine. So, you have to keep the software up to date and make sure you're running on a platform that's actively maintained. If you're looking for a magic bullet, the answers are simple. For a single system, turn it off. For a network, you can always run with scissors. BTW, My original plan does not work. I have SunRay clients, which means I can not shutdown the global zone's NIC - because then the SunRay will stop function. I must somehow separate local zones traffic, from the global zone's traffic. I have no clue about SunRay (and I dunno who might), but I think the simplest configuration by far is to set up the shared IP stack model for your zones and assign each zone an address in the same subnet as the global zone. Implement any security you need at a higher level -- using IPsec, SSL, or other such protocols. Don't forget that with security, simple is usually better. Complex answers tend to be the ones that are hard to configure properly and thus are often done wrong. But good luck. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Security through virtualization is a failure:
Ok, thanks. So, Solaris zones are probably not susceptible to these kind of attacks, it seems. But I was considering running VirtualBox in each local zone and surf from the VirtualBox virtual machines. So, in that case, then you can exploit that attack in each local zone. But you could not access the other local zones, because of underlying Zone model? Regarding my SunRay setup and Global zone. I think I just should do it simple, just like this picture: Figure 15-1. Zone 1 will be the global zone. And the rest of the zones, will be VirtualBox zones. Good so? http://docs.sun.com/app/docs/doc/821-1458/gdytf?a=view -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Security through virtualization is a failure:
But I was considering running VirtualBox in each local zone and surf from the VirtualBox virtual machines. So, in that case, then you can exploit that attack in each local zone. But you could not access the other local zones, because of underlying Zone model? As a part of VBox is located in the kernel, your conclusion doesn't seem to be 100% valid. Regarding my SunRay setup and Global zone. I think I just should do it simple, just like this picture: Figure 15-1. Zone 1 will be the global zone. And the rest of the zones, will be VirtualBox zones. Good so? http://docs.sun.com/app/docs/doc/821-1458/gdytf?a=view -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Security through virtualization is a failure:
On 12/27/10 08:15, Orvar Korvar wrote: Ok, thanks. So, Solaris zones are probably not susceptible to these kind of attacks, it seems. But I was considering running VirtualBox in each local zone and surf from the VirtualBox virtual machines. So, in that case, then you can exploit that attack in each local zone. But you could not access the other local zones, because of underlying Zone model? Unless there's a kernel module associated with VirtualBox, a user who breaks out of VirtualBox will still be in a process running in the non-global zone. Kernel modules are global to the system, and are installed (and read) only in the global zone. If one of those is corrupted, then all bets are off. Regarding my SunRay setup and Global zone. I think I just should do it simple, just like this picture: Figure 15-1. Zone 1 will be the global zone. And the rest of the zones, will be VirtualBox zones. Good so? http://docs.sun.com/app/docs/doc/821-1458/gdytf?a=view That's not quite what I'd call simple, but I guess it's a matter of taste. That uses VNICs and exclusive IP stack zones, which wasn't what I was describing in my previous message. Doing it that way means that you have to grant privileges to the zones such that they can manage the interfaces they have, and then you may need to set up security on top of that to keep them from managing them in ways you don't want, such as configuring the wrong IP address. Shared IP stack zones are simpler, at least to me, because the non-global zones are much more constrained in what they can do. For what it's worth, the global zone is usually considered separate from the rest of the zones. Including it as part of a picture like that only (in my opinion) clouds things rather than clarifies. If I were concerned about security at this level, I'd keep the global zone only on a private network. (But I'm usually not concerned about things like this. Either we're friends just sharing a box, or we're not. If we're not, then I'm going to set up secure protocols to talk; I'm not going to trust my data to any sort of partitioning scheme -- whether subnets, VLANs, VNICs or whatever.) -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Security through virtualization is a failure:
On (12/27/10 08:26), James Carlson wrote: That's not quite what I'd call simple, but I guess it's a matter of taste. That uses VNICs and exclusive IP stack zones, which wasn't what I was describing in my previous message. Doing it that way means that you have to grant privileges to the zones such that they can manage the interfaces they have, and then you may need to set up security on top of that to keep them from managing them in ways you don't want, such as configuring the wrong IP address. That (the wrong IP address bit) has changed a bit recently- in S11, we have the facility to configure IP addresses from the global zone, and ensure that the NGZ cannot use any other IP addresses: see the allowed-address property in zonecfg for exclusive IP zones in S11. Shared IP stack zones are simpler, at least to me, because the non-global zones are much more constrained in what they can do. ymmv, but shared IP has its share of ugly features which may leave the NGZ with an incorrect perception of what exactly it can and cannot administer. And it makes it harder for the GZ to observe NGZ networking resource usage (or enforce controls on these). (But I'm usually not concerned about things like this. Either we're friends just sharing a box, or we're not. If we're not, then I'm going to set up secure protocols to talk; I'm not going to trust my data to any sort of partitioning scheme -- whether subnets, VLANs, VNICs or whatever.) yes, agreed. --Sowmini ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Security through virtualization is a failure:
In message 1922922131.01293446116372.javamail.tweb...@sf-app1, Orvar Korvar w rites: BTW, My original plan does not work. I have SunRay clients, which means I can not shutdown the global zone's NIC - because then the SunRay will stop functio n. I must somehow separate local zones traffic, from the global zone's traffic Do you have any additional physical NICs in your system? Have you tried installing SRSS inside a non-global zone? John groenv...@acm.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
