On RHEL 5, I got:

security/security_selinux.c: In function 'getContext':
security/security_selinux.c:971: warning: unused parameter 'mgr' [-Wunused-parameter]

* src/security/security_selinux.c (getContext): Mark potentially
unused parameter.

The security manager drivers are not allowed to call back
out to top level security manager APIs, since that results
in recursive mutex acquisition and thus deadlock. Remove
calls to virSecurityManagerGetModel from SELinux / AppArmor
drivers
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Rename all the usbDeviceXXX and usbXXXDevice APIs to have a
fixed virUSBDevice name prefix

Rename all the pciDeviceXXX and pciXXXDevice APIs to have a
fixed virPCIDevice name prefix

According to Eric Paris this is slightly more efficient because it
only loads the regular expressions in libselinux once.

It was possible to call VIR_FREE in cleanup prior to initialization

Commit id a994ef2d changed the mechanism to store/update the default
security label from using disk->seclabels[0] to allocating one on the
fly. That change allocated the label, but never saved it.  This patch
will save the label. The new virDomainDiskDefAddSecurityLabelDef() is
a copy of the virDomainDefAddSecurityLabelDef().

The SELinux security driver needs to learn to label storage/misc
hostdev devices for LXC
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Prepare to support different types of hostdevs by refactoring
the current SELinux security driver code
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When LXC labels USB devices during hotplug, it is running in
host context, so it needs to pass in a vroot path to the
container root.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The virSecurityManager{Set,Restore}AllLabel methods are invoked
at domain startup/shutdown to relabel resources associated with
a domain. This works fine with QEMU, but with LXC they are in
fact both currently no-ops since LXC does not support disks,
hostdevs, or kernel/initrd files. Worse, when LXC gains support
for disks/hostdevs, they will do the wrong thing, since they
run in host context, not container context. Thus this patch
turns then into a formal no-op when used with LXC. The LXC
controller will call out to specific security manager labelling
APIs as required during startup.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The current SELinux policy only works for KVM guests, since
TCG requires the 'execmem' privilege. There is a 'virt_use_execmem'
boolean to turn this on globally, but that is unpleasant for users.
This changes libvirt to automatically use a new 'svirt_tcg_t'
context for TCG based guests. This obsoletes the previous
boolean tunable and makes things 'just work(tm)'

Since we can't assume we run with new enough policy, I also
make us log a warning message (once only) if we find the policy
lacks support. In this case we fallback to the normal label and
expect users to set the boolean tunable
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

In the case of an OOM error in virDomainDefGetSecurityLabelDef, secdef
is set to NULL, then dereferenced while printing the debug message.

The impls of virSecurityManagerGetMountOptions had no way to
return errors, since the code was treating 'NULL' as a success
value. This is somewhat pointless, since the calling code did
not want NULL in the first place and has to translate it into
the empty string "". So change the code so that the impls can
return "" directly, allowing use of NULL for error reporting
once again
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The libvirt coding standard is to use 'function(...args...)'
instead of 'function (...args...)'. A non-trivial number of
places did not follow this rule and are fixed in this patch.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When restoring selinux labels after a VM is stopped, any non-standard
path that doesn't have a default selinux label causes the process
to stop and exit early. This isn't really an error condition IMO.

Of course the selinux API could be erroring for some other reason
but hopefully that's rare enough to not need explicit handling.

Common example here is storing disk images in a non-standard location
like under /mnt.

We used to walk the backing file chain at least twice per disk,
once to set up cgroup device whitelisting, and once to set up
security labeling.  Rather than walk the chain every iteration,
which possibly includes calls to fork() in order to open root-squashed
NFS files, we can exploit the cache of the previous patch.

* src/conf/domain_conf.h (virDomainDiskDefForeachPath): Alter
signature.
* src/conf/domain_conf.c (virDomainDiskDefForeachPath): Require caller
to supply backing chain via disk, if recursion is desired.
* src/security/security_dac.c
(virSecurityDACSetSecurityImageLabel): Adjust caller.
* src/security/security_selinux.c
(virSecuritySELinuxSetSecurityImageLabel): Likewise.
* src/security/virt-aa-helper.c (get_files): Likewise.
* src/qemu/qemu_cgroup.c (qemuSetupDiskCgroup)
(qemuTeardownDiskCgroup): Likewise.
(qemuSetupCgroup): Pre-populate chain.

