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
--
Stephen Smalley
National Security Agency