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

[Stephen Smalley]

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

-- 
Stephen Smalley
National Security Agency