Created attachment 335434 [details] Output of lsusb for the iPod in question and text of the selinuxtroubleshooter alert Description of problem: SELinux issues a denial when hal mounts an iPod and invokes the /usr/lib64/hal/scripts/libgpod-callout script. Version-Release number of selected component (if applicable): libgpod-0.6.0-9.fc10.x86_64 selinux-policy-3.5.13-47.fc10.noarch selinux-policy-targeted-3.5.13-45.fc10.noarch How reproducible: Every time Steps to Reproduce: 1. Plug my iPod into a USB port 2. 3. Actual results: I get an svc denial for a mount operation (actual selinuxtroubleshooter message attached. Expected results: Amarok can scan and play music off the iPod fine, but the denial message is troubling. Additional info: iPod info from lsusb in attachment
The denial shows one of the targets with a context of nfs_t. I'm guessing something may be mounted over nfs and that's tripping up selinux. The callout does very little, it reads some XML data from the ipod via a scsi call, then it mounts the ipod temporarily under /var/run/hald and saves the XML data to iPod_Control/Device/SysInfoExtended. Are any of the parents of /var/run/hald mounted via NFS?
There are no NFS mounts on this system. There are a couple of hard drives connected via USB and the iPod is an HFS- (Mac) formatted unit, with caching turned off. I am running DropBox, but as far as I know it does not use NFS. Here's the output "mount" run as root: [root@prophead scripts]# mount /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) /proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sda1 on /boot type ext3 (rw) tmpfs on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) gvfs-fuse-daemon on /home/rick/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=rick) /dev/sdb1 on /media/CD-DVD-Images type ext3 (rw,nosuid,nodev,uhelper=hal) /dev/sdc1 on /media/500GB-Drive type ext3 (rw,nosuid,nodev,uhelper=hal) /dev/sdd3 on /media/Rick-iPod type hfsplus (rw,nosuid,nodev,uhelper=hal) /dev/sdb1 and /dev/sdc1 are the USB drives.
Hmm, perhaps / has the wrong context? What is the output of: ls -lid / # just to verify the inode, which I'm guessing will be 2 ls -ldZ / # on my F10 box, the context is system_u:object_r:root_t:s0 Of course, I could be reading the AVC from your attachment wrong: node=prophead.hci.com type=AVC msg=audit(1237227454.470:125377): avc: denied { mount } for pid=10636 comm="libgpod-callout" name="/" dev=sdd3 ino=2 scontext=system_u:system_r :hald_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=filesystem It might be worth checking id any of the other mentioned paths have an nfs_t context (e.g. /dev/sdd3).
Don't think they're wonky, but: [root@prophead ~]# ls -lid / 2 drwxr-xr-x 26 root root 4096 2009-03-05 17:22 / [root@prophead ~]# ls -ldZ / drwxr-xr-x root root system_u:object_r:root_t:s0 /
And to add insult to injury: [root@prophead ~]# ls -lid /dev/sdd3 1468250 brw-rw---- 1 root disk 8, 51 2009-03-16 11:17 /dev/sdd3 [root@prophead ~]# ls -ldZ /dev/sdd3 brw-rw---- root disk system_u:object_r:fixed_disk_device_t:s0 /dev/sdd3 The only other thing that seemed to have nfs involved: [root@prophead ~]# ls -lid /var/lib/nfs/rpc_pipefs 7953 drwxr-xr-x 7 root root 0 2009-03-05 17:22 /var/lib/nfs/rpc_pipefs [root@prophead ~]# ls -ldZ /var/lib/nfs/rpc_pipefs drwxr-xr-x root root system_u:object_r:rpc_pipefs_t:s0 /var/lib/nfs/rpc_pipefs Dropbox has lots of stuff open, but none of it seems to have an nfs_t context: [root@prophead ~]# lsof -Z *:*:nfs_t lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/rick/.gvfs Output information may be incomplete.
Well, so much for the obvious and easy. :) It may be worth checking the context of /var/run/hald (and parents) to see if any of them are nfs_t. Other than that, I'm hoping that Dan or Miroslav will have some suggestions.
Interesting. I did a find on the system and everything in the iPod (including its mountpoint, "/media/Rick-iPod") are tagged with "nfs_t". Could it be something like hfsplus filesystems are given nfs_t contexts? I mounted it manually (had to fight hal for it!) and found the subdirectories all had nfs_t context. This certainly seems odd.
Good find! I don't know what the proper context would be for an hfs+ formatted iPod. My vfat model has dosfs_t. You may be able to use that and get things working. In fact, before that, you might want to try 'restorecon -R -v /media/Rick-iPod' to see if that changes the context. Ideally, we'll want to ensure that the iPod is getting labeled correctly from the start and that hald is permitted to mount it. The policy currently explicitly allows the dosfs mounts. It might need to be extended to allow the hfs+ filesystems if those are to have a different context. That's what we'll need Dan and Miroslav for. :)
Miroslav, I think we ought to change these file systems from nfs_t to dosfs_t, since they are similar and have the same security properties. That will fix this problem.
While that'd probably get us over the hump, shouldn't each filesystem type supported by the system have a unique context for finer-grained control? I realize it'd be more work, but seems the "right" way to do it. I don't wish to create more work for you chaps, you've been most helpful. If I can assist any further, I shall. One of my co-workers has a Macbook and I'll get him to format a FLASH drive for me to verify this is a HAL/filesystem issue and not a libgpod/callout thing. That'll be a bit later this afternoon.
Yes and no. It all matters what is the security properties of the domain. As you add more types for file systems that have the same security properties, you increase the complexity and the chance for failure. What is the difference between the security properties of a DOS file system and an Apple File System on a Linux box. They are both removable file systems that do not support extended attributes and users would expect to have them mounted when they are inserted into the machine via USB. Now maybe we should replace the dosfs_t label with a noxattr label of a removable_t label.
Just a bit more info. I got the FLASH drive set up by my friend with the MacBook Pro. Interestingly, it created a GPT partion table that fdisk doesn't grok. gparted did, however, so I found the HFS+ partition was /dev/sdd2. I've mounted it manually (as root: "mount /dev/sdd2 /mnt/dvd") and performed the same items requested above: [root@prophead xxx]# mount ... /dev/sdd2 on /mnt/dvd type hfsplus (rw) [root@prophead xxx]# ls -lid /mnt/dvd 2 drwxrwxr-x 1 nobody nobody 11 2009-03-18 11:20 /mnt/dvd [root@prophead xxx]# ls -ldZ /mnt/dvd drwxrwxr-x nobody nobody system_u:object_r:nfs_t:s0 /mnt/dvd So it's not an iPod-specific thing, but rather an HFS/HFS+ thing. You probably already knew that. :-)
Fixed in selinux-policy-3.5.13-50.fc10
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping