Description of problem: The SELinux policy for podsleuth prevents read/write access to the partition containing the iPod's filesystem. Version-Release number of selected component (if applicable): podsleuth-0.6.5-1.fc12.x86_64 selinux-policy-3.6.32-41.fc12.noarch selinux-policy-targeted-3.6.32-41.fc12.noarch How reproducible: 100% Steps to Reproduce: 1.Plug in iPod 2.podsleuth --rescan --debug Actual results: AVC messages: type=1400 audit(1257521916.401:63): avc: denied { read write } for pid=21391 comm="mono" name="sdc2" dev=tmpfs ino=3219332 scontext=system_u:system_r:podsleuth_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file type=1400 audit(1257521916.401:64): avc: denied { open } for pid=21391 comm="mono" name="sdc2" dev=tmpfs ino=3219332 scontext=system_u:system_r:podsleuth_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file type=1400 audit(1257521916.402:65): avc: denied { getattr } for pid=21391 comm="mono" path="/dev/sdc2" dev=tmpfs ino=3219332 scontext=system_u:system_r:podsleuth_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file type=1400 audit(1257521916.402:66): avc: denied { ioctl } for pid=21391 comm="mono" path="/dev/sdc2" dev=tmpfs ino=3219332 scontext=system_u:system_r:podsleuth_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file and no serial number listed in the podsleuth output. Expected results: Serial number listed in the podsleuth output. Additional info: audit2allow says: allow podsleuth_t fixed_disk_device_t:blk_file { read write getattr open ioctl }; Ideally, of course, it wouldn't need this access in the first place. Does it really need to manipulate the raw partition, or can it do its job with the filesystem it contains?
(In reply to comment #0) > Ideally, of course, it wouldn't need this access in the first place. Does it > really need to manipulate the raw partition, or can it do its job with the > filesystem it contains? I doubt that podsleuth tries to access the raw partition directly. IMHO podsleuth does only the following: 1. under certain circumstances it will mount and unmount the partition using the standard libc "mount" and "umount" calls (could this generate the read/write requests to the partition?) 2. to read the serial number and the property list it will use the "sg_ll_inquiry" function from libsgutils to do an SCSI_INQUIRY for a couple of pages (most likely this has caused the open, getattr and ioctl) - that's pretty much the same as "sg_inq --page=0x80 /dev/sdc" etc. I'm not that much familiar with selinux, so I'm unsure that it can be fixed in podsleuth. The ability to mount/umount and to do the SCSI inquiry seems to be the basic requirement for podsleuth so that it can do its job. Any advice how the problem could be fixed is highly appreciated!
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 540335 has been marked as a duplicate of this bug. ***
In this case /dev/sdc was not a removable device correct, to it is actually trying to look at every disk on the system? To figure out whether it is an ipod?
I'll re-assign this bug report to the selinux-policy component. @selinux-experts: Please can you help solving this problem? I'm willing to help as much as I can. I am able to reproduce the problem, so please don't hesitate to request any information you need. Thank you very much in advance! On my system (fully updated F12) it looks like that the following rules are missing: audit2allow -a #============= podsleuth_t ============== allow podsleuth_t fixed_disk_device_t:blk_file { read write getattr open ioctl }; allow podsleuth_t kernel_t:system module_request;
(In reply to comment #4) > In this case /dev/sdc was not a removable device correct, to it is actually > trying to look at every disk on the system? To figure out whether it is an > ipod? Are you referring to https://bugzilla.redhat.com/show_bug.cgi?id=533399#c0 ? If yes, than I think this is just a strange output - even if lines like this "tcontext=system_u:object_r:fixed_disk_device_t:s0" indicate something different - most likely the raw scsi device of the attached ipod (which is actually a USB mass storage device) was accessed. I can easily reproduce this on my system: USB Mass Storage support registered. usb-storage: device scan complete scsi 4:0:0:0: Direct-Access Apple iPod 1.62 PQ: 0 ANSI: 0 sd 4:0:0:0: Attached scsi generic sg1 type 0 sd 4:0:0:0: [sdb] Adjusting the sector count from its reported value: 7999488 sd 4:0:0:0: [sdb] 7999487 512-byte logical blocks: (4.09 GB/3.81 GiB) sd 4:0:0:0: [sdb] Write Protect is off sd 4:0:0:0: [sdb] Mode Sense: 68 00 00 08 sd 4:0:0:0: [sdb] Assuming drive cache: write through sd 4:0:0:0: [sdb] Adjusting the sector count from its reported value: 7999488 sd 4:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sdb2 sd 4:0:0:0: [sdb] Adjusting the sector count from its reported value: 7999488 sd 4:0:0:0: [sdb] Assuming drive cache: write through sd 4:0:0:0: [sdb] Attached SCSI removable disk SELinux: initialized (dev sdb2, type vfat), uses genfs_contexts ... Raw Audit Messages type=AVC msg=audit(1259016939.208:18): avc: denied { getattr } for pid=2188 comm="mono" path="/dev/sdb2" dev=tmpfs ino=27644 scontext=system_u:system_r:podsleuth_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file type=SYSCALL msg=audit(1259016939.208:18): arch=40000003 syscall=197 per=400000 success=yes exit=0 a0=7 a1=bfe3d780 a2=56aff4 a3=8459188 items=0 ppid=2184 pid=2188 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mono" exe="/usr/bin/mono" subj=system_u:system_r:podsleuth_t:s0 key=(null)
(In reply to comment #4) Sorry, the answer to your second question got lost: > In this case /dev/sdc was not a removable device correct, to it is actually > trying to look at every disk on the system? To figure out whether it is an > ipod? IMHO podsleuth doesn't scan the devices itself. It is initially called by hal if its vendor/device ID is recognized. Even later, when a user uses "podsleuth --rescan" IMHO only a function in hal (provided by the podsleuth interface) is called which then in order starts podsleuth for the specific device. If podsleuth would scan the whole system, I assume there would be selinux errors even for the real disks.
Dan: no, /dev/sdc is not a real disk on this system: it is the USB mass storage device view of the iPod.
Right so my choices is allow this tool to read/write every disk on the system or somehow get this device to have a label on it.
Is there a script that starts podsleuth? Could we change the script to label the device such that podsleuth could read it and destroy it when it is complete? Does the device get mounted? afterwoods to be accessed by user apps?
(In reply to comment #10) > Is there a script that starts podsleuth? Yes. That part of podsleuth, which needs this access, is Podsleuth.Hal.exe (mono) which is started by /usr/libexec/hal-podsleuth (which is a script). > Could we change the script to label > the device such that podsleuth could read it and destroy it when it is > complete? Sure, I can try this. Please can you give me a short hint how I should label the device file? > Does the device get mounted? afterwoods to be accessed by user apps? Yes, if it is not mounted yet, podsleuth will also mount it to gather more information from the filesystem on this device as well.
Lets talk about the security goals of the confinement of podsleuth. A user plugs in a usb/ipod device and attempts to trick podsleuth into doing something evil, via the content on the device. Currently if I allow podsleuth the ability to read/write all fixed_disks, it can subvert the entire machine. If we do the mount command in the script or label in the script, we could make podsleuth only able to use the particular usb/ipod device plugged in. Does this make sense?
(In reply to comment #12) > Lets talk about the security goals of the confinement of podsleuth. A user > plugs in a usb/ipod device and attempts to trick podsleuth into doing something > evil, via the content on the device. Currently if I allow podsleuth the > ability to read/write all fixed_disks, it can subvert the entire machine. If > we do the mount command in the script or label in the script, we could make > podsleuth only able to use the particular usb/ipod device plugged in. Sure, this looks good. Since we still need the access to the raw device via ioctl, I would prefer that we label the device in the script. Since hald will populate the device name in the environment, it should be no problem to label the device accordingly. Please can you give me a hint, which command I should use to give a device a specific selinux label?
chcon would do it. chcon -t removable_device_t /dev/sd2 Then I could add these access to removable_device_t.
Change that to chcon -t removable_t /dev/sd2
tah(In reply to comment #15) > chcon -t removable_t /dev/sd2 Thank you very much for the info. I've tried to label the device file, but unfortunately it looks like that it gets re-labeled right after my chcon call. AFAIK PodSleuth.Hal.exe (which is called by the script after I've labeled it) does internally mount and umount the device (if it is not mounted by hal itself). Can a call to libc's mount/umount re-label the device files? Additionally it looks like that "chcon" is not allowed to relabel the device.
*** Bug 544659 has been marked as a duplicate of this bug. ***
Daniel, please can you guide me a little bit through this selinux adventure? I've already checked lots of the documentation (e.g. http://docs.fedoraproject.org/selinux-user-guide/f12/en-US/ ), but unfortunately it only covers "static" cases with static file and directory names. I haven't found lots about the dynamic creation of e.g. devices and which part of a linux system is responsible for its labeling. In bug 544659 you've suggested to relabel the device to removable_t, but unfortunately all my tests were not successful: 1. If I label the device manually via chcon and then let podsleuth run again, the device is somehow relabeled back to fixed_disk_device_t (and selinux still prevents the access). I don't understand, why this happens (see my comment #16). 2. I've looked in the source udev and it looks like, that the only way how udev sets security labels is by getting the correct label via "matchpathcon", and then use "lsetfilecon" or "setfscreatecon" to actually label a file (or make sure that the newly created device node gets the correct label). As far as I understand "matchpathcon" just does some basic file name matching according to the definitions in /etc/selinux/targeted/contexts/files/file_contexts* . It does not look like that any other udev rules directly uses chcon and so I'm unsure how to fix this. 3. I've seen that there were simliar issues with libgpod (BZ #490541) and so I have looked at libgpod and its hal-callout binary: This tool ( /usr/lib/hal/scripts/libgpod-callout ) does exactly the same as podsleuth (accessing the raw device via ioctl calls), but it does not look like that there is an explicit rule to allow this. So I'm wondering why it works for libgpod but not for podsleuth. Thank you very much in advance!
cat > /etc/udev/rules.d/80-posleuth.rules << EOF SUBSYSTEM!="block", GOTO="end_podsleuth" #KERNEL!="sd", GOTO="end_podsleuth" ACTION!="add", GOTO="end_podsleuth" ATTRS{vendor}=="Apple*", ATTRS{model}=="iPod*", \ RUN+="/usr/bin/chcon -t removable_t /dev/%k" LABEL="end_podsleuth" EOF
The udev file above seems to fix the problem. Can podsleuth package this up.
*** Bug 548552 has been marked as a duplicate of this bug. ***
(In reply to comment #20) > The udev file above seems to fix the problem. Can podsleuth package this up. I've tried the provided udev rule on my system (and I had already tried something similar before), but it does not really help: - sure, the device gets labeld as removable_t (first) - but later, during the podsleuth run, the devices are labeled back to fixed_disk brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/sdb brw-rw----. root disk system_u:object_r:removable_t:s0 /dev/sdb1 brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/sdb2 - please see my comment #16 or #18 (1.) I can easily reproduce this: - set the correct lables: chcon -t removable_t /dev/sdb* root@edoras:/etc/udev/rules.d# ls -Z /dev/sdb* brw-rw----. root disk system_u:object_r:removable_t:s0 /dev/sdb brw-rw----. root disk system_u:object_r:removable_t:s0 /dev/sdb1 brw-rw----. root disk system_u:object_r:removable_t:s0 /dev/sdb2 - run podsleuth --rescan - check labels: brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/sdb2 So this means, that something must re-label the device files during the podsleuth run. Since podsleuth itself doesn't deal with selinux labels, I can only imagine that either hal itself (because the podsleuth --rescan actually only triggers hal to execute /usr/libexec/hal-podsleuth --discover) does the re-labeling or something which hal-podsleuth does (but can just a syscall like mount/umount/getattr trigger a re-labeling)?
I've debugged the problem: The automatic re-labeling happens, because udev will get (during the hal-podsleuth run) the following "hotplug" event from the kernel via netlink: ...UDEV_LOG=3\0ACTION=change\0DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb2/2-2/2-2:1.0/host6/target6:0:0/6:0:0:0/block/sdb/sdb2\0SUBSYSTEM=block\0DEVNAME=sdb2\0DEVTYPE=partition... - udev will now use selinux's matchpathcon function to determine the intended label for /dev/sdb2: /dev/[shmx]d[^/]* -b system_u:object_r:fixed_disk_device_t:s0 - udev sets now this label Why the kernel sounds out this event I don't know, there seems to be several reasons (including re-reading the partition table, "medium change" scsi events, etc.). As an ugly workaround I have slightly altered the suggested udev rule: SUBSYSTEM!="block", GOTO="end_podsleuth" ACTION=="remove", GOTO="end_podsleuth" ATTRS{vendor}=="Apple*", ATTRS{model}=="iPod*", \ RUN+="/usr/bin/chcon -t removable_t /dev/%k" LABEL="end_podsleuth" so that now even for a "change" event the device is re-labeled. This "works" on my system. However, I assume that there is now a short time interval where the label is fixed_disk (between the "stardard labeling" of udev and the execution of the rule). Since udev and hal-podsleuth run in parallel in case of this "change" event, this might be a race condition. Additionally the usage of the label "removable_t" will break the access for hald-addon-storage: SELinux is preventing /usr/libexec/hald-addon-storage "read" access on sdb. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by hald-addon-stor. It is not expected that this access is required by hald-addon-stor 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 FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:hald_t:s0 Target Context system_u:object_r:removable_t:s0 Target Objects sdb [ blk_file ] Source hald-probe-stor Source Path /usr/libexec/hald-probe-storage Port <Unknown> Host edoras Source RPM Packages hal-0.5.13-9.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-56.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name catchall Host Name edoras Platform Linux edoras 2.6.31.6-166.fc12.i686.PAE #1 SMP Wed Dec 9 11:00:30 EST 2009 i686 i686 Alert Count 38 First Seen Wed Dec 16 21:18:10 2009 Last Seen Sat Dec 19 17:23:39 2009 Local ID 352d3c79-13dd-481f-ba69-9a63cbe69867 Line Numbers Raw Audit Messages node=edoras type=AVC msg=audit(1261239819.2:178): avc: denied { read } for pid=13073 comm="hald-addon-stor" name="sdb" dev=tmpfs ino=579678 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:removable_t:s0 tclass=blk_file node=edoras type=AVC msg=audit(1261239819.2:178): avc: denied { open } for pid=13073 comm="hald-addon-stor" name="sdb" dev=tmpfs ino=579678 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:removable_t:s0 tclass=blk_file node=edoras type=SYSCALL msg=audit(1261239819.2:178): arch=40000003 syscall=5 success=yes exit=5 a0=95534b6 a1=8000 a2=0 a3=95547b8 items=0 ppid=1092 pid=13073 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="hald-addon-stor" exe="/usr/libexec/hald-addon-storage" subj=system_u:system_r:hald_t:s0 key=(null) So basically there are 2 problems left: 1. How can it be prevented that udev re-labels the device back to fixed_disk or whether udev could correctly label the device in the first place? 2. Give hald-addon-storage the permission to write to devices labeled with removable_t. Any ideas how to solve these two problems?
You can add these rules for now using # grep avc /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Fixed in selinux-policy-3.6.32-61.fc12.noarch
Harald, any suggestion on the race condition?
*** Bug 550880 has been marked as a duplicate of this bug. ***
*** Bug 552948 has been marked as a duplicate of this bug. ***
Althought there might be still a race condition (as described in comment #23), I'll push out a bug fix release containing the intermediate bug fix which works at least on my system without any problems. Daniel, Harald: If you have an idea how to fix this in a better way, please just let me know!
podsleuth-0.6.6-0.2.20091216git.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/podsleuth-0.6.6-0.2.20091216git.fc12
*** Bug 558529 has been marked as a duplicate of this bug. ***
*** Bug 558530 has been marked as a duplicate of this bug. ***
podsleuth-0.6.6-0.2.20091216git.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 558754 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.