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
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
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:
zones-discuss mailing list