Re: [libvirt] None seclabel question

2012-09-04 Thread Daniel P. Berrange
On Mon, Sep 03, 2012 at 12:57:50PM -0300, Marcelo Cerri wrote:
 Hi,
 
 I was discussing with Jiri Denemark about the current behavior of
 none seclabels with multiple security drivers and I'd like to hear
 more opinions about how this should work.
 
 Currently, a none security label can be defined specifically to each
 enabled security driver. For example, using a default configuration
 (in which SELinux is enabled as default driver and DAC is enabled
 due to privileged mode), a guest definition can contain the
 following seclabel:
 
 seclabel type='none' model='selinux'/
 
 This will disable SELinux labeling and will keep labeling enabled
 for any other security drivers (DAC in this case).
 
 So, my question is: should none seclabels affect specific drivers
 (as done now) or just one none seclabel should be accepted affecting
 all security drivers in use?

No, as with your example above, the type=none is scoped to a specific
driver.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] None seclabel question

2012-09-04 Thread Jiri Denemark
On Tue, Sep 04, 2012 at 10:22:56 +0100, Daniel P. Berrange wrote:
 On Mon, Sep 03, 2012 at 12:57:50PM -0300, Marcelo Cerri wrote:
  Hi,
  
  I was discussing with Jiri Denemark about the current behavior of
  none seclabels with multiple security drivers and I'd like to hear
  more opinions about how this should work.
  
  Currently, a none security label can be defined specifically to each
  enabled security driver. For example, using a default configuration
  (in which SELinux is enabled as default driver and DAC is enabled
  due to privileged mode), a guest definition can contain the
  following seclabel:
  
  seclabel type='none' model='selinux'/
  
  This will disable SELinux labeling and will keep labeling enabled
  for any other security drivers (DAC in this case).
  
  So, my question is: should none seclabels affect specific drivers
  (as done now) or just one none seclabel should be accepted affecting
  all security drivers in use?
 
 No, as with your example above, the type=none is scoped to a specific
 driver.

And what happens if you have older libvirt and a domain configured with
seclabel type='none'/ and upgrade libvirt to the state when it actually
enables more than one security driver at a time. Shouldn't such generic
seclabel type='none'/ actually turn off any labeling, that is, affect all
the enabled drivers?

Jirka

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] None seclabel question

2012-09-04 Thread Daniel P. Berrange
On Tue, Sep 04, 2012 at 11:28:19AM +0200, Jiri Denemark wrote:
 On Tue, Sep 04, 2012 at 10:22:56 +0100, Daniel P. Berrange wrote:
  On Mon, Sep 03, 2012 at 12:57:50PM -0300, Marcelo Cerri wrote:
   Hi,
   
   I was discussing with Jiri Denemark about the current behavior of
   none seclabels with multiple security drivers and I'd like to hear
   more opinions about how this should work.
   
   Currently, a none security label can be defined specifically to each
   enabled security driver. For example, using a default configuration
   (in which SELinux is enabled as default driver and DAC is enabled
   due to privileged mode), a guest definition can contain the
   following seclabel:
   
   seclabel type='none' model='selinux'/
   
   This will disable SELinux labeling and will keep labeling enabled
   for any other security drivers (DAC in this case).
   
   So, my question is: should none seclabels affect specific drivers
   (as done now) or just one none seclabel should be accepted affecting
   all security drivers in use?
  
  No, as with your example above, the type=none is scoped to a specific
  driver.
 
 And what happens if you have older libvirt and a domain configured with
 seclabel type='none'/ and upgrade libvirt to the state when it actually
 enables more than one security driver at a time. Shouldn't such generic
 seclabel type='none'/ actually turn off any labeling, that is, affect all
 the enabled drivers?

IMHO with the old libvirt, if no model= was set, this was implicitly
refering to the current model.


Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] None seclabel question

