[RFC][PATCH 00/01]qemu VM entrypoints

[RFC][PATCH 00/01]qemu VM entrypoints

[David Windsor]

Hi,

After a bit more discussion about integrating SELinux and KVM, it seems that
there is little interest in adding enforcement hooks to KVM as it stands.
Once KVM gets some type of inter-vm communication mechanism, MAC hooks will
probably be added in that space.

Until then, there seems to be interest in adding MAC controls to control VM
management operations, such as migrating VMs, or saving/resuming VMs.

One particular aspect of VM management which may be nice to control via
SELinux is the loading of a virtual hard disk into a VM.  Currently,
administrators would have to rely on file permissions to control which files
could be used as a virtual hard disks.  The semantics of file permissions do
not accomplish what is needed here.  A domain needs to explicitly get
permission from the policy to both use a file as a virtual disk and to use
the contents of that virtual disk as an "entrypoint" to the new, virtual
machine of a different integrity level.

Since there is no SELinux permission for this, I have created the vm {
entrypoint } object class/permission pair to represent this type of access.
Policy for allowing domain user_t to load a virtual disk of type
qemu_virtdisk_t would look something like:

allow user_t qemu_virtdisk_t:file r_file_perms;
type_change user_t qemu_virtdisk_t:vm vm_user_t;
allow qemu_virtdisk_t user_vm_t:vm entrypoint;

Please note that this patch will only check the entrypoint permission, and
does not actually facilitate transitioning on the type of the virtual disk.
I want some comments before continuing with this approach.

When loading a virtual disk into a VM, qemu would consult the policy to see
essentially three things: if the current process is allowed to read the
virtual disk file, what the type of the VM should be after loading the disk,
and if the virtual disk is in fact allowed to serve as an entrypoint to the
target domain.

One problem with this approach is that loading a VM is not an exec-based
operation.  Dynamic transitions could be used, but could possibly be avoided
by altering the patch to fork, then re-exec in the target domain.

This patch applies cleanly to kvm-userspace trunk.

Thoughts?


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[Anthony Liguori]

David Windsor wrote:
> Hi,
>
> After a bit more discussion about integrating SELinux and KVM, it seems that
> there is little interest in adding enforcement hooks to KVM as it stands.
> Once KVM gets some type of inter-vm communication mechanism, MAC hooks will
> probably be added in that space.
>   

First, a patch like this has to go to qemu-devel.

> Until then, there seems to be interest in adding MAC controls to control VM
> management operations, such as migrating VMs, or saving/resuming VMs.
>   

Why is this interesting?  Is it common to modify applications like this 
to have additional selinux hooks?  Can you give examples?

What makes QEMU/KVM special such that it requires userspace selinux hooks?

Regards,

Anthony Liguori

> One particular aspect of VM management which may be nice to control via
> SELinux is the loading of a virtual hard disk into a VM.  Currently,
> administrators would have to rely on file permissions to control which files
> could be used as a virtual hard disks.  The semantics of file permissions do
> not accomplish what is needed here.  A domain needs to explicitly get
> permission from the policy to both use a file as a virtual disk and to use
> the contents of that virtual disk as an "entrypoint" to the new, virtual
> machine of a different integrity level.
>
> Since there is no SELinux permission for this, I have created the vm {
> entrypoint } object class/permission pair to represent this type of access.
> Policy for allowing domain user_t to load a virtual disk of type
> qemu_virtdisk_t would look something like:
>
> allow user_t qemu_virtdisk_t:file r_file_perms;
> type_change user_t qemu_virtdisk_t:vm vm_user_t;
> allow qemu_virtdisk_t user_vm_t:vm entrypoint;
>
> Please note that this patch will only check the entrypoint permission, and
> does not actually facilitate transitioning on the type of the virtual disk.
> I want some comments before continuing with this approach.
>
> When loading a virtual disk into a VM, qemu would consult the policy to see
> essentially three things: if the current process is allowed to read the
> virtual disk file, what the type of the VM should be after loading the disk,
> and if the virtual disk is in fact allowed to serve as an entrypoint to the
> target domain.
>
> One problem with this approach is that loading a VM is not an exec-based
> operation.  Dynamic transitions could be used, but could possibly be avoided
> by altering the patch to fork, then re-exec in the target domain.
>
> This patch applies cleanly to kvm-userspace trunk.
>
> Thoughts?
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[David Windsor]

On 7/20/07, Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> wrote:
> David Windsor wrote:
> > Hi,
> >
> > After a bit more discussion about integrating SELinux and KVM, it seems that
> > there is little interest in adding enforcement hooks to KVM as it stands.
> > Once KVM gets some type of inter-vm communication mechanism, MAC hooks will
> > probably be added in that space.
> >
>
> First, a patch like this has to go to qemu-devel.
>
Understood.  This patch started out as a patch to KVM, but eventually
found its way into userspace/qemu.

> > Until then, there seems to be interest in adding MAC controls to control VM
> > management operations, such as migrating VMs, or saving/resuming VMs.
> >
>
> Why is this interesting?  Is it common to modify applications like this
> to have additional selinux hooks?  Can you give examples?
>
This is interesting because currently there are only DAC controls on
the loading of virtual hard disks into a qemu virtual machine.
Further, this patch proposes additional SELinux functionality for
transitioning the qemu process into the correct TE domain prior to
launching the VM.

