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