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
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list