The use case this patch addresses is that of an administrator wanting
to use KVM/qemu on a server to provide services for subnets of
computers.  It is important here to ensure that if the server is
compromised, a qemu process on this compromised server can only use
virtual disks permitted by policy, otherwise entire subnets of
computers could be exposed to rogue VMs.

If the qemu process attempting to load the virutal disk does not
possess the file:read permission on the virtual disk file, access will
be denied right there.  However, if the process can read the disk
file, this patch proposes an additional control to see if the virtual
disk can be used as an entrypoint to the new, target domain.  If the
vm:entrypoint permission is granted by policy, the qemu process would
transition to the new domain.

As it stands, this patch does not perform any transitions upon loading
a virtual disk.  I think that a transition based on the label of the
requesting process and the label of the virtual disk is appropriate
here.  Does anyone else have any thoughts about this?

> What makes QEMU/KVM special such that it requires userspace selinux hooks?
>
qemu itself is special in that it is a userspace backend that is
widely used with KVM, and the SELinux functionality proposed by this
patch is significant.  Hopefully this answers your question
adequately.

> Regards,
>
> Anthony Liguori
>
> > One particular aspect of VM management which may be nice to control via
> > SELinux is the loading of a virtual hard disk into a VM.  Currently,
> > administrators would have to rely on file permissions to control which files
> > could be used as a virtual hard disks.  The semantics of file permissions do
> > not accomplish what is needed here.  A domain needs to explicitly get
> > permission from the policy to both use a file as a virtual disk and to use
> > the contents of that virtual disk as an "entrypoint" to the new, virtual
> > machine of a different integrity level.
> >
> > Since there is no SELinux permission for this, I have created the vm {
> > entrypoint } object class/permission pair to represent this type of access.
> > Policy for allowing domain user_t to load a virtual disk of type
> > qemu_virtdisk_t would look something like:
> >
> > allow user_t qemu_virtdisk_t:file r_file_perms;
> > type_change user_t qemu_virtdisk_t:vm vm_user_t;
> > allow qemu_virtdisk_t user_vm_t:vm entrypoint;
> >
> > Please note that this patch will only check the entrypoint permission, and
> > does not actually facilitate transitioning on the type of the virtual disk.
> > I want some comments before continuing with this approach.
> >
> > When loading a virtual disk into a VM, qemu would consult the policy to see
> > essentially three things: if the current process is allowed to read the
> > virtual disk file, what the type of the VM should be after loading the disk,
> > and if the virtual disk is in fact allowed to serve as an entrypoint to the
> > target domain.
> >
> > One problem with this approach is that loading a VM is not an exec-based
> > operation.  Dynamic transitions could be used, but could possibly be avoided
> > by altering the patch to fork, then re-exec in the target domain.
> >
> > This patch applies cleanly to kvm-userspace trunk.
> >
> > Thoughts?
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > kvm-devel mailing list
> > kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > https://lists.sourceforge.net/lists/listinfo/kvm-devel
> >
> >
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [kvm-devel] [RFC][PATCH 00/01]qemu VM entrypoints

[Anthony Liguori]

David Windsor wrote:
> On 7/20/07, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> David Windsor wrote:
>> > Hi,
>> >
>> > After a bit more discussion about integrating SELinux and KVM, it 
>> seems that
>> > there is little interest in adding enforcement hooks to KVM as it 
>> stands.
>> > Once KVM gets some type of inter-vm communication mechanism, MAC 
>> hooks will
>> > probably be added in that space.
>> >
>>
>> First, a patch like this has to go to qemu-devel.
>>
> Understood.  This patch started out as a patch to KVM, but eventually
> found its way into userspace/qemu.
>
>> > Until then, there seems to be interest in adding MAC controls to 
>> control VM
>> > management operations, such as migrating VMs, or saving/resuming VMs.
>> >
>>
>> Why is this interesting?  Is it common to modify applications like this
>> to have additional selinux hooks?  Can you give examples?
>>
> This is interesting because currently there are only DAC controls on
> the loading of virtual hard disks into a qemu virtual machine.
> Further, this patch proposes additional SELinux functionality for
> transitioning the qemu process into the correct TE domain prior to
> launching the VM.
>
> The use case this patch addresses is that of an administrator wanting
> to use KVM/qemu on a server to provide services for subnets of
> computers.  It is important here to ensure that if the server is
> compromised, a qemu process on this compromised server can only use
> virtual disks permitted by policy, otherwise entire subnets of
> computers could be exposed to rogue VMs.
>
> If the qemu process attempting to load the virutal disk does not
> possess the file:read permission on the virtual disk file, access will
> be denied right there.  However, if the process can read the disk
> file, this patch proposes an additional control to see if the virtual
> disk can be used as an entrypoint to the new, target domain.  If the
> vm:entrypoint permission is granted by policy, the qemu process would
> transition to the new domain.

I'm sorry, but this seems a bit mad to me.  Wouldn't you just limit the 
qemu process to not be able to read the virtual disk file either using 
traditional permissions or SELinux based restrictions?

