This is hopefully fixed for RHEL5 and FC6 by selinux-policy-2.4.6-23. Could you
please confirm? Thanks.

As soon as the updated packages hit the repo I'll try to confirm

I updated to the latest form updates-testing.
The problem is still here (SELinux denials)

Here is the output of sealert

sealert -l 5b77c8c5-93c1-4600-b6a7-51137fb4866d
Summary
    SELinux is preventing /usr/bin/fusermount (mount_t) "mount" to /
    (unlabeled_t).

Detailed Description
    SELinux denied access requested by /usr/bin/fusermount. It is not expected
    that this access is required by /usr/bin/fusermount and this access may
    signal an intrusion attempt. It is also possible that the specific version
    or configuration of the application is causing it to require additional
    access.

Allowing Access
    You can generate a local policy module to allow this access - see
    http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable
    SELinux protection altogether. Disabling SELinux protection is not
    recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi
    against this package.

Additional Information        

Source Context                system_u:system_r:mount_t
Target Context                system_u:object_r:unlabeled_t
Target Objects                / [ filesystem ]
Affected RPM Packages         fuse-2.6.1-1.fc6 [application]filesystem-2.4.0-1
                              [target]
Policy RPM                    selinux-policy-2.4.6-23.fc6
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.catchall
Host Name                     ghost.home-net
Platform                      Linux ghost.home-net 2.6.18-1.2869.fc6 #1 SMP Wed
                              Dec 20 14:51:19 EST 2006 i686 i686
Alert Count                   16
Line Numbers                  

Raw Audit Messages            

avc: denied { mount } for comm="fusermount" dev=fuse egid=0 euid=0
exe="/usr/bin/fusermount" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="/"
pid=2538 scontext=system_u:system_r:mount_t:s0 sgid=0
subj=system_u:system_r:mount_t:s0 suid=0 tclass=filesystem
tcontext=system_u:object_r:unlabeled_t:s0 tty=(none) uid=0

I'm sorry, but this bug isn't fixed with selinux-policy-targeted-2.4.6-23.fc6.
The error messages are still there

Adding user_allow_other to fuse.conf and the following parameters in fstab
solved the problem for me: dmask=022,fmask=133,noauto,locale=de_DE.utf8,user 0 0

