On Thu, Nov 25, 2010 at 9:21 AM, Petr Benes <petr...@gmail.com> wrote: >> Limit the damage if the Zone's VBox application is somehow >> subverted by the guest OS. > > There are VBox modules in the kernel and the containers framework > can't stop misbehavior in kernelspace.
The use of kernel modules in VBox doesn't weaken the security of Zones. Other software accessible in a zone ultimately uses kernel modules. Gaining unfettered control over kernel space is the hard part. In any case, please see more detail below. >> Beyond security, running VBox in a Zone allows you to make >> use of Zone Resource Controls and Crossbow networking. >> Cool stuff! > > No question about cool features. My concern is if running VBox in a > local zone has any security advantage regarding an evil guest over > running it in the global one. And if so, why? Because all processes running in a zone run with a reduced privilege set, compared to processes running in the global zone. For example, a process in a zone cannot have the proc_zone privilege, so a process in one zone cannot send a signal to another process. Also, by default, a process in a zone does not have the sys_time privilege, so it cannot change the system's time clock. (The global zone administrator can give the sys_time privilege to one or more zones, after which they would be able to change the system's time clock.) See the man page privileges(5). Is the security framework of Zones good enough? An independent security certification gave Solaris Trusted Extensions (which uses Zones to compartmentalize information) a rating of EAL4+ with three different profiles - the highest rating achieved by a general purpose operating system. For more information on security and Solaris Zones, please read the paper "Understanding the Security Capabilities of Solaris Zones" written by Glenn Brunette and myself: http://hub.opensolaris.org/bin/download/Project+isc/WebHome/820%2D7017.pdf . --JeffV _______________________________________________ zones-discuss mailing list email@example.com