I don't see what you would gain from enforcing this sort of a policy.  
Why would you every want to give QEMU read access to a virtual disk file 
but not allow the VM to access it?

Remember, a VM *is* a process here.  You should restrict QEMU in 
whatever way you want the VM to be restricted.  If you have QEMU 
enforcing security policies for the guest, IMHO you've broken your 
security model.

Regards,

Anthony Liguori

> As it stands, this patch does not perform any transitions upon loading
> a virtual disk.  I think that a transition based on the label of the
> requesting process and the label of the virtual disk is appropriate
> here.  Does anyone else have any thoughts about this?
>
>> What makes QEMU/KVM special such that it requires userspace selinux 
>> hooks?
>>
> qemu itself is special in that it is a userspace backend that is
> widely used with KVM, and the SELinux functionality proposed by this
> patch is significant.  Hopefully this answers your question
> adequately.
>
>> Regards,
>>
>> Anthony Liguori
>>
>> > One particular aspect of VM management which may be nice to control 
>> via
>> > SELinux is the loading of a virtual hard disk into a VM.  Currently,
>> > administrators would have to rely on file permissions to control 
>> which files
>> > could be used as a virtual hard disks.  The semantics of file 
>> permissions do
>> > not accomplish what is needed here.  A domain needs to explicitly get
>> > permission from the policy to both use a file as a virtual disk and 
>> to use
>> > the contents of that virtual disk as an "entrypoint" to the new, 
>> virtual
>> > machine of a different integrity level.
>> >
>> > Since there is no SELinux permission for this, I have created the vm {
>> > entrypoint } object class/permission pair to represent this type of 
>> access.
>> > Policy for allowing domain user_t to load a virtual disk of type
>> > qemu_virtdisk_t would look something like:
>> >
>> > allow user_t qemu_virtdisk_t:file r_file_perms;
>> > type_change user_t qemu_virtdisk_t:vm vm_user_t;
>> > allow qemu_virtdisk_t user_vm_t:vm entrypoint;
>> >
>> > Please note that this patch will only check the entrypoint 
>> permission, and
>> > does not actually facilitate transitioning on the type of the 
>> virtual disk.
>> > I want some comments before continuing with this approach.
>> >
>> > When loading a virtual disk into a VM, qemu would consult the 
>> policy to see
>> > essentially three things: if the current process is allowed to read 
>> the
>> > virtual disk file, what the type of the VM should be after loading 
>> the disk,
>> > and if the virtual disk is in fact allowed to serve as an 
>> entrypoint to the
>> > target domain.
>> >
>> > One problem with this approach is that loading a VM is not an 
>> exec-based
>> > operation.  Dynamic transitions could be used, but could possibly 
>> be avoided
>> > by altering the patch to fork, then re-exec in the target domain.
>> >
>> > This patch applies cleanly to kvm-userspace trunk.
>> >
>> > Thoughts?
>> >
>> >
>> > 
>> ------------------------------------------------------------------------- 
>>
>> > This SF.net email is sponsored by: Microsoft
>> > Defy all challenges. Microsoft(R) Visual Studio 2005.
>> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> > _______________________________________________
>> > kvm-devel mailing list
>> > kvm-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/kvm-devel
>> >
>> >
>>
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> kvm-devel mailing list
>> kvm-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>>
>

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[Daniel P. Berrange]

On Fri, Jul 20, 2007 at 03:32:16PM -0400, David Windsor wrote:
> Hi,
> 
> After a bit more discussion about integrating SELinux and KVM, it seems that
> there is little interest in adding enforcement hooks to KVM as it stands.
> Once KVM gets some type of inter-vm communication mechanism, MAC hooks will
> probably be added in that space.
> 
> Until then, there seems to be interest in adding MAC controls to control VM
> management operations, such as migrating VMs, or saving/resuming VMs.
> 
> One particular aspect of VM management which may be nice to control via
> SELinux is the loading of a virtual hard disk into a VM.  Currently,
> administrators would have to rely on file permissions to control which files
> could be used as a virtual hard disks.  The semantics of file permissions do
> not accomplish what is needed here.  A domain needs to explicitly get
> permission from the policy to both use a file as a virtual disk and to use
> the contents of that virtual disk as an "entrypoint" to the new, virtual
> machine of a different integrity level.
> 
> Since there is no SELinux permission for this, I have created the vm {
> entrypoint } object class/permission pair to represent this type of access.
> Policy for allowing domain user_t to load a virtual disk of type
> qemu_virtdisk_t would look something like:
> 
> allow user_t qemu_virtdisk_t:file r_file_perms;
> type_change user_t qemu_virtdisk_t:vm vm_user_t;
> allow qemu_virtdisk_t user_vm_t:vm entrypoint;
> 
> Please note that this patch will only check the entrypoint permission, and
> does not actually facilitate transitioning on the type of the virtual disk.
> I want some comments before continuing with this approach.
> 
> When loading a virtual disk into a VM, qemu would consult the policy to see
> essentially three things: if the current process is allowed to read the
> virtual disk file, what the type of the VM should be after loading the disk,
> and if the virtual disk is in fact allowed to serve as an entrypoint to the
> target domain.
> 
> One problem with this approach is that loading a VM is not an exec-based
> operation.  Dynamic transitions could be used, but could possibly be avoided
> by altering the patch to fork, then re-exec in the target domain.