(In reply to comment #5)
> Adding user_allow_other to fuse.conf and the following parameters in fstab
> solved the problem for me: dmask=022,fmask=133,noauto,locale=de_DE.utf8,user 0 0
Please ignore this comment. It doesn't fix the problem.

I use selinux-policy-targeted-2.4.6-27, and I have the exact same problem. The
only procedure to generate a local policy module to allow ntfs-3g fails, because
audit2allow does not work anymore; it crashes with an error message. I tried to
hack the audit2allow Python script, the problem comes from lines printing text,
I could create the local module, and load it using semodule. But this did not
make any difference. The only solution seems to add noauto in fstab, manually
mount the NTFS drive, and DO NOT forget to manually unmount before shutting
down. There is enough things to think about when using a computer, this is not
necessary to add this annoying one. So I disabled SELinux; what is the point
with this feature which always blocks everything up? With Fedora Core 3, I
disabled it, because it was blocking GnuPG. Now, it continues to block other
programs, and there is no way the user can customize the policy to selectively
unblock things, or the provided ways are buggy.
So in my opinon, the problem is not with ntfs-3g itself, but SELinux.

I'm also seeing this problem using selinux-policy-targeted-2.4.6-27.fc6 and
ntfs-3g-0-0.9.20070118.fc6.  Loading the following policy module as per the
SELinux FAQ solves the problem.  It is basically a commented version of the
audit2allow output.

I have not investigated yet why the root of the ntfs-3g filesystem is unlabeled,
despite the genfscon command in filesystem.te.

policy_module(local, 1.0)

require {
	type mount_t, mount_exec_t, unconfined_t, fixed_disk_device_t, unlabeled_t;
}

# NOTE: This may not be secure; however, DAC should provide enough security
# for now.

# mount.ntfs-3g does a system("modprobe fuse") if the module is not loaded
corecmd_exec_shell(mount_t)
modutils_domtrans_insmod(mount_t)

# To allow access to /dev/fuse, which is labeled fixed_disk_device_t
# (thankfully there are not many other character devices of this type)
allow mount_t fixed_disk_device_t:chr_file rw_file_perms;

# The target filesystem happens to be unlabeled (should have been dosfs_t);
# we won't let that stop us.
allow mount_t unlabeled_t:filesystem { mount unmount };

# The boot scripts run mount as mount_t.  Running mount directly as root
# uses unconfined_mount_t though, so the problem cannot be reproduced this way.
#
# The following statement allows us to use "runcon -t mount_t mount ..."
# as root, so that we can test this module without rebooting.
domain_trans(unconfined_t,mount_exec_t,mount_t)

Thanks for the info and the fix

Tested and works. No messages on startup or shutdown and no setroubleshoot alerts.

But i would like a comment from Daniel.

Correction
It fixes the problem with ntfs-3g but introduces (at least for me) a problem
with operations to a nfsv4 mount drive (copying stalls for ever using cli, mc,
gnome-commander and when killed leaves open pending transactions that prevent
the  unmount of the nfs share) and probably other problems.
Unloading and removing the policy fixed the problem i had with the nfs mount.

I have been waiting on these bugs until, I clean up some lots of other bugs.  I
believe we need a policy for fusermount, that is different from mount.  Also
their  either needs to be some kernel changes or changes to the ntfs-3g module
to understand SELinux, since an unlabeled_t file system should not exist. 
Everything in the kernel needs to be labeled.

> I have been waiting on these bugs until, I clean up some lots of other bugs.

Thank you it's not fogotten. The SELinux problems are extremely popular and
the feedbacks are quite confusing when SELinux works properly and when it
doesn't.

> I believe we need a policy for fusermount, that is different from mount.
> Also their either needs to be some kernel changes

In SELinux or FUSE or somewhere else?

> or changes to the ntfs-3g module to understand SELinux,

What do you mean by "module"? The ntfs-3g software? What changes are needed?
I believed it's a 100% SELinux problem. How would this solve the problem
SELinux denying fusermount operations?

> since an unlabeled_t file system should not exist.  Everything in the
> kernel needs to be labeled.

So the problem is that the fuse and fuseblk file system types aren't
labeled? Do you have examples how this is supposed to be done? Thanks.

Dan, is there a genfs statement for ntfs-3g?  That would probably take care of this.

genfscon ntfs-3g / gen_context(system_u:object_r:dosfs_t,s0)

Is in the policy now.

(In reply to comment #14)
> genfscon ntfs-3g / gen_context(system_u:object_r:dosfs_t,s0)
> 
> Is in the policy now.

This will not work, because mount says that it is fuse filesystem:

[gajownik@zuzia ~]$ mount
[snip]
/dev/hda1 on /mnt/win type fuse (rw,nosuid,nodev,noatime,allow_other)
[gajownik@zuzia ~]$

I've got in fstab this line:
/dev/hda1        /mnt/win   ntfs-3g defaults,noauto        0 0

As you can see, SELinix does not check what is in fstab. Adding this line to the
policy file resolves the problem:

genfscon fuse / gen_context(system_u:object_r:dosfs_t,s0)

Unfortunately, I presume that this is not acceptable, because other fuse
filesystems may work better with other context. You should ask fuse/fuse
filesystem maintainers.

Depending on the kernel version and other issues, mount(8) can report the file
system type (fstype) to be: fuse, fuseblk, fuse.ntfs-3g and fuseblk.ntfs-3g. 

The 'ntfs-3g' sub part of the fstype should stay in the future but it's not
available yet in stable Linux kernels, only in Linus' development tree. This
FUSE feature was added recently to help the identification of the user space
fstype by e.g. mount helpers and make its detection independent of FUSE's
internal evolution, e.g. the introduction of the new, additional fuseblk FUSE
fstype which was required for safe block devices support.

Created attachment 150395 [details]
Patch for use ntfs-3g with the SELinux reference policy

I have create a patch, which should the SELinux issue of ntfs-3g.

I have just put out a policy to handle this in Rawhide for FC7.  Once it gets a
few days of testing and I am convinced it will cause no other problems, I will
back port it to FC6.

Daniel: does the new policy expect ntfs-3g to use exec() instead of system() or
not? Will it work with any of the fuse, fuseblk, fuse.ntfs-3g and
fuseblk.ntfs-3g file system types?

From an selinux point of view exec and system are the same.  You are executing a
new processes.

As far as fuse* file types, I do not know, from a mount command point of view do
you say something like mount -t fuseblk /dev/xyz /mnt/ntfs?

The syntax is always 'mount -t ntfs-3g device mountpoint'. But FUSE can register
the filesystem type to be any of the fuse* types and mount, df -T, /etc/mtab,
etc all will report that value.

(In reply to comment #18)
> I have just put out a policy to handle this in Rawhide for FC7.  Once it gets a
> few days of testing and I am convinced it will cause no other problems, I will
> back port it to FC6.

any update on this?
I tested ntfs-3g and it only works when I disable selinux which I don't want to
do... can you atleast put the fix into updates-testing?

Fixed in selinux-policy-2.4.6-49 

Should be in updates-testing tonight.

(In reply to comment #23)
> Fixed in selinux-policy-2.4.6-49 
> 
> Should be in updates-testing tonight.

still nothing here... and no anouncment on fedora-test-list...

Fixed in rawhide with selinux-policy-2.5.11-2.fc7

(In reply to comment #23)
> Fixed in selinux-policy-2.4.6-49 
> 
> Should be in updates-testing tonight.

works fine for me; also other fuse filesystems are now labled.

works fine here too :-)

*** Bug 220908 has been marked as a duplicate of this bug. ***

I was the filer of Bug 220908 and am trying to figure out if I am having the
same problems as here.

Originally, my problem was that ntfs-3g filesystems were mounted as
'unlabeled_t' which made it impossible for me to copy/move files between normal
linux file systems and ntfs-3g volumes. I never had any problem with
mounting/umounting.

The latest updates to selinux-policy-targeted have fixed the unlabeled problem,
but now all my ntfs-3g volumes show up as 'fusefs_t' and the policy *still*
doesn't allow me to copy/mv between linux and ntfs-3g volumes.

So,
1. Are other people having the same problem or is my issue different?
2. What is the best way to solve this?
   - Use the mount option to assign a default label such as dosfs_t to ntfs-3g
filesystems so that they can interoperate with linux filesystems
   - Change the default policy to enable cp/mv to fusefs_t filesystems?
   - Modify ntfs-3g/fuse/selinux so that ntfs-3g volumes get mounted by default
with a compatible labeling?
   - Something else?

Thanks

Jeff: ntfs-3g development have never heard SELinux related copy/move problem.
The mount/umount one was __FAR__ one of the top issues since October but people
are keep reporting (quite many already) only success with the latest
selinux-policy. Could it be that you have a local selinux configuration issue?

I have a stock selinux 'targeted' policy configuration.

My problem seems to be only with 'mv' -- doing a 'cp' and or 'rm' has no issues.

Again, this is specifically how I create my problem:

mount -t ntsfs-3g /dev/hda1 /mnt/winXP [no problem]
touch ~/crapola [no problem]

cp ~/crapola  /mnt/winxpA [no problem]
cp /mnt/winxpA/crapola ~/ [no problem]

mv /mnt/winxpA/crapola ~/
avc:  denied  { associate } for  pid=22533 comm="mv" name="crapola"
scontext=system_u:object_r:fusefs_t:s0 tcontext=system_u:object_r:fs_t:s0
tclass=filesystem

mv ~/crapola /mnt/winxpA
avc:  denied  { associate } for  pid=22529 comm="mv" name="crapola"
scontext=user_u:object_r:user_home_t:s0 tcontext=system_u:object_r:fusefs_t:s0
tclass=filesystem

rm ~/crapola /mnt/winxpA [no problem]
rm ~/crapola [no problem]

Of course everything works with selinux permissive or if I use audit2allow to
enable the relevant operations. I also don't have selinux issues mv'ing 

This seems to me to be as basic as it gets so I am not sure then why I get these
issues and others don't. Also, it's not clear to me why the problem is with 'mv'
but not with 'cp' or 'rm'.

Any suggestions on how to diagnose this and determine if this is a really bug or
just something weird with my configuration?

Also, can you verify what is the default labeling when you do something like:
mount -t ntfs-3g /dev/hda1 /mnt/winXP

I get:

ls -Zd /mnt/winXP
drwxrwxrwx  root root system_u:object_r:fusefs_t       /mnt/winXP

Fixed in selinux-policy-2_4_6-57_el5

Yippee! Finally all fixed for me. Not sure though why I seemed to be the only
one seeing these problems though...