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.

The functions virGetUserID and virGetGroupID are now able to parse
user/group names and IDs in a similar way to coreutils' chown. So, user
and group parsing in security_dac can be simplified.

The DAC driver is missing parsing of group and user names for DAC labels
and currently just parses uid and gid. This patch extends it to support
names, so the following security label definition is now valid:

  <seclabel type='static' model='dac' relabel='yes'>
      <label>qemu:qemu</label>
      <imagelabel>qemu:qemu</imagelabel>
  </seclabel>

When it tries to parse an owner or a group, it first tries to resolve it as
a name, if it fails or it's an invalid user/group name then it tries to
parse it as an UID or GID. A leading '+' can also be used for both owner and
group to force it to be parsed as IDs, so the following example is also
valid:

  <seclabel type='static' model='dac' relabel='yes'>
      <label>+101:+101</label>
      <imagelabel>+101:+101</imagelabel>
  </seclabel>

This ensures that UID 101 and GUI 101 will be used instead of an user or
group named "101".

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/

The DAC security driver silently ignored errors when parsing the DAC
label and used default values instead.

With a domain containing the following label definition:

<seclabel type='static' model='dac' relabel='yes'>
  <label>sdfklsdjlfjklsdjkl</label>
</seclabel>

the domain would start normaly but the disk images would be still owned
by root and no error was displayed.

This patch changes the behavior if the parsing of the label fails (note
that a not present label is not a failure and in this case the default
label should be used) the error isn't masked but is raised that causes
the domain start to fail with a descriptive error message:

virsh #  start tr
error: Failed to start domain tr
error: internal error invalid argument: failed to parse DAC seclabel
'sdfklsdjlfjklsdjkl' for domain 'tr'

I also changed the error code to "invalid argument" from "internal
error" and tweaked the various error messages to contain correct and
useful information.

Recent changes in the security driver discarded changes that fixed
labeling un-confined guests.

If no 'security_driver' config option was set, then the code
just loaded the 'dac' security driver. This is a regression
on previous behaviour, where we would probe for a possible
security driver. ie default to SELinux if available.

This changes things so that it 'security_driver' is not set,
we once again do probing. For simplicity we also always
create the stack driver, even if there is only one driver
active.

The desired semantics are:

 - security_driver not set
     -> probe for selinux/apparmour/nop
     -> auto-add DAC driver
 - security_driver set to a string
     -> add that one driver
     -> auto-add DAC driver
 - security_driver set to a list
     -> add all drivers in list
     -> auto-add DAC driver

It is not allowed, or possible to specify 'dac' in the
security_driver config param, since that is always
enabled.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

This reverts commit 9f9b7b85.

The DAC security driver needs special handling and extra parameters and
can't just be added to regular security drivers.

* src/security/security_dac.c: remove useless dead code.
Signed-off-by: NAlex Jia <ajia@redhat.com>

As in the previous commit, images are also chowned to uninitialised
uid and gid if the label is not present.

When starting a machine the DAC security driver tries to set the UID and
GID of the newly spawned process. This worked as desired if the desired
label was set. When the label was missing a logical bug in
virSecurityDACGenLabel() caused that uninitialised values were used as
uid and gid for the new process.

With this patch, default values (from qemu driver configuration)
are used if the label is not found.

When no DAC "label" was requested for a domain the DAC manager tried to
strdup a NULL string causing a segfault.

Currently, if users set 'security_driver="dac"' in qemu.conf libvirtd
fails to initialize as DAC driver is not found because it is missing
in our security drivers array.

The DAC security driver uses the virStrToLong_ui function to
parse the uid/gid out of the seclabel string. This works on
Linux where 'uid_t' is an unsigned int, but on Mingw32 it is
just an 'int'. This causes compiler warnings about signed/
unsigned int pointer mis-match.

To avoid this, use explicit 'unsigned int ouruid' local
vars to pass into virStrToLong_ui, and then simply assign
to the 'uid_t' type after parsing
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

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>

The virSecuritySELinuxGenNewContext method was not reporting any
errors, leaving it up to the caller to report a generic error.
In addition it could potentially trigger a strdup(NULL) in an
OOM scenario. Move all error reporting into the
virSecuritySELinuxGenNewContext method where accurate info
can be provided
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