2012-09-04 Thread Jiri Denemark
On Tue, Sep 04, 2012 at 10:31:54 +0100, Daniel P. Berrange wrote:
 On Tue, Sep 04, 2012 at 11:28:19AM +0200, Jiri Denemark wrote:
  On Tue, Sep 04, 2012 at 10:22:56 +0100, Daniel P. Berrange wrote:
   On Mon, Sep 03, 2012 at 12:57:50PM -0300, Marcelo Cerri wrote:

So, my question is: should none seclabels affect specific drivers
(as done now) or just one none seclabel should be accepted affecting
all security drivers in use?
   
   No, as with your example above, the type=none is scoped to a specific
   driver.
  
  And what happens if you have older libvirt and a domain configured with
  seclabel type='none'/ and upgrade libvirt to the state when it actually
  enables more than one security driver at a time. Shouldn't such generic
  seclabel type='none'/ actually turn off any labeling, that is, affect all
  the enabled drivers?
 
 IMHO with the old libvirt, if no model= was set, this was implicitly
 refering to the current model.

Yes, but there was just one model, thus it trivially affected all enabled
models. Also its semantics can be understood as do no labeling no matter what
security model is used. I'm mainly concerned about libvirt upgrades while
domains with seclabel type='none'/ are running.

Jirka

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] None seclabel question

2012-09-04 Thread Daniel P. Berrange
On Tue, Sep 04, 2012 at 12:00:33PM +0200, Jiri Denemark wrote:
 On Tue, Sep 04, 2012 at 10:31:54 +0100, Daniel P. Berrange wrote:
  On Tue, Sep 04, 2012 at 11:28:19AM +0200, Jiri Denemark wrote:
   On Tue, Sep 04, 2012 at 10:22:56 +0100, Daniel P. Berrange wrote:
On Mon, Sep 03, 2012 at 12:57:50PM -0300, Marcelo Cerri wrote:
 
 So, my question is: should none seclabels affect specific drivers
 (as done now) or just one none seclabel should be accepted affecting
 all security drivers in use?

No, as with your example above, the type=none is scoped to a specific
driver.
   
   And what happens if you have older libvirt and a domain configured with
   seclabel type='none'/ and upgrade libvirt to the state when it actually
   enables more than one security driver at a time. Shouldn't such generic
   seclabel type='none'/ actually turn off any labeling, that is, affect 
   all
   the enabled drivers?
  
  IMHO with the old libvirt, if no model= was set, this was implicitly
  refering to the current model.
 
 Yes, but there was just one model, thus it trivially affected all enabled
 models. Also its semantics can be understood as do no labeling no matter what
 security model is used. I'm mainly concerned about libvirt upgrades while
 domains with seclabel type='none'/ are running.

I don't think that description of existing behaviour is accurate. With old
libvirt you have one seclabel (for SELinux/AppArmour), but secretly there
are 2 security drivers (SELinux/AppArmour + DAC). Setting type=none for
the seclabel only meant that the SELinux/AppArmour drivers ran the guest
unconfined. The second (DAC) driver would still be applied to the guest
making it run unprivileged/confined.

What actual problem have you seen with upgrades ?

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] None seclabel question

2012-09-04 Thread Jiri Denemark
On Tue, Sep 04, 2012 at 11:14:35 +0100, Daniel P. Berrange wrote:
 On Tue, Sep 04, 2012 at 12:00:33PM +0200, Jiri Denemark wrote:
 
 I don't think that description of existing behaviour is accurate. With old
 libvirt you have one seclabel (for SELinux/AppArmour), but secretly there
 are 2 security drivers (SELinux/AppArmour + DAC). Setting type=none for
 the seclabel only meant that the SELinux/AppArmour drivers ran the guest
 unconfined. The second (DAC) driver would still be applied to the guest
 making it run unprivileged/confined.

Isn't DAC still applied in the same way?

 What actual problem have you seen with upgrades ?

I don't see any actual problem, I'm just trying to think about them :-) Let's
say there's a domain running with seclabel type='none'/ while libvirtd is
upgraded and reconfigured to enable more seclabels by default (a very
theoretical example could be [ selinux, apparmor ]. I think neither
selinux nor apparmor labeling should be applied for that domain. Or am I
wrong?

Jirka

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] None seclabel question

