Re: [libvirt] [PATCH 6/6] Try much harder to restore disk file labels

On Tue, 2009-09-01 at 18:10 +0100, Daniel P. Berrange wrote: > On Tue, Sep 01, 2009 at 01:00:13PM -0400, Stephen Smalley wrote: > > On Tue, 2009-09-01 at 16:28 +0100, Daniel P. Berrange wrote: > > > * src/security_selinux.c: matchpath() may well return NULL for many > > > directories, to try and fallback to using parent directory label > > > in that scenario. > > > > When have you seen this happen? matchpathcon() ultimately should fall > > back to the top-level regex (/.*) and map any otherwise unmatched files > > to default_t, and should generally have a fallback regex for each > > subtree (e.g. any file under /dev that isn't otherwise matched would get > > device_t). So I wouldn't expect this to happen. > > That describes what I always imagined would happen, but in my recent > testing it doesn't appear to be doing that in practice in some cases > > eg, running matchpathcon("/media/usbdisk/virtual-images/demo.img") returned > an error. Likewise for /sys/bus/pci/devices/NNNN.NN.NN.NN/*. I was testing > this on a Fedora 11 host. Perhaps the policy is simply missing some rules Ah, I had forgotten about the behavior in the case where the path is marked with <<none>> in the file_contexts configuration, in which case matchpathcon() does return NULL as you describe. That gets used for two situations: - mount point directories for filesystems that do not support labeling, like /sys and /selinux. That should be obsoleted by the support in kernels >= 2.6.30 to report seclabel support in /proc/mounts, which gets used by setfiles when available. So we can likely remove those <<none>> entries going forward. - directories that contain runtime-created files whose labels we do not wish to reset, like /tmp or /var/run. Those entries are still necessary to avoid clobbering runtime labels on such files upon a relabel. So I guess you do need this.

> > Also, files will inherit their SELinux type from the parent directory by > > default upon creation unless a type transition rule is specified, so it > > isn't clear why you need to replicate this copying from parent behavior > > in the application. > > This code is being run upon VM shutdown, to get rid of the dynamic label > that was assigned at VM startup. THe file already exists, so the default > rule for file creation wouldn't come into effect at this point, so I was > aiming to replicate that behaviour for the existing file. > > If we could guarentee that matchpathcon($PATH) would always return > something usable, I would happily kill this code