It could be - if your put the policy at the control API layer instead of
in QEMU itself. One of the roadmap items for the libvirt API is fine grained
MAC on all virtual machine control APIs it exposes. SELinux is the most
likely technology we've thought about using for this task. libvirt itself 
exec's the QEMU or KVM binary, so it may be possible to do a transition at 
that point.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[James Morris]

On Fri, 20 Jul 2007, Daniel P. Berrange wrote:

> It could be - if your put the policy at the control API layer instead of
> in QEMU itself.

Then you can bypass MAC security by invoking qemu directly.


- James
-- 
James Morris
<jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[Daniel P. Berrange]

On Fri, Jul 20, 2007 at 04:30:22PM -0400, James Morris wrote:
> On Fri, 20 Jul 2007, Daniel P. Berrange wrote:
> 
> > It could be - if your put the policy at the control API layer instead of
> > in QEMU itself.
> 
> Then you can bypass MAC security by invoking qemu directly.

Isn't that upto the policy - if its a targetted policy, then this is true
of most apps where the local users can bypass MAC, since they're all in 
unconfined  domains. I would have thought strict policy would prevent direct 
execution of qemu though ?

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[Anthony Liguori]

James Morris wrote:
> On Fri, 20 Jul 2007, Daniel P. Berrange wrote:
>
>   
>> It could be - if your put the policy at the control API layer instead of
>> in QEMU itself.
>>     
>
> Then you can bypass MAC security by invoking qemu directly.
>   

You can bypass MAC security by writing your own binary that uses the KVM 
kernel interfaces.

Regards,

Anthony Liguori

> - James
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[James Morris]

On Fri, 20 Jul 2007, Anthony Liguori wrote:

> James Morris wrote:
> > On Fri, 20 Jul 2007, Daniel P. Berrange wrote:
> > 
> >   
> > > It could be - if your put the policy at the control API layer instead of
> > > in QEMU itself.
> > >     
> > 
> > Then you can bypass MAC security by invoking qemu directly.
> >   
> 
> You can bypass MAC security by writing your own binary that uses the KVM
> kernel interfaces.

Yep, I was thinking only about qemu.

I guess you'd have OS policy preventing normal domains from accessing 
/dev/kvm (or /dev/lguest etc.), while a security-aware launcher would 
enforce access control policy over which domains could launch which disk 
images as VMs, and also setup the execution context & fork.

So, perhaps this would be better done at the libvirt layer (i.e. make 
libvirt the object manager).



- James
-- 
James Morris
<jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[Anthony Liguori]

James Morris wrote:
> On Fri, 20 Jul 2007, Anthony Liguori wrote:
>
>   
>> James Morris wrote:
>>     
>>> On Fri, 20 Jul 2007, Daniel P. Berrange wrote:
>>>
>>>   
>>>       
>>>> It could be - if your put the policy at the control API layer instead of
>>>> in QEMU itself.
>>>>     
>>>>         
>>> Then you can bypass MAC security by invoking qemu directly.
>>>   
>>>       
>> You can bypass MAC security by writing your own binary that uses the KVM
>> kernel interfaces.
>>     
>
> Yep, I was thinking only about qemu.
>
> I guess you'd have OS policy preventing normal domains from accessing 
> /dev/kvm (or /dev/lguest etc.), while a security-aware launcher would 
> enforce access control policy over which domains could launch which disk 
> images as VMs, and also setup the execution context & fork.
>   

I really think you have to start with the assumption that a guest can 
access anything that QEMU can access and attempt to build security 
around that.  If you want to restrict what the guest can see, restrict 
what QEMU can see.

At some point, we may do crazy stuff like syscall pass-through in which 
case, it would be all but impossible to have a "security-aware" launcher.

Regards,

Anthony Liguori

> So, perhaps this would be better done at the libvirt layer (i.e. make 
> libvirt the object manager).
>
>
>
> - James
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[James Morris]

On Fri, 20 Jul 2007, Anthony Liguori wrote:

> > I guess you'd have OS policy preventing normal domains from accessing
> > /dev/kvm (or /dev/lguest etc.), while a security-aware launcher would
> > enforce access control policy over which domains could launch which disk
> > images as VMs, and also setup the execution context & fork.
> >   
> 
> I really think you have to start with the assumption that a guest can access
> anything that QEMU can access and attempt to build security around that.  If
> you want to restrict what the guest can see, restrict what QEMU can see.

Right, we are talking about specific invocations of qemu running in 
different security domains.  SELinux policy at the OS level would control 
what each domain (i.e. instance of qemu) can do.

> At some point, we may do crazy stuff like syscall pass-through in which case,
> it would be all but impossible to have a "security-aware" launcher.

We need some mechanism to invoke VM instances so that they execute in a 
specific security domain, and to ensure that the domain performing the 
invocation is authorized to do so, on the specific disk image, and to be 
transitioned to a specific domain of execution according to policy.