2012-09-04 Thread Daniel P. Berrange
On Tue, Sep 04, 2012 at 01:43:43PM +0200, Jiri Denemark wrote:
 On Tue, Sep 04, 2012 at 11:14:35 +0100, Daniel P. Berrange wrote:
  On Tue, Sep 04, 2012 at 12:00:33PM +0200, Jiri Denemark wrote:
  
  I don't think that description of existing behaviour is accurate. With old
  libvirt you have one seclabel (for SELinux/AppArmour), but secretly there
  are 2 security drivers (SELinux/AppArmour + DAC). Setting type=none for
  the seclabel only meant that the SELinux/AppArmour drivers ran the guest
  unconfined. The second (DAC) driver would still be applied to the guest
  making it run unprivileged/confined.
 
 Isn't DAC still applied in the same way?
 
  What actual problem have you seen with upgrades ?
 
 I don't see any actual problem, I'm just trying to think about them :-) Let's
 say there's a domain running with seclabel type='none'/ while libvirtd is
 upgraded and reconfigured to enable more seclabels by default (a very
 theoretical example could be [ selinux, apparmor ]. I think neither
 selinux nor apparmor labeling should be applied for that domain. Or am I
 wrong?

When I think of upgrade issues, i consider the scenario where the new
libvirt is configured in the same way as the old livirt, and we need
to make sure the guest behaviour remains the same. This scenario you
describe obviously doesn't fall under that, since you're enabling new
behaviour that was not previously possible. I so don't think that is
an upgrade problem, but rather just a case of defining what the new
behaviour should be.

IMHO, the behaviour is thus

 - A single seclabel with no model=XXX attribute, refers to the first
   security driver
 - Multiple seclabel with explicit model=XXX attributes refer to the
   corresponding driver
 - Multiple seclabel with no model=XX - forbidden config

If you want to set behaviour for the secondary, or tertiary security
drivers then you are required to provide multiple seclabel elements
with explicit model= attributes. We shouldn't try to abuse a single
seclabel element to set properties against multiple security drivers.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] None seclabel question

2012-09-04 Thread Jiri Denemark
On Tue, Sep 04, 2012 at 12:50:55 +0100, Daniel P. Berrange wrote:
 When I think of upgrade issues, i consider the scenario where the new
 libvirt is configured in the same way as the old livirt, and we need
 to make sure the guest behaviour remains the same. This scenario you
 describe obviously doesn't fall under that, since you're enabling new
 behaviour that was not previously possible. I so don't think that is
 an upgrade problem, but rather just a case of defining what the new
 behaviour should be.
 
 IMHO, the behaviour is thus
 
  - A single seclabel with no model=XXX attribute, refers to the first
security driver
  - Multiple seclabel with explicit model=XXX attributes refer to the
corresponding driver
  - Multiple seclabel with no model=XX - forbidden config
 
 If you want to set behaviour for the secondary, or tertiary security
 drivers then you are required to provide multiple seclabel elements
 with explicit model= attributes. We shouldn't try to abuse a single
 seclabel element to set properties against multiple security drivers.

Fair enough and works for me :-) We ended up with a clearly defined behavior,
which is worth including in formatdomain.html

Jirka

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] None seclabel question

2012-09-03 Thread Marcelo Cerri

Hi,

I was discussing with Jiri Denemark about the current behavior of none 
seclabels with multiple security drivers and I'd like to hear more 
opinions about how this should work.


Currently, a none security label can be defined specifically to each 
enabled security driver. For example, using a default configuration (in 
which SELinux is enabled as default driver and DAC is enabled due to 
privileged mode), a guest definition can contain the following seclabel:


seclabel type='none' model='selinux'/

This will disable SELinux labeling and will keep labeling enabled for 
any other security drivers (DAC in this case).


So, my question is: should none seclabels affect specific drivers (as 
done now) or just one none seclabel should be accepted affecting all 
security drivers in use?


Regards,
Marcelo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list