[libvirt] Printing runtime DAC seclabel in the XML

Fri Apr 22 05:28:40 UTC 2016

On Thu, Apr 21, 2016 at 10:16:41AM -0400, Cole Robinson wrote:
>On 04/21/2016 06:08 AM, Martin Kletzander wrote:
>> On Wed, Apr 20, 2016 at 07:57:05PM -0400, Cole Robinson wrote:
>>> I'm looking in the code to see why runtime VM dac seclabel values aren't
>>> printed in the active XML. They are filled in, but the domain XML formatter
>>> explicitly skips it:
>>>
>>>    /* To avoid backward compatibility issues, suppress DAC and 'none' labels
>>>     * that are automatically generated.
>>>     */
>>>    if ((STREQ_NULLABLE(def->model, "dac") ||
>>>         STREQ_NULLABLE(def->model, "none")) && def->implicit)
>>>        return;
>>>
>>> The relevant bit is from here:
>>>
>>> commit 990e46c4542349f838e001d30638872576c389e9
>>> Author: Marcelo Cerri <mhcerri at linux.vnet.ibm.com>
>>> Date:   Fri Aug 31 13:40:41 2012 +0200
>>>
>>>    conf: Avoid formatting auto-generated DAC labels
>>>
>>> And I think comment elsewhere in domain_conf.c explains what that's all about:
>>>
>>>    /* libvirt versions prior to 0.10.0 support just a single seclabel element
>>>     * in guest's XML and model attribute can be suppressed if type is none or
>>>     * type is dynamic, baselabel is not defined and INACTIVE flag is set.
>>>     *
>>>     * To avoid compatibility issues, for this specific case the first model
>>>     * defined in host's capabilities is used as model for the seclabel.
>>>     */
>>>
>>> Just dropping the the model == "dac" check above seems to accomplish what I'm
>>> after, but it's not strictly back compatible. That said, libvirt has supported
>>
>> I think this has nothing to do with backward compatibility, but forward
>> compatibility (which we care about for "some" time).
>>
>
>That's not my reading of the patch + thread. I think it was that new libvirt
>starting printing two <seclabel> blocks for active XML. If you then do a
>managedsave, downgrade libvirt, and attempt a restore (or live migration to an
>older version), old libvirt errors when it sees 2 <seclabel> blocks. So back
>compat here to me meant 'generate XML that old libvirt will accept'
>

Yes, so we have the same understanding, but the terminology is
confusing.  Backward compatibility is about supporting old
XML/API/whatever in new libvirt.  Forward compatibility means old
libvirt will work with newer XML/API/whatever.

To be even surer, I checked Wikipedia [1] =)

So we are talking about the same thing.  And about that, I don't think
we need to care about older libvirt.  Most of the XMLs won't work
because of other things anyway.  Especially versions lower than 0.10.0
as oldest CentOS we consider supported has 0.10.2 IIRC and most requests
and bugreports for other distros are from newer versions as well.

>> What are you trying to achieve?  It works for me, the default seclabel
>> is not exposed, but if I change it, it is dumped for running, shut-off
>> or whatever domain there is.
>>
>
>the issue: start a VM with no explicit seclabel config, dump the running XML,
>you'll see something like this:
>
>  <seclabel type='dynamic' model='selinux' relabel='yes'>
>    <label>unconfined_u:unconfined_r:svirt_t:s0:c325,c747</label>
>    <imagelabel>unconfined_u:object_r:svirt_image_t:s0:c325,c747</imagelabel>
>  </seclabel>
>
>but no <seclabel> block for DAC labels, which seems inconsistent
>

Well, this is just about the point of view.  SELinux labels are
dynamically generated and the user cannot predict what the categories
will be and so on.  But for DAC, the domain will be running under the
default user and group set in qemu.conf.

Don't get me wrong, I'm all for exposing all the labels, but I see one
problem with that that we need to make sure is deal with.  Currently, if
you change the default in qemu.conf it will apply to all your domains.
However, if we add it there and save it to the disk, the default uid:gid
won't follow the change in qemu.conf even if it was just left at the
default state.

>>> multiple seclabels for a loooong time now, so I wonder do we even care? Do we
>>
>> Probably migration to older versions, but I'm not sure that there's that
>> many people who care about it.  And it won't work because of other
>> things too -- I think it's just not supported use-case anyway.
>>
>>> have a target for how far back we try to maintain XML compat? Or does anyone
>>> else have other ideas?
>>>
>>
>> Back-compat has now something like a 10½ years now and I think it will
>> reach around 15 in next 5 years...
>>
>
>I should have been more explicit. Certainly for things like XML input we aim
>to maintain back compat to the beginning, which is why tools like virt-install
>can reliably work across versions.
>
>In this case though I meant XML output back compat/migration back compat: do
>we still think it's a worthy goal to maintain XML output compat with libvirt
><= 0.10.0 ? (and if so, I imagine there's a better place to handle this...
>somewhere migration specific? but I'm not really familiar with the latest
>infrastructure for that)
>

Again, back-compat will stay.  But in the future-compat scenario, I
honestly wouldn't care about <=0.10.0, most of the code doesn't even
care about <=1.3.0.

Have a nice day,
Martin

[1] https://en.wikipedia.org/wiki/Backward_compatibility
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160422/278be2db/attachment-0001.sig>