This is just the invocation phase.

There may need to be further controls on e.g. inter-VM communication or 
other things which may operate outside the standard host OS mechanisms.

I'm not sure exactly what syscall passthrough entails, or what the 
security implications are.  How would it make it impossible to have a 
security-aware launcher (i.e. the application which invokes the VM 
instance per above) ?



- James
-- 
James Morris
<jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[David Windsor]

On 7/20/07 6:42 PM, "James Morris" <jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org> wrote:

> On Fri, 20 Jul 2007, Anthony Liguori wrote:
> 
>> James Morris wrote:
>>> On Fri, 20 Jul 2007, Daniel P. Berrange wrote:
>>> 
>>>   
>>>> It could be - if your put the policy at the control API layer instead of
>>>> in QEMU itself.
>>>>     
>>> 
>>> Then you can bypass MAC security by invoking qemu directly.
>>>   
>> 
>> You can bypass MAC security by writing your own binary that uses the KVM
>> kernel interfaces.
> 
> Yep, I was thinking only about qemu.
> 
> I guess you'd have OS policy preventing normal domains from accessing
> /dev/kvm (or /dev/lguest etc.), while a security-aware launcher would
> enforce access control policy over which domains could launch which disk
> images as VMs, and also setup the execution context & fork.
>

Yes, the use case I was targeting was an environment in which access to
/dev/kvm from normal user domains was not permitted.
 
> So, perhaps this would be better done at the libvirt layer (i.e. make
> libvirt the object manager).
>

The more that I think about this, I think that libvirt may indeed be the
correct place for the vm:entrypoint hook.  Rather than have individual
userspace backends be responsible for setting up the correct execution
context and forking, it makes sense for libvirt itself to set up the correct
context for the qemu process prior to launching qemu.  And as Daniel said,
it would allow policy writers to write coherent policy about VMs regardless
of the userspace backend used.

The SELinux specific bits of the patch are still relevant, I think I will
just move the enforcement code to libvirt.

> 
> 
> - James



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[Avi Kivity]

Anthony Liguori wrote:
> James Morris wrote:
>   
>> On Fri, 20 Jul 2007, Daniel P. Berrange wrote:
>>
>>   
>>     
>>> It could be - if your put the policy at the control API layer instead of
>>> in QEMU itself.
>>>     
>>>       
>> Then you can bypass MAC security by invoking qemu directly.
>>   
>>     
>
> You can bypass MAC security by writing your own binary that uses the KVM 
> kernel interfaces.
>
>   

I guess modifying qemu makes sense if the modification gives you *more*
permissions.

i.e. you start out just with the ability to access the disk image, and
then you transition to a new domain that allows you to access some network.


Is that what is intended here?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[David Windsor]

On 7/21/07 2:21 AM, "Avi Kivity" <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:

> Anthony Liguori wrote:
>> James Morris wrote:
>>   
>>> On Fri, 20 Jul 2007, Daniel P. Berrange wrote:
>>> 
>>>   
>>>     
>>>> It could be - if your put the policy at the control API layer instead of
>>>> in QEMU itself.
>>>>     
>>>>       
>>> Then you can bypass MAC security by invoking qemu directly.
>>>   
>>>     
>> 
>> You can bypass MAC security by writing your own binary that uses the KVM
>> kernel interfaces.
>> 
>>   
> 
> I guess modifying qemu makes sense if the modification gives you *more*
> permissions.
> 
> i.e. you start out just with the ability to access the disk image, and
> then you transition to a new domain that allows you to access some network.
> 
> 
> Is that what is intended here?

The intent here is to provide some mechanism for a policy-driven transition
to occur when loading a virtual disk.  So, an administrator would write
policy for say, a topsecret_vm_t domain, in which the top secret VM can run.
All access requests from this VM would have a source type of topsecret_vm_t
on the host machine.  The virtual disk, labeled perhaps as topsecret_disk_t,
would need to be authorized in policy to be an entrypoint into the
topsecret_vm_t domain.  This patch proposes a mechanism that allows us to
provide policy driven controls both over which files can be used as a disk
image, and to which domain a qemu process will transition after loading the
disk image.  

Originally, I thought qemu was the proper place for this type of an
enforcement hook, but libvirt may be more appropriate because qemu could be
launched with a different security context if loading a virtual disk, rather
than having qemu set up the security context of the VM.  Thoughts?



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[Anthony Liguori]

