Hi Stefan,
The SELinux policy may need to be updated to accommodate the access.
Following is a summary of the general procedure in practical terms
for handling simple issues with existing policy like the one you
describe (other more complex problems would likely require
additional actions).
Look for the corresponding avc denial in the audit record. It will
tell you how the subject and object are labeled, the object class
to which access is being attempted, and the requested permission.
If the labels don't appear to be correct, try to fix them with
restorecon. If the label is incorrect in the policy, add a new
context rule with semanage fcontext and set it with restorecon.
If labels are way off, perhaps relabel the filesystem with touch
/.autorelabel reboot. If things appear to be labeled correctly
and the access is desirable, then look for a boolean to flip on in
the policy with getsebool -a. It's also helpful to search for an
allow rule with sesearch or to look at the suspect source policy
modules. You can distinguish between Type Enforcement and MCS
denials with audit2why. If it looks like a new allow rule is
necessary, take a stab at generating a small module with
audit2allow -M newmodulename and install it with
semodule -i newmodulename. The avc record should no longer
appear in the audit trail when the operation is performed. If you
needed any file labeling changes, create a corresponding .fc file
and rebuild the module. There's a ready made build environment in
/usr/share/selinux/devel. Refine the policy as possible using
interface macros, rebuild and reinstall iteratively. When
you're satisfied with the policy, upstream it to SELinux
maintainers.
As Laine mentioned, if there's a permanent code fix to the issue
you're addressing, it's better to use that and minimize privilege by
limiting the SELinux policy addition to a single affected release.
Regards,
George Wilson
IBM Linux Technology Center
Security Architect Team Lead
512-286-9271
Stefan Hajnoczi
stefanha@gmail.c
omTo
la...@laine.org
03/09/2012 05:32 cc
AMlibvir-list@redhat.com, qemu-devel
qemu-de...@nongnu.org, Paolo
Bonzini pbonz...@redhat.com,
Daniel P. Berrange
berra...@redhat.com, Khoa
Huynh/Austin/IBM@IBMUS, George
Wilson/Austin/IBM@IBMUS
Subject
QEMU fstatfs(2) and libvirt SELinux
policy
Hi,
I have a question about the libvirt SELinux policy that can be applied
to QEMU processes. Yesterday Laine helped Khoa and me diagnose an
issue where QEMU was doing fstatfs(2) but SELinux prevented this
FILESYSTEM__GETATTR operation, resulting in a failed syscall with
-EACCES. The SELinux hook is:
security/selinux/hooks.c:selinux_sb_statfs():
return superblock_has_perm(cred, dentry-d_sb,
FILESYSTEM__GETATTR, ad);
It turns out this problem also affects XFS discard support in QEMU
today. QEMU calls platform_test_xfs_fd() in libxfs, which works like
this:
static __inline__ int platform_test_xfs_fd(int fd)
{
struct statfs buf;
if (fstatfs(fd, buf) 0)
return 0;
return (buf.f_type == 0x58465342); /* XFSB */
}
In other words, XFS detection will fail when SELinux is enabled.
I'm not familiar with libvirt's use of SELinux. Can someone explain
if we need to expand the policy in libvirt and how to do that?
Thanks,
Stefan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