In commit 9674f2c6, I forgot to change
selabel_lookup with the other functions, so this one-liner does exactly
that.

BZ:https://bugzilla.redhat.com/show_bug.cgi?id=851981
When using macvtap, a character device gets first created by
kernel with name /dev/tapN, its selinux context is:
system_u:object_r:device_t:s0

Shortly, when udev gets notification when new file is created
in /dev, it will then jump in and relabel this file back to the
expected default context:
system_u:object_r:tun_tap_device_t:s0

There is a time gap happened.
Sometimes, it will have migration failed, AVC error message:
type=AVC msg=audit(1349858424.233:42507): avc:  denied  { read write } for
pid=19926 comm="qemu-kvm" path="/dev/tap33" dev=devtmpfs ino=131524
scontext=unconfined_u:system_r:svirt_t:s0:c598,c908
tcontext=system_u:object_r:device_t:s0 tclass=chr_file

This patch will label the tapfd device before qemu process starts:
system_u:object_r:tun_tap_device_t:MCS(MCS from seclabel->label)

We are currently able to work only with non-translated SELinux
contexts, but we are using functions that work with translated
contexts throughout the code.  This patch swaps all SELinux context
translation relative calls with their raw sisters to avoid parsing
problems.

The problems can be experienced with mcstrans for example.  The
difference is that if you have translations enabled (yum install
mcstrans; service mcstrans start), fgetfilecon_raw() will get you
something like 'system_u:object_r:virt_image_t:s0', whereas
fgetfilecon() will return 'system_u:object_r:virt_image_t:SystemLow'
that we cannot parse.

I was trying to confirm that the _raw variants were here since the dawn of
time, but the only thing I see now is that it was imported together in
the upstream repo [1] from svn, so before 2008.

Thanks Laurent Bigonville for finding this out.

[1] http://oss.tresys.com/git/selinux.git

All USB device lookup functions emit an error when they cannot find the
requested device. With this patch, their caller can choose if a missing
device is an error or normal condition.

This allows the user to control labelling of each character device
separately (the default is to inherit from the VM).
Signed-off-by: NRichard W.M. Jones <rjones@redhat.com>

https://www.gnu.org/licenses/gpl-howto.html recommends that
the 'If not, see <url>.' phrase be a separate sentence.

* tests/securityselinuxhelper.c: Remove doubled line.
* tests/securityselinuxtest.c: Likewise.
* globally: s/;  If/.  If/

Currently the dynamic label generation code will create labels
with a sensitivity of s0, and a category pair in the range
0-1023. This is fine when running a standard MCS policy because
libvirtd will run with a label

  system_u:system_r:virtd_t:s0-s0:c0.c1023

With custom policies though, it is possible for libvirtd to have
a different sensitivity, or category range. For example

  system_u:system_r:virtd_t:s2-s3:c512.c1023

In this case we must assign the VM a sensitivity matching the
current lower sensitivity value, and categories in the range
512-1023
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The code to refactor sec label handling accidentally changed the
SELinux driver to use the 'domain_context' when generating the
image label instead of the 'file_context'
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

These changes make the security drivers able to find and handle the
correct security label information when more than one label is
available. They also update the DAC driver to be used as an usual
security driver.
Signed-off-by: NMarcelo Cerri <mhcerri@linux.vnet.ibm.com>

This patch updates the structures that store information about each
domain and each hypervisor to support multiple security labels and
drivers. It also updates all the remaining code to use the new fields.
Signed-off-by: NMarcelo Cerri <mhcerri@linux.vnet.ibm.com>

This is a fix for the object label generation. It uses a new flag for
virSecuritySELinuxGenNewContext that specifies whether the context is
for an object. If so the context role remains unchanged.
Without this fix it is not possible to start domains with image file or
block device backed storage when selinux is enabled.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

The code for picking a MCS label is about to get significantly
more complicated, so it deserves to be in a standlone method,
instead of a switch/case body.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When generating an SELinux context for a VM from the template
"system_u:system_r:svirt_t:s0", copy the role + user from the
current process instead of the template context. So if the
current process is

   unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

then the VM context ends up as

  unconfined_u:unconfined_r:svirt_t:s0:c386,c703

instead of

   system_u:system_r:svirt_t:s0:c177,c424

Ideally the /etc/selinux/targeted/contexts/virtual_domain_context
file would have just shown the 'svirt_t' type, and not the full
context, but that can't be changed now for compatibility reasons.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>