build: remove MCS SELinux labels from built image

[dustymabe]

If we don't do this we end up with an image with MCS labels which means
that a subsequent run of a container (i.e. coreos-assembler run) will
fail.

With this we go from:

system_u:object_r:container_file_t:s0:c255,c505

to:

system_u:object_r:container_file_t:s0

Fixes #292

[cgwalters]

Hmmm....right, from #292 (comment)
it must be related to libvirt doing SVirt.

I imagine we could tell libvirt to disable svirt? In my dev environment I'm seeing:

$ virsh dominfo 1
Name:           coreos-inst-4507-1548362421
...
Security model: none

And I just verified I'm not seeing this issue (and am seeing the Security model: none) with the official container (although mine is a bit out of date and the hotel wifi here is terrible).

[dustymabe]

yeah. my original patch for this added something like --security none to the virt-install invocation, but that either didn't work or the subsequent libguestfs calls still caused the file to have MCS labels. This patch is what I ended up with without digging into a ball of wax.

[dustymabe]

@cgwalters - WDYT? is it possible I'm doing something wrong?

[cgwalters]

I guess what I need to understand about this is whether it's specific to the unprivileged path - things have been working for me privileged. I'll test that other PR. libvirt shouldn't be doing the chmod regardless with our setup.

[dustymabe]

I guess what I need to understand about this is whether it's specific to the unprivileged path - things have been working for me privileged. I'll test that other PR. libvirt shouldn't be doing the chmod regardless with our setup.

maybe: moby/moby@b63ce33 ?

[rfairley]

LGTM - working well on my end after build with the script mounted and coreos-assembler run (previously gave avc denial).

[dustymabe]

thanks @rfairley - merging now.