David Windsor wrote:
> On 7/21/07 2:21 AM, "Avi Kivity" <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>
>   
>> Anthony Liguori wrote:
>>     
>>> James Morris wrote:
>>>   
>>>       
>>>> On Fri, 20 Jul 2007, Daniel P. Berrange wrote:
>>>>
>>>>   
>>>>     
>>>>         
>>>>> It could be - if your put the policy at the control API layer instead of
>>>>> in QEMU itself.
>>>>>     
>>>>>       
>>>>>           
>>>> Then you can bypass MAC security by invoking qemu directly.
>>>>   
>>>>     
>>>>         
>>> You can bypass MAC security by writing your own binary that uses the KVM
>>> kernel interfaces.
>>>
>>>   
>>>       
>> I guess modifying qemu makes sense if the modification gives you *more*
>> permissions.
>>
>> i.e. you start out just with the ability to access the disk image, and
>> then you transition to a new domain that allows you to access some network.
>>
>>
>> Is that what is intended here?
>>     
>
> The intent here is to provide some mechanism for a policy-driven transition
> to occur when loading a virtual disk.  So, an administrator would write
> policy for say, a topsecret_vm_t domain, in which the top secret VM can run.
> All access requests from this VM would have a source type of topsecret_vm_t
> on the host machine.  The virtual disk, labeled perhaps as topsecret_disk_t,
> would need to be authorized in policy to be an entrypoint into the
> topsecret_vm_t domain.  This patch proposes a mechanism that allows us to
> provide policy driven controls both over which files can be used as a disk
> image, and to which domain a qemu process will transition after loading the
> disk image.  
>   

Can you already write an selinux policy that changes the label of a 
process when it open()s a different file?

Regards,

Anthony Liguori

> Originally, I thought qemu was the proper place for this type of an
> enforcement hook, but libvirt may be more appropriate because qemu could be
> launched with a different security context if loading a virtual disk, rather
> than having qemu set up the security context of the VM.  Thoughts?
>
>
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[James Morris]

On Sat, 21 Jul 2007, Anthony Liguori wrote:

> Can you already write an selinux policy that changes the label of a 
> process when it open()s a different file?

No, and you normally want to do this over an exec anyway, to ensure the 
new execution state is clean.



- James
-- 
James Morris
<jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[Joshua Brindle]

James Morris wrote:
> On Sat, 21 Jul 2007, Anthony Liguori wrote:
> 
>> Can you already write an selinux policy that changes the label of a
>> process when it open()s a different file?
> 
> No, and you normally want to do this over an exec anyway, to
> ensure the new execution state is clean.
> 

This is correct and the object model being proposed isn't just about
opening files. 

Anthony - There are several userspace object managers for SELinux,
basically they manage resources that are too abstract for the kernel to
manage. These include DBUS connections, X windows/pixmaps/cursors/etc,
postgresql tables and rows, etc. SELinux is designed to designed to have
non-centralized enforcement of the policy (but centralized decision
making). In this case the object model isn't just about opening a file,
its about lauching and restricting a vm based on an abstract resource,
in this case a virtual disk file, that the kernel can't differenciate
from any other file.

The reason for this abstraction is simple, think about all the files
that qemu has to open that aren't disk files. For example, if you have 3
vm's, unclass, secret, top secret, those qemu processes still have to
share resources, library files, configuration files, devices,
potentially log, pid etc. If someone could manage to get a top secret
disk labeled lib_t they could boot any of those vm's with that disk
image (using snapshot or some feature to prevent write attempts on it),
and disclose top secret data where it shouldn't be disclosed. 

With David's object model this kind of attack can be prevented because
virtual disk files aren't 'just files' to qemu, they are an abstract
resource that means more than just a regular file, just like a database
file is more than just a regular file for SE-Postgresql.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[Anthony Liguori]

Joshua Brindle wrote:
> James Morris wrote:
>   
>> On Sat, 21 Jul 2007, Anthony Liguori wrote:
>>
>>     
>>> Can you already write an selinux policy that changes the label of a
>>> process when it open()s a different file?
>>>       
>> No, and you normally want to do this over an exec anyway, to
>> ensure the new execution state is clean.
>>
>>     
>
> This is correct and the object model being proposed isn't just about
> opening files. 
>
> Anthony - There are several userspace object managers for SELinux,
> basically they manage resources that are too abstract for the kernel to
> manage. These include DBUS connections, X windows/pixmaps/cursors/etc,
> postgresql tables and rows, etc. SELinux is designed to designed to have
> non-centralized enforcement of the policy (but centralized decision
> making). In this case the object model isn't just about opening a file,
> its about lauching and restricting a vm based on an abstract resource,
> in this case a virtual disk file, that the kernel can't differenciate
> from any other file.
>
> The reason for this abstraction is simple, think about all the files
> that qemu has to open that aren't disk files. For example, if you have 3
> vm's, unclass, secret, top secret, those qemu processes still have to
> share resources, library files, configuration files, devices,
> potentially log, pid etc. If someone could manage to get a top secret
> disk labeled lib_t they could boot any of those vm's with that disk
> image (using snapshot or some feature to prevent write attempts on it),
> and disclose top secret data where it shouldn't be disclosed. 
>   

The only way that the VM could possible see the top secret data is if 
the disk file was readable by the QEMU process running the secret 
guest.  That's the security problem.  You address this "attack" by 
simply not letting the user that launched the QEMU process have read 
access to the top secret disk file.   Why would you ever want to allow 
the QEMU process that's running a "secret" domain to have any read 
access to top secret files?

Regards,

Anthony Liguori

> With David's object model this kind of attack can be prevented because
> virtual disk files aren't 'just files' to qemu, they are an abstract
> resource that means more than just a regular file, just like a database
> file is more than just a regular file for SE-Postgresql.
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[David Windsor]

On 7/22/07 3:07 PM, "Anthony Liguori" <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> wrote:

