On Sun, Jul 25, 2010 at 11:14 AM, Xavier Toth <txtoth@xxxxxxxxx> wrote: > On Fri, Jul 23, 2010 at 3:34 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: >> On Fri, 2010-07-23 at 13:57 -0500, Xavier Toth wrote: >>> On Fri, Jul 23, 2010 at 1:32 PM, David P. Quigley <dpquigl@xxxxxxxxxxxxx> wrote: >>> > On Fri, 2010-07-23 at 12:14 -0500, Xavier Toth wrote: >>> >> I'm looking at building a fuse filesystem for polyinstantiated >>> >> directories which could be used as a alternative to pam_namespace. >>> >> I've noticed that my filesystem is never queried for the xattr >>> >> security.selinux and that the file contexts are defaulting to a fuse >>> >> file type. I've seen some list posting from 2004 related to this >>> >> subject but not much else. Is this a bug or a feature? >>> >> >>> >> Ted >>> >> >>> >> -- >>> >> This message was distributed to subscribers of the selinux mailing list. >>> >> If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with >>> >> the words "unsubscribe selinux" without quotes as the message. >>> > >>> > After a brief conversation with Steve more information has come up with >>> > respect to this. A while back Eric Paris had developed a patch to >>> > dynamically probe the file system's getxattr handler to determine if we >>> > can use xattr support on the file system for SELinux labels. The major >>> > stumbling block that Eric ran into was that he was experiencing >>> > deadlocks when using the code. Apparently there were and still might be >>> > locking issues between the fuse and SELinux code. I'm sure you could dig >>> > up Eric's old patch and try to forward port it to see if those locking >>> > issues still exist. >>> > >>> > Dave >>> > >>> > >>> >>> Thanks I'll try and run down the patch and contact Eric. I'll report >>> back if I can get this to work. >> >> Patch was posted here: >> http://marc.info/?l=selinux&m=121379719014155&w=2 >> >> This bug is relevant: >> https://bugzilla.redhat.com/show_bug.cgi?id=493565 >> >> -- >> Stephen Smalley >> National Security Agency >> >> > > I'm testing on FC13 which has equal to or greater than versions of the > packages referenced in the bug report. > > > For test purposes I patched my policy with: > > fs_use_xattr fuse.bbfs gen_context(system_u:object_r:fs_t,s0); > > Mount shows: > /home/tedx/Downloads/fuse-tutorial/src/bbfs on /home/tedx/test type > fuse.bbfs (rw,nosuid,nodev,user=tedx) > > I'm runnning kernel-debug but I don't see a "SELinux: initialized (dev > " message for the fuse.bbfs type. Shouldn't the fusermount cause one > of these messages to be generated? > > I do see fuse attempting to access the system.posix_acl_access and > system.posix_acl_default: > getxattr /Music system.posix_acl_access 0 > unique: 174, error: -61 (No data available), outsize: 16 > unique: 175, opcode: GETXATTR (22), nodeid: 36, insize: 73 > getxattr /Music system.posix_acl_default 0 > unique: 175, error: -61 (No data available), outsize: 16 > > So fuse seems to be able to deal with xattrs. > > I'm pretty new to all of the pieces and could use a little help with > figuring out where to focus my investigation. Is the fuse mounts > superblock initializing its security structure properly? Fuse can deal with xattrs but only AFTER the fuse userspace program believes the filesystem is mounted (and if the filesystem can handle it). My original patches didn't work, because I was calling getxattr during the mount(2) syscall. It gets even worse. We had a 'bug' in which the mount(8) program would call stat (or something like that) on the root inode before it told the fuse userspace program the mount was finished. The audit system checked for file capabilities on the stat call, which resulted in an xattr upcall, which resulted in a deadlock because the fuse userspace wouldn't answer until the mount finished. The 'fix' was to stop mount(8) from calling stat on fuse mounts. The 'right' solution (I think) is going to be 2 parts. First we need to get more information in the superblock mounting. I seem to recall that the only information we had was that it was 'fuse.' Not that is was fuse mounting ntfs. After that we need to fix the other bug you pointed out (and other bug I half worked on and you might be able to find the patch in the archives somewhere) You cannot put fsuse in modules for a number of reasons today, but the last problem i never solved was that of holding the genfs context in a module. We don't (as I recall) have a method to represent the MLS portion of a label in a module. Once that is done (and I think to do it you actually have to store it as a string and then fix it up at link time) you can better handle fuse. I keep telling myself I'm going to look at this stuff again, but people stopped harassing me in bugzilla so I never did..... -Eric -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
