Hide Forgot
Description of problem: libvirt needs to use hugetlbfs as the backing store for KVM guest RAM. With sVirt, every KVM guest runs under a dedicated security context. To prevent guests accessing each other's RAM, we need to label files on hugetlbfs matching each guest. This was possible on 2.6.29 kernels # mount -t hugetlbfs none /mnt/ # cd /mnt # touch foo bar # chcon system_u:object_r:svirt_image_t:s0:c500 bar # ls -lZ -rw-r--r--. root root system_u:object_r:svirt_image_t:s0:c500 bar -rw-r--r--. root root system_u:object_r:hugetlbfs_t:s0 foo # uname -r 2.6.29.6-213.fc11.i686.PAE But no longer works on 2.6.30 # mount -t hugetlbfs none /mnt/ # cd /mnt # touch foo bar # chcon system_u:object_r:svirt_image_t:s0:c500 bar chcon: failed to change context of `bar' to `system_u:object_r:svirt_image_t:s0:c500': Operation not supported # ls -lZ -rw-r--r--. root root system_u:object_r:hugetlbfs_t:s0 bar -rw-r--r--. root root system_u:object_r:hugetlbfs_t:s0 foo # uname -r 2.6.31-0.118.rc5.fc12.x86_64 There is an explanation for this here: http://www.redhat.com/archives/libvir-list/2009-July/msg00915.html [quote Sephen Smalley] > There is a vfs fallback for setxattr of the security.* namespace to the > security module, which would work for hugetlbfs if not for the fact that > policy defines it as a genfscon-labeled filesystem. We only started > prohibiting setxattr on genfscon-labeled filesystems in 2.6.30; prior to > that we only did that for mountpoint-labeled filesystems. I can > actually chcon a file in a hugetlbfs mount on 2.6.29. > To convert hugetlbfs to fully support labeling we'd need > hugetlbfs_mknod() to call security_inode_init_security() to set up new > inode security labels, just like shmem_mknod() does for tmpfs. And then > we'd need to switch over the policy from genfscon to fs_use_trans. [/quote] Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
The attached patch restores the ability to {set,get}xattr(2) on hugetlbfs inodes in 2.6.31-rc5 which should resolve this case. A tad more infrastructure needed to be pulled in to support this functionality -- patch is attached but has yet to be laundered upstream. Also required is a modification of: serefpolicy-3.5.*/policy/modules/kernel/filesystem.te to change hugetlbfs from genfscon to fs_use_xattr (Daniel Walsh has captured the details). Without this modification selinux in enforcing mode will still disallow set/get of inode xattrs.
Created attachment 357394 [details] Patch to resolve case relative to 2.6.31-rc5
John, could you post the latest status on this here? thanks
Since creating the fix captured in the above patch I discovered there was another effort in flight which addressed hubetlbfs xattr support but was more comprehensive in scope. I was unsure whether this fix hit F12 beta as of kernel-2.6.31-0.125.4.2.rc5.git2.fc12.x86_64 however testing showed the problem still exists here. Unfortunately no upstream fix is available to backport as the earlier effort apparently was abandoned. In the process of moving/verifying the above patch to 2.6.31-0.125.4.2.rc5.git2.fc12, tripping over a few build issues. I believe this fix to be low-risk, localized to hugetlbfs, and is simply reenabling previously existing functionality. Also as it is still throttled by the security policy as described above in comment #1, there is a userland resident method to revert the feature. The only minor unresolved issue associated with this fix is a bit more concrete justification of additional code needed to circumvent a !ptr dereference in generic xattr operations, a clarification request coming as a review comment from Stephen (TBD pending fc12 kernel patch): Stephen Smalley wrote: > On Mon, 2009-08-17 at 16:23 -0400, john cooper wrote: >> Stephen Smalley wrote: >> >>> However: >>> 1) You don't really need the listxattr/setxattr/getxattr handlers since >>> the vfs_* functions will fall back automatically to calling the security >>> hooks if the fs doesn't provide any. So I think you only need the >>> security_inode_init_security() call. >> That's where I had started given the advertising preceding >> fs/xattr.c:xattr_resolve_name(), However the generic_*xattr() >> operations kept tripping over a NULL inode->i_sb->s_xattr ptr >> (perhaps a latent bug). It appeared pulling in the additional >> infrastructure was less risk in this context compared with >> circumventing the NULL ptr deref in common code. > > I'm confused by that, as we get selinux xattr support for free for > devpts by virtue of the vfs fallbacks. We used to get it for free for > tmpfs as well but they ultimately moved that down inside of tmpfs when > they added POSIX ACL support.
Okay, sounds like we'll have a patch suitable for F-12 soon
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.