> Joshua Brindle wrote:
>> James Morris wrote:
>>   
>>> On Sat, 21 Jul 2007, Anthony Liguori wrote:
>>> 
>>>     
>>>> Can you already write an selinux policy that changes the label of a
>>>> process when it open()s a different file?
>>>>       
>>> No, and you normally want to do this over an exec anyway, to
>>> ensure the new execution state is clean.
>>> 
>>>     
>> 
>> This is correct and the object model being proposed isn't just about
>> opening files. 
>> 
>> Anthony - There are several userspace object managers for SELinux,
>> basically they manage resources that are too abstract for the kernel to
>> manage. These include DBUS connections, X windows/pixmaps/cursors/etc,
>> postgresql tables and rows, etc. SELinux is designed to designed to have
>> non-centralized enforcement of the policy (but centralized decision
>> making). In this case the object model isn't just about opening a file,
>> its about lauching and restricting a vm based on an abstract resource,
>> in this case a virtual disk file, that the kernel can't differenciate
>> from any other file.
>> 
>> The reason for this abstraction is simple, think about all the files
>> that qemu has to open that aren't disk files. For example, if you have 3
>> vm's, unclass, secret, top secret, those qemu processes still have to
>> share resources, library files, configuration files, devices,
>> potentially log, pid etc. If someone could manage to get a top secret
>> disk labeled lib_t they could boot any of those vm's with that disk
>> image (using snapshot or some feature to prevent write attempts on it),
>> and disclose top secret data where it shouldn't be disclosed.
>>   
> 
> The only way that the VM could possible see the top secret data is if
> the disk file was readable by the QEMU process running the secret
> guest.  That's the security problem.  You address this "attack" by
> simply not letting the user that launched the QEMU process have read
> access to the top secret disk file.   Why would you ever want to allow
> the QEMU process that's running a "secret" domain to have any read
> access to top secret files?
> 

There will be some cases where VMs of different integrity levels have
file:read permissions in common for certain files, for example, shared
libraries, or other resources which may be explicitly shared.

The vm:entrypoint is similar in nature to the file:entrypoint permission.
For files, only a certain trusted codebase is authorized in policy as an
entrypoint into a certain domain; this codebase is given file:entrypoint
permission wrt the target domain.  Similarly, for virtual machines, it would
be nice to authorize in policy a certain disk image as an entrypoint into a
certain domain.  It would also be nice to have SELinux policy decide which
domain a VM will execute in not only based on the type of the virtual disk,
but on the type of the process loading the virtual disk.  This can be
accomplished using the vm:entrypoint permission and type_transition rules.
If the patch that I posted is moved to libvirt, no modification of qemu is
necessary, and those wishing to use qemu (and likely other userspace
backends later) would just link against libvirt and libselinux.

Thanks,

David Windsor


> Regards,
> 
> Anthony Liguori
> 
>> With David's object model this kind of attack can be prevented because
>> virtual disk files aren't 'just files' to qemu, they are an abstract
>> resource that means more than just a regular file, just like a database
>> file is more than just a regular file for SE-Postgresql.
>> 
>>   
> 



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[David Windsor]

On 7/21/07 11:54 AM, "Anthony Liguori" <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> wrote:

> David Windsor wrote:
>> On 7/21/07 2:21 AM, "Avi Kivity" <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>> 
>>   
>>> Anthony Liguori wrote:
>>>     
>>>> James Morris wrote:
>>>>   
>>>>       
>>>>> On Fri, 20 Jul 2007, Daniel P. Berrange wrote:
>>>>> 
>>>>>   
>>>>>     
>>>>>         
>>>>>> It could be - if your put the policy at the control API layer instead of
>>>>>> in QEMU itself.
>>>>>>     
>>>>>>       
>>>>>>           
>>>>> Then you can bypass MAC security by invoking qemu directly.
>>>>>   
>>>>>     
>>>>>         
>>>> You can bypass MAC security by writing your own binary that uses the KVM
>>>> kernel interfaces.
>>>> 
>>>>   
>>>>       
>>> I guess modifying qemu makes sense if the modification gives you *more*
>>> permissions.
>>> 
>>> i.e. you start out just with the ability to access the disk image, and
>>> then you transition to a new domain that allows you to access some network.
>>> 
>>> 
>>> Is that what is intended here?
>>>     
>> 
>> The intent here is to provide some mechanism for a policy-driven transition
>> to occur when loading a virtual disk.  So, an administrator would write
>> policy for say, a topsecret_vm_t domain, in which the top secret VM can run.
>> All access requests from this VM would have a source type of topsecret_vm_t
>> on the host machine.  The virtual disk, labeled perhaps as topsecret_disk_t,
>> would need to be authorized in policy to be an entrypoint into the
>> topsecret_vm_t domain.  This patch proposes a mechanism that allows us to
>> provide policy driven controls both over which files can be used as a disk
>> image, and to which domain a qemu process will transition after loading the
>> disk image.  
>>   
> 
> Can you already write an selinux policy that changes the label of a
> process when it open()s a different file?
> 

