Bug 220908 - selinux errors copying between various labelled & unlabelled filesystems
Summary: selinux errors copying between various labelled & unlabelled filesystems
Keywords:
Status: CLOSED DUPLICATE of bug 220732
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-12-28 18:36 UTC by Need Real Name
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-04-11 17:57:51 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Need Real Name 2006-12-28 18:36:18 UTC
Description of problem:

In addition to the standard ext3 filesystem, I also have partitions with
dos/vfat and ntfs-3g types.

Copying/moving files between various pairwise combinations of these labeled and
unlabeled filesystems gives selinux errors.

It seems to me that these operations should be allowed under the targeted
policy, particularly, when the user has ownership rights to the respective
directories and files.

So far, I have needed to create the following rules to allow such copies/moves,
though I am sure that there are other combinations and permutations of source
and target type contexts:

require {
        class filesystem associate;
        type dosfs_t;
        type file_t;
        type fs_t;
        type unlabeled_t;
        type usr_t;
        type var_t;
        role object_r;
};

allow dosfs_t unlabeled_t:filesystem associate;
allow file_t unlabeled_t:filesystem associate;
allow unlabeled_t dosfs_t:filesystem associate;
allow unlabeled_t fs_t:filesystem associate;
allow usr_t unlabeled_t:filesystem associate;
allow var_t unlabeled_t:filesystem associate;

I could presumably continue to add new permutations to my 'local' policy as they
come up but I suspect that there must be a better way to do this.

In any case, please let me know whether you at least agree with the premise that
under the targeted policy, the average user should be able to move/copy files
between filesystems that they have permission to.

Alternatively, maybe in my /etc/fstab, I should 'force' a context to the
unlabeled file systems????

Please advise and/or correct...

Comment 1 Daniel Walsh 2006-12-29 15:34:55 UTC
Is the unlabeled file system a ext3 file system.  You can easily add a label
useing restorecon -R -v /MOUNTPOINT.  Or you could us a mount option to mount it
with one context.

Something like the following

mount -o context=system_u:object_r:default_t /dev/XYZ /MOUNTPOINT

Comment 2 Need Real Name 2006-12-29 16:11:58 UTC
No - the unlabeled file system is an ntfs-3g filesystem and the dosfs_t is a
vfat filesystem.

Again, I get selinux errors when I copy any of the following permutations:
   vfat -> ntfs-3g
   ntfs-3g -> ext3
   ntfs-3g -> vfat
   ext3 -> ntfs-3g
   
Presumably, similar errors would occur between ntfs-3g and any other filesystem,
since mount.ntfs-3g apparently by default mounts the ntfs-3g filesystem with
context 'unlabeled'.

Maybe the solution is to have the ntfs-3g module assign a context to the
filesystem and mount it accordingly.



Comment 3 Need Real Name 2006-12-29 16:15:01 UTC
The more I think about it, the problem is really just that ntfs-3g is not
mounting  the file system as type dosfs_t (which is what the older 'ntfs' mount
does).

Maybe the owner of the Fedora Extra ntfs-3g module should be copied on this bug
report

Comment 4 Daniel Walsh 2007-01-02 16:05:39 UTC
Yes the problem is a mapping problem in policy.

Should be fixed in selinux-policy-2.4.6-21

Comment 5 Need Real Name 2007-01-14 17:55:06 UTC
Just updated to selinux-policy-2.4.6.23.
Still seeing the following in my /var/log/messages:

Jan 14 12:49:03 consult kernel: SELinux: initialized (dev fuse, type fuse), not
configured for labeling

(remember that ntfs-3g is a user-space filesystem so it uses 'fuse')

Thanks,
Jeff

Comment 6 Need Real Name 2007-02-18 01:27:02 UTC
This still doesn't seem to be fixed. I have the latest  selinux-policy-2.4.6-37.fc6.

I still get the boot message:
 SELinux: initialized (dev fuse, type fuse), not configured for labeling
when I boot and mount the filesystem using ntfs-3g.

I am using:
    ntfs-3g-0-0.9.20070118.fc6
    fuse-2.6.3-1.fc6

What am I doing wrong since I believe you said that you had fixed it as of
selinux-policy-2.4.6-21 ?




Comment 7 Need Real Name 2007-03-28 00:42:47 UTC
Still not fixed -- i.e., ntfs-3g filesystems (using fuse) still show up as
unlabeled.

Interestingly, though, the kernel boot error message has changed a little to:

SELinux: initialized (dev hda1, type fuseblk), not configured for labeling

I'm surprised that other people aren't having this problem since I would have
thought that by now many people would want to use ntfs-3g to read/write to
Windoze ntfs filesystems (though perhaps those people just shut off selinux :)

In any case, I would think this would be a priority bug to fix...

By the way, I am currently running:
kernel-2.6.20-1.2933.fc6
selinux-policy-targeted-2.4.6-42.fc6.noarch.rpm
fuse-2.6.3-2.fc6.i386.rpm
ntfs-3g-1.0-1.fc6


Comment 8 Daniel Walsh 2007-04-10 18:40:04 UTC
Fixed in selinux-policy-2.4.6-49.fc6

Comment 9 Need Real Name 2007-04-11 16:57:44 UTC
Not sure it's fully fixed yet :)
Good news is that my ntfs-3g partitions are now labeled.

The bad news is that they are labeled as: system_u:object_r:fusefs_t 
Unfortunately, the targeted policy selinux definitions don't allow for copying
between to the fusefs_t domain.

I would think that the 'average' user of an ntfs-3g filesystem would want to be
able to at least do basic file operations.

Any suggestions on the *best* way to remedy this?

Comment 10 Daniel Walsh 2007-04-11 17:57:51 UTC
That is strange, it should be labeled ntfs-3g.

Checkout bugzilla #220732

They seem happy with this fix.

I will close this bug as a duplicate and we can carry on the conversations there.

*** This bug has been marked as a duplicate of 220732 ***


Note You need to log in before you can comment on or make changes to this bug.