General TC > Tiny Core on Virtual Machines
Virtualization or chroot more secure?
Ulysses_:
In response to the following:
--- Quote from: tinypoodle on April 13, 2011, 02:24:21 PM ---
--- Quote from: Ulysses_ on April 13, 2011, 02:11:30 PM ---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).
--- End quote ---
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.
--- End quote ---
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?
Ulysses_:
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/
danielibarnes:
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:
--- Quote ---First, the more software is deployed within chroot environment, the more dangerous it becomes
--- End quote ---
In it's simplest configuration, lighttpd requires no binaries within the chroot directory.
--- Quote ---Second, the number of ways that root user can break out of chroot is huge.
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
This is what lighttpd can do.
--- Quote ---Fourth, in some cases attackers might not be able to break, but instead will be able to somewhat affect such processes.
--- End quote ---
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.
Ulysses_:
--- Quote ---Actually, I chroot within a VM
--- End quote ---
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?
Ulysses_:
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
Navigation
[0] Message Index
[#] Next page
Go to full version