Bug 490541 - SELinux libgpod denial when hal mounts an iPod
Summary: SELinux libgpod denial when hal mounts an iPod
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 10
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-03-16 21:55 UTC by Rick Stevens
Modified: 2009-11-18 11:40 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-11-18 11:40:07 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Output of lsusb for the iPod in question and text of the selinuxtroubleshooter alert (9.97 KB, application/octet-stream)
2009-03-16 21:55 UTC, Rick Stevens
no flags Details

Description Rick Stevens 2009-03-16 21:55:22 UTC
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

Comment 1 Todd Zullinger 2009-03-16 22:17:56 UTC
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?

Comment 2 Rick Stevens 2009-03-16 22:44:38 UTC
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.

Comment 3 Rick Stevens 2009-03-16 22:59:56 UTC
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.

Comment 4 Todd Zullinger 2009-03-16 23:03:59 UTC
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).

Comment 5 Rick Stevens 2009-03-16 23:20:11 UTC
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      /

Comment 6 Rick Stevens 2009-03-16 23:29:45 UTC
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.

Comment 7 Todd Zullinger 2009-03-16 23:35:05 UTC
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.

Comment 8 Rick Stevens 2009-03-17 01:10:20 UTC
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.

Comment 9 Todd Zullinger 2009-03-17 01:31:31 UTC
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. :)

Comment 10 Daniel Walsh 2009-03-17 18:12:26 UTC
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.

Comment 11 Rick Stevens 2009-03-17 18:55:03 UTC
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.

Comment 12 Daniel Walsh 2009-03-17 19:23:04 UTC
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.

Comment 13 Rick Stevens 2009-03-18 18:33:01 UTC
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.  :-)

Comment 14 Miroslav Grepl 2009-03-20 15:43:21 UTC
Fixed in  selinux-policy-3.5.13-50.fc10

Comment 15 Bug Zapper 2009-11-18 11:31:49 UTC
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


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