Of blueman is creating the device it needs to make sure the device is properly labeled. Either need to run restorecon itself or use udev to create the device.
Since blueman is not part of Fedora I have to close this bug as can't fix.
You could either patch blueman to create the device with the right label or use restorecond to watch for the device and fix its label.
If you want to open a bug with blueman, I would work with them to fix their code.

Well, blueman is packaged in fedora.
And that's not blueman directly that create the rfcomm device, but bluetoothd using dbus or the python api, I am not sure from looking at the code. Since blueman is not running as root, I doubt it can create the file directly.
However, when trying to reproduce using rfcomm, it work correctly.

Ok, after reading bluez code, the device is created using a ioctl :
dev = ioctl(sk, RFCOMMCREATEDEV, &req);
And so everything is done in kernel, there is a function rfcomm_create_dev that does it ( in net/bluetooth/rfcomm/tty.c ). There is no mention of selinux anywhere.
And as I said, if I use rfcomm as root, the device is correctly labeled ( iirc ).

I´ve just hit a bug which gets called a dupe of this, if you go through two levels of dupes. It happens every time I try to set up Bluetooth DUN via a phone after a clean F13 install, using regular GNOME bluetooth stuff. At the end of the pairing process for the phone there is a box you can check to do the DUN stuff. As soon as I check this, the denial comes up (repeatably).

I too am being affected by this bug. I am using the semodule work-around for now, myself.
Hardware: Lenovo T60p laptop.
Kernel: 2.6.33.5-112.fc13.i686
NetworkManager-0.8.1-0.1.git20100510.fc13.i686
ModemManager-0.3-12.git20100504.fc13.i686

I'm very perplexed. the bluez maintainer looked over the code and said that bluez never calls mknod to create /dev/rfcomm[0-9]. that means it is likely udev and I know udev has proper selinux support.
Can I ask what version of selinux-policy policy you are running? And can you verify that semanage fcontext -l | grep rfcomm shows tty_device_t?
I wouldn't be surprised if this is just a result of old policy before rfcomm had a label and the problem is actually fixed when everything is up 2 date. I wish I had a phone so I could reproduce it myself, but I don't, so I'm going to have to rely on your help.
I'm assuming that /dev/rfcomm does not exist on a clean reboot. If it does, what is it labeled? (ls -lZ)
No matter what can someone run
audictl -w /dev/rfcomm0
and then reproduce the problem? Attach the audit log in question after having done so? (ausearch -i -ts recent)
(you can clear the audictl command with auditctl -W /dev/rfcomm0)

Your log cuts a lot more out than I would like (each PATH record should have come with a SYSCALL record a CWD record, maybe other PATH records I don't know for sure) which might help me see who is messing with the file.
In any case, what i really want is those records when the file was CREATED during/after boot. It is being created wrong (both gid and selinux label) and so I'm interested to know who is getting it wrong.
I notice that during the life of your log that /dev/rfcomm had its gid changed (root->dialout) and it was around that time that the context was fixed. So I'm also interested in knowing what fixed it....

Same issue here. I receive a single AVC denial message when connecting NetworkManager to my phone via bluetooth, although the mobile broadband works fine since bluetoothd has a permissive type.
Attached are the results of auditctl -w /dev/rfcomm0

Sorry to be so darn slow coming back. @Michael and Mika, thanks for the logs. Can you do it yet again, this time with the following rules?
auditctl -a exit,always -f arch=b32 -S mknod
auditctl -a exit,always -f arch=b64 -S mknod
auditctl -w /dev/rfcomm0
auditctl -w /dev/rfcomm1
when you are finished just run
auditctl -D
to delete all of the audit rules.

I see that a clone of this bug has been made for RHEL6, and that the clone is now diverging from this bug because: Apparently on RHEL, the SELinux intercept happens once and only once, and everything is fine after that.
The behavior under Fedora 13 is **DIFFERENT**.
Without the work-around supplied by Nicholas Kudriavtsev, the rfcomm NEVER opens, because under Fedora 13, the rfcomm device is created ON THE FLY, and then destroyed when the bluetooth setup is taken down.
Do we have a definitive identification of the root cause of this problem yet?
Maybe RHEL 6 doesn't need a fix, but Fedora SURE DOES!

Created attachment 436999[details]
Audit log
I initially got the same error msg about the auditctl command as Michael, so I used the -F option.
For reference, the testing procedure: Rebooted, added the auditctl rules, attached the bluetooth dongle and then connected to the phone's mobile broadband through ModemManager.

Thanks both of you. The testing methodology in comment 34 seems right but the device file was already created when the first audit message was gathered so I must have screwed up. I guess whatever is creating the device file used mknodat rather than mknod. Sorry.
I do see in the trace that udev came in and fixed the label and that modemmanager then used the file. Do things actually work for you? Because the end of the trace sure seems like it is working.
In any case can you reproduce yet again for me ? This time add the following rules to /etc/audit/audit.rules and reboot? That way I know the rules are in as early as possible.
-a exit,always -F arch=b32 -S mknod
-a exit,always -F arch=b64 -S mknod
-a exit,always -F arch=b32 -S mknodat
-a exit,always -F arch=b64 -S mknodat
-w /dev/rfcomm0

Created attachment 437005[details]
New audit log
Edited /etc/audit/audit.rules as instructed.
Mobile broadband works fine, it's just the minor annoyance of getting an AVC denial message when connecting that I'm experiencing.

Created attachment 437007[details]
Audit log, with mknod and mknodat
Here, network manager do not show the icon for connecting, unlike to what happen when I plug the usb cable, but indeed, running wvdial as root work, and 3g work.

But the fact that devtpmfs is allowing the kernel to created devices rather then having udev create the devices is the root of the problem.
udev can not differentiate between the kernel creating a device for the first time with the wrong label, as opposed to libvirt coming in and changing the label on a device for better confinement.
One possible solution would be to have udev change the label iff the label matched the confining directory and was different then the default label.
device_t chr_file in a device_t parent directory is wrong.

devtmps == 'the kernel' in this context. I use them interchangeably.
My original suggestion was for udev to be allowed to tell the kernel to stop creating device nodes after it was running (devtmpfs makes boot a whole lot easier since /dev gets populated before udev starts) Kay didn't jump on that idea. Maybe Harald likes it better, I don't know.
Long term solution: will be for me to get my butt back to work on passing the last part of the path name into inode creation so file transition rules can take that into account and the kernel (or udev) won't need SELinux magic and things 'just work'
Medium term solution: figure out what we need to do so udev can distinguish create from change events.
Short term solution: have udev determine the 'default' context things in /dev would be created in and have it fix anything that is labeled the 'default'

udev-153-4.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update udev'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/udev-153-4.fc13

(In reply to comment #53)
> Has the fix be made available to Fedora 14 as well? Bug 628077 was marked as a
> duplicate of this one, but was reported on Fedora 14.
udev-161-2.fc14 should fix the issue in F14

After update I have no error while connecting to a device existing in the NetworkManager, but I have non blocking error while creating a new DUN device. Previously I can not create a new DUN device without selinux policy workaround.
The error is the same "SELinux is preventing /usr/sbin/bluetoothd "read" access to device rfcomm0"

Yes, there is still a short window, where after the kernel loaded the module and the module provides rfcomm0 with devtmpfs and still udev has not processed the "add" event. In this small window the device node is present but has not yet been relabled by udev.

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. 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 '13'.
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 13'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 13 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 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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.