On 7/25/2010 6:24 PM, Eric Paris wrote:
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)
I agree with you on this part. I was talking with Steve about this on
Friday and I said it would be a good idea to have fsues statements based
on the specific fuse file system type. To do this if you detected a fuse
file system type you'd take the device string and chop off everything up
until the first # and that would be the specific fuse file system type.
Steve said there were some other issues with locking between the fuse
code and the security code so I left it at that and didn't actually look
into it further.
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.
--
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.
