Tiny Core Linux
General TC => Tiny Core on Virtual Machines => Topic started by: Ulysses_ on April 13, 2011, 03:28:42 PM
-
In response to the following:
Browsing in a virtual machine is prefered because of its extreme security*. So getting opera to fully function in a TC VM is very much desirable, as TC is very economical in memory so you can run several instances of TC in isolation from each other.
* any infection cannot access private data in the host, cannot infect the host, and cannot exist after a reboot if nonpersistence is selected).
How would that compare from a security aspect to a chroot?
My estimation would be that vmware would be way more resource hungry, slower and also much more complicated to configure.
I wonder why some security specialists recommend vmware but do not mention chroot. In theory they both isolate running processes. Is it possible chroot envrironments are not as isolated? Might there be more exploits for chroot than vmware?
-
Some problems with chroot:
"the number of ways that root user can break out of chroot is huge. Starting from simple use of a chroot() call with no chdir() [see code below] to esoteric methods as the creation of your own /dev/hda or /dev/kmem devices, injection code into the running kernel (http://www.big.net.au/~silvio/runtime-kernel-kmem-patching.txt), using open directory handles outside chroot or chroot-breaking buffer overflows. While system capabilities can be used to render inoperable many of these methods, new ones will likely be found by smart attackers.
Sample code to break out of chroot:"
http://www.linuxsecurity.com/content/view/117632/49/
-
Actually, I chroot within a VM. :) Keep in mind that chroot can be useful when used properly. The best security comes from applying the principles in the article to the program you are running in a chroot. To use lighttpd as an example:
First, the more software is deployed within chroot environment, the more dangerous it becomes
In it's simplest configuration, lighttpd requires no binaries within the chroot directory.
Second, the number of ways that root user can break out of chroot is huge.
I tested the example code, and it only works when executed as root. If you drop privileges (--userspec=nobody:nogroup), this particular example no longer works.
Third, if there is no root user defined within the chroot environment, no SUID binaries, no devices, and the daemon itself dropped root privileges right after calling chroot() call, breaking out of chroot appears to be impossible.
This is what lighttpd can do.
Fourth, in some cases attackers might not be able to break, but instead will be able to somewhat affect such processes.
As far as I know, Lighttpd does not interact with local processes and so cannot affect them.
With other programs, you mileage may vary. I use scponly to chroot scp sessions, for example, and it requires binaries and devices within the chroot directory.
-
Actually, I chroot within a VM
And I chroot within xen within openvz within vmware on a liveCD. :P ;D
So you use lighttpd in TC VMs? Are web servers your main motivation for virtualization?
-
It is recommended to browse the internet with opera in a TC VM (in fact several of them), or to use opera in chroot.
If an exploit exists in opera that allows the attacker to run native code when you visit their site, can such an attacker escape the chroot jail?
(Tbh, I don't understand much from the article, nor the exchange below, but check it out anyway:
"chroot is not and never has been a security tool"
http://kerneltrap.org/Linux/Abusing_chroot
-
Are web servers your main motivation for virtualization?
No, we use them primary for software development as we can get four 2GB development VMs on one 12GB ESXi server (about 4GB overhead). I do, however, have a system with a number of services, each running in a separate VM: iptables/dnsmasq, ntpd, NIS, NFS, lighttpd, etc. Basically, I just chroot lighttpd because I can do so quite easily.
I'd say running web browsers in a chroot is worth it. Maybe even a "howto" for opera, minefield, etc. would be useful. The kerneltrap article centered around neglecting to drop privileges after chroot, which of course is not secure. So long as you do not put any setuid binaries in your chroot (busybox drops privileges for applets which do not require it) and you drop privileges when executing the chroot, I expect you will at least get protection from malicious code which does not expect and provide exploits for escaping a chroot.
-
Even if there was a flaw in Opera, as mentioned, only root can escape from chroot (easily :P). The attacker would need all three of opera flaw, privilege escalation, and code to exit from chroot.
-
When asking the question about comparison of vmware versus chroot as quoted in OP, of course all of the above factors were meant to be implied as I had assumed they would be self-understood in context.
-
Ref reply 4, I guess not :)
-
Alright I'm bought. Would someone with in-depth knowledge care to write a "howto" for opera?
-
While this thread got split off from a different thread, a significant aspect of the basic questions changed.
Originally the issue was specifically about vmware being used as part of a security environment, while this by now has become virtualization in general.
With examining "vmware versus chroot for security puprposes", the most fundamental comparison for me would be "closed source proprietary software versus free open source software for a secure environment."
Inherently to the matter, closed source proprietary software could never be recommended as being proven to be highly secure (in pure opposite to any open source code which is up to review [and possible patching]), so using such for security purposes would depend on blind trust of a user.
Of course there are free open source virtualization solutions available where there would be no such security aspect involved.
-
It does look like setting up chroot correctly is anything but trivial for large applications like opera. For vmware even I can write a "howto", here it is:
1. Download and install vmware player
2. Create a new VM accepting all default settings for ubuntu
3. Download ubuntu .iso
4. Change the VM's CD to the ubuntu .iso using the player menu
5. Change the VM's networking to Bridged using the player menu
6. Set comodo or whatever host firewall to Block All
7. Boot the VM and use firefox, or use synaptic to install opera
And this gives all the protection of a chroot done by an expert. At the expense of some memory.
-
And this gives all the protection of a chroot done by an expert. At the expense of some memory.
... and CPU cycles
-
... and CPU cycles
Unless you have a cpu that is virtualization-ready, which most of today's cpu's are.
-
With the open-vm-tools-x extension I recently submitted, you can use Unity to give a more integrated look and use shared folders to store bookmarks and other permanent data.
Regarding step 5, why select Bridged then modify host firewall (if exists) instead of using NAT?
-
With the open-vm-tools-x extension I recently submitted, you can use Unity to give a more integrated look and use shared folders to store bookmarks and other permanent data.
Thanks. Was it difficult?
Regarding step 5, why select Bridged then modify host firewall (if exists) instead of using NAT?
Because chances are a newbie is using a windows host. Which has a terrible reputation for security so it better be completely blocked off the internet and the VM, otherwise an infected VM might infect the host too. Through one of the many services that run in windows or exploits that exist for windows. But then NAT is blocked too. Whereas Bridged networking is not blocked, this somehow bypasses the firewall.
-
Thanks. Was it difficult?
It was difficult to get right and make it work with a minimum of user intervention. The more recent release of open-vm-tools is easier to compile, but it omits the vmmemctl module, so I had to compile that separately.
Because chances are a newbie is using a windows host.
Good point. Using VMware Player as you describe so completely protects the host that a chroot would not provide any additional security that I can imagine.
-
Maybe ESX can be infected too, if it exposes itself to the internet and the VMs, and one of the VMs gets infected?
-
Maybe ESX can be infected too, if it exposes itself to the internet and the VMs, and one of the VMs gets infected?
It is a best practice to separate your administrative network from your VM network for that reason.
-
Does that imply having two network cards on the host, one for VMs, one administrative to connect to other computers in your lan?
-
Does that imply having two network cards on the host, one for VMs, one administrative to connect to other computers in your lan?
Yes, most rack-mount systems include two NICs for that purpose. The administrative and virtual machine networks can be placed on a different VLANs or firewalled externally.