Yes, technically a process can change its context without executing execve.
However, this is generally considered to be bad from a security perspective,
as domain transitions should always occur at the boundary of an execve,
because of the environmental cleansing that occurs as a result of executing
a new binary.  This type of behavior, the changing of a process' security
context outside of an execve, is called a dynamic transition and violates
various useful security properties, namely label tranquility.  See
http://beyondabstraction.net/2006/04/06/the-environment-environmental-contam
ination-and-selinux-part-1 for more information about how SELinux and the
linux environment interact.

> Regards,
> 
> Anthony Liguori
> 
>> Originally, I thought qemu was the proper place for this type of an
>> enforcement hook, but libvirt may be more appropriate because qemu could be
>> launched with a different security context if loading a virtual disk, rather
>> than having qemu set up the security context of the VM.  Thoughts?
>> 
>> 
>> 
>>   
> 



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[David Windsor]

On 7/20/07, James Morris <jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org> wrote:
> On Fri, 20 Jul 2007, Daniel P. Berrange wrote:
>
> > It could be - if your put the policy at the control API layer instead of
> > in QEMU itself.
>
I think that libvirt may be a bit too high in the virtualization stack
for this control.
What benefits are there for placing such a hook in libvirt vs qemu?
libvirt could still use the vm:entrypoint permission for other types
of VMs it manages.

> Then you can bypass MAC security by invoking qemu directly.
>
>
> - James
> --
> James Morris
> <jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[Daniel P. Berrange]

On Fri, Jul 20, 2007 at 05:57:29PM -0400, David Windsor wrote:
> On 7/20/07, James Morris <jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org> wrote:
> >On Fri, 20 Jul 2007, Daniel P. Berrange wrote:
> >
> >> It could be - if your put the policy at the control API layer instead of
> >> in QEMU itself.
> >
> I think that libvirt may be a bit too high in the virtualization stack
> for this control.
> What benefits are there for placing such a hook in libvirt vs qemu?
> libvirt could still use the vm:entrypoint permission for other types
> of VMs it manages.

It is quite possible that we need policy at several layers of the virt stack.
It also could be that we're thinking about different aspects of the access 
control for VMs. So here's a little background on what I've considered so 
far in the context of libvirt & in particular how it deals with QEMU...

Currently there are two ways to access libvirt. A local user may use the 
library directly. A remote user may use the library indirectly via the 
libvirt daemon. The libvirt daemon allows connections either via combination 
of an SSH tunnel to its UNIX domain socket, or a SSL/TLS encrypted channel.
In the local, or SSH case permissions are coarse - root has full read-write, 
non-root has readonly. Potentially we could use peer credentials on unix 
domain sockets to do more per-user permissioning. In the TLS case, we each 
client user is identified based on their client  SSL cert. 

We'd like to be able to have fine grained MAC, so one could allow rules like

  - client 'a' can start/stop guest 'X'
  - client 'b' can monitor stats of guest 'Y'
  - client 'c' can define new guests / delete existing guests

We've not really investigated the SELinux side in much detail yet, but my
current thoughts are based on knowledge of the way DBus integrates with
SELinux to do MAC on its clients & their API calls.  In the local user case, 
obviously the UNIX user has a corresponding SELinux domain. In the remote 
case, one could map x509 certificate IDs (the remote user's identify) to 
appropriate local SELinux domains.

The libvirt daemon/driver would need calls out to the SELinux APIs for any
of the ACL checks it needs internally. Policy would ensure than when libvirtd
started any VMs (ie qemu processes), the appropriate domain transition would
take place on exec. Once QEMU is running in appropriate domain, policy would
take care of ensuring it only accessed appropriate disks & network interfaces
defined by the config.

The appealing thing to me about trying to get some form of policy at the 
libvirt layer is that to the outside (ie end users) it could provide a
consistent policy for all the different virt platforms supported by libvirt.
Of course the underlying policy for each virt platform is likely radically
different - qemu we deal with directly, Xen we talk to Xend & hypervisor,
OpenVZ we run openvz command line tools. libvirt is all about providing a
consistent management API for all virtualization platforms. Being able to
provide a consistent MAC model alongside that is really desirable to me and
as I see SELinux expand to apps like DBus, PostgreSQL it seems a no-brainer
to also apply it to libvirt (for Linux platforms).

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[James Morris]

On Sat, 21 Jul 2007, Daniel P. Berrange wrote:

> obviously the UNIX user has a corresponding SELinux domain. In the remote 
> case, one could map x509 certificate IDs (the remote user's identify) to 
> appropriate local SELinux domains.

There is already a mechanism for conveying SELinux labels over the network 
via IPsec.


- James
-- 
James Morris
<jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH 00/01]qemu VM entrypoints

[James Morris]

On Fri, 20 Jul 2007, David Windsor wrote:

> One problem with this approach is that loading a VM is not an exec-based
> operation.  Dynamic transitions could be used, but could possibly be avoided
> by altering the patch to fork, then re-exec in the target domain.
> 
> This patch applies cleanly to kvm-userspace trunk.
> 
> Thoughts?

I think we need to ensure that these object classes and permissions 
generalize to similar Linux-based virtualization schemes.  As far as I can 
tell, this particular case should.


- James
-- 
James Morris
<jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/