Bug 220908 - selinux errors copying between various labelled & unlabelled filesystems
selinux errors copying between various labelled & unlabelled filesystems
Status: CLOSED DUPLICATE of bug 220732
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-28 13:36 EST by Need Real Name
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-11 13:57:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2006-12-28 13:36:18 EST
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 10:34:55 EST
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 11:11:58 EST
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 11:15:01 EST
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 11:05:39 EST
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 12:55:06 EST
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-17 20:27:02 EST
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-27 20:42:47 EDT
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 14:40:04 EDT
Fixed in selinux-policy-2.4.6-49.fc6
Comment 9 Need Real Name 2007-04-11 12:57:44 EDT
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 13:57:51 EDT
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.