There is currently no way to distinguish the case that a requested
security driver was disabled, from the case where no security driver
was available. Use VIR_ERR_CONFIG_UNSUPPORTED as the error when an
explicitly requested security driver was disabled
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The security_manager.h header is not self-contained because it
uses the virDomainDefPtr without first including domain_conf.h
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

All callers used the same initialization seed (well, the new
viratomictest forgot to look at getpid()); so we might as well
make this value automatic.  And while it may feel like we are
giving up functionality, I documented how to get it back in the
unlikely case that you actually need to debug with a fixed
pseudo-random sequence.  I left that crippled by default, so
that a stray environment variable doesn't cause a lack of
randomness to become a security issue.

* src/util/virrandom.c (virRandomInitialize): Rename...
(virRandomOnceInit): ...and make static, with one-shot call.
Document how to do fixed-seed debugging.
* src/util/virrandom.h (virRandomInitialize): Drop prototype.
* src/libvirt_private.syms (virrandom.h): Don't export it.
* src/libvirt.c (virInitialize): Adjust caller.
* src/lxc/lxc_controller.c (main): Likewise.
* src/security/virt-aa-helper.c (main): Likewise.
* src/util/iohelper.c (main): Likewise.
* tests/seclabeltest.c (main): Likewise.
* tests/testutils.c (virtTestMain): Likewise.
* tests/viratomictest.c (mymain): Likewise.

If a domain is explicitly configured with <seclabel type="none"/> we
correctly ensure that no labeling will be done by setting
norelabel=true. However, if no seclabel element is present in domain XML
and hypervisor is configured not to confine domains by default, we only
set type to "none" without turning off relabeling. Thus if such a domain
is being started, security driver wants to relabel resources with
default label, which doesn't make any sense.

Moreover, with SELinux security driver, the generated image label lacks
"s0" sensitivity, which causes setfilecon() fail with EINVAL in
enforcing mode.

This is a follow up patch of commit f9ce7dad, it modifies all
the files which declare the copyright like "See COPYING.LIB for
the License of this software" to use the detailed/consistent one.

And deserts the outdated comments like:

 * libvirt-qemu.h:
 * Summary: qemu specific interfaces
 * Description: Provides the interfaces of the libvirt library to handle
 *              qemu specific methods
 *
 * Copy:  Copyright (C) 2010, 2012 Red Hat, Inc.

Uses the more compact style like:

 * libvirt-qemu.h: Interfaces specific for QEMU/KVM driver
 *
 * Copyright (C) 2010, 2012 Red Hat, Inc.

Per the FSF address could be changed from time to time, and GNU
recommends the following now: (http://www.gnu.org/licenses/gpl-howto.html)

  You should have received a copy of the GNU General Public License
  along with Foobar.  If not, see <http://www.gnu.org/licenses/>.

This patch removes the explicit FSF address, and uses above instead
(of course, with inserting 'Lesser' before 'General').

Except a bunch of files for security driver, all others are changed
automatically, the copyright for securify files are not complete,
that's why to do it manually:

  src/security/security_selinux.h
  src/security/security_driver.h
  src/security/security_selinux.c
  src/security/security_apparmor.h
  src/security/security_apparmor.c
  src/security/security_driver.c

Instead of using an O(n) efficiency linked list for storing
MCS labels, use a hash table. Instead of having the list
be global, put it in the SELinux driver private data struct
to ensure uniqueness across different instances of the driver.
This also ensures thread safety when multiple hypervisor
drivers are used in the same libvirtd process
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When adding MCS labels, OOM was not being handled correctly.
In addition when reserving an existing label, no check was
made to see if it was already reserved
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The function names in the SELinux driver all start with
SELinux or 'mcs' as a prefix. Sanitize this so that they
all use 'virSecuritySELinux' as the prefix
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Update the security drivers to use virReportError instead of
the virSecurityReportError custom macro
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Noticed during the recent error cleanups.

* src/network/bridge_driver.c (networkStartRadvd): Fix spacing.
* src/openvz/openvz_conf.c (openvzReadMemConf): Likewise.
* src/qemu/qemu_command.c (qemuNetworkIfaceConnect): Likewise.
* src/qemu/qemu_hotplug.c (qemuDomainDetachNetDevice): Likewise.
* src/qemu/qemu_process.c (qemuProcessStop): Likewise.
* src/security/virt-aa-helper.c (vah_add_file): Likewise.

Remove a number of pointless checks against PATH_MAX and
add a syntax-check rule to prevent its use in future
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>