Bug 566332

Summary: SELinux is preventing /usr/sbin/bluetoothd "read" access to device rfcomm0.
Product: [Fedora] Fedora Reporter: Michael Scherer <misc>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: aeneby, am.senthilnathan, anton, awilliam, bnocera, carl.gaudreault, celiohermoso, cesarb, christian.bjorkman, craig, cwickert, dannyel.olivares, davids, de_anand, denis.salmanovich, diegobz, dougsland, dwalsh, dwmw2, ekanter, eparis, fedora-bugzilla, gansalmon, harald, huffman, hundred17, itamar, johnbojie, jonathan, jonathanr.pritchard+bugzilla, jordi, jturner, kernel-maint, km12187, kutekunal, larieu, leon, luya, marcel, mgrepl, mku, motuws, nkudriavtsev, nsoranzo, nstrug, orkut32, pavel.ondracka, plautrba, rajeevrvis, run, santiago.lunar.m, scottt.tw, sebasbabel, Shane_Hulburt, sokol420, thub, vanilkovy.puding, viabsb, wdc, xlu, zgarcia83, zimon
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:fa9a779e21f9ede48dc767008bd4d74e02ddc11a0dab387e140ced49f0268baa
Fixed In Version: udev-153-4.fc13 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 603729 (view as bug list) Environment:
Last Closed: 2011-06-27 11:00:26 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
semodule to workaround the problem. checkmodule -M -m -o bluetoothd.mod bluetoothd.te semodule_package -o bluetoothd.pp -m bluetoothd.mod semodule -i ./bluetoothd.pp
none
audit.log
none
ausearch -i -ts recent
none
audit log
none
Latest log
none
Audit log
none
New audit log
none
Audit log, with mknod and mknodat none

Description Michael Scherer 2010-02-17 17:58:19 EST
Résumé:

SELinux is preventing /usr/sbin/bluetoothd "read" access to device rfcomm0.

Description détaillée:

SELinux has denied bluetoothd "read" access to device rfcomm0. rfcomm0 is
mislabeled, this device has the default label of the /dev directory, which
should not happen. All Character and/or Block Devices should have a label. You
can attempt to change the label of the file using restorecon -v 'rfcomm0'. If
this device remains labeled device_t, then this is a bug in SELinux policy.
Please file a bg report. If you look at the other similar devices labels, ls -lZ
/dev/SIMILAR, and find a type that would work for rfcomm0, you can use chcon -t
SIMILAR_TYPE 'rfcomm0', If this fixes the problem, you can make this permanent
by executing semanage fcontext -a -t SIMILAR_TYPE 'rfcomm0' If the restorecon
changes the context, this indicates that the application that created the
device, created it without using SELinux APIs. If you can figure out which
application created the device, please file a bug report against this
application.

Autoriser l'accès:

Attempt restorecon -v 'rfcomm0' or chcon -t SIMILAR_TYPE 'rfcomm0'

Informations complémentaires:

Contexte source               system_u:system_r:bluetooth_t:s0-s0:c0.c1023
Contexte cible                system_u:object_r:device_t:s0
Objets du contexte            rfcomm0 [ chr_file ]
source                        bluetoothd
Chemin de la source           /usr/sbin/bluetoothd
Port                          <Inconnu>
Hôte                         (removed)
Paquetages RPM source         bluez-4.61-1.fc13
Paquetages RPM cible          
Politique RPM                 selinux-policy-3.7.8-11.fc13
Selinux activé               True
Type de politique             targeted
Mode strict                   Enforcing
Nom du plugin                 device
Nom de l'hôte                (removed)
Plateforme                    Linux (removed)
                              2.6.33-0.44.rc8.git0.fc13.i686.PAE #1 SMP Sat Feb
                              13 02:29:36 UTC 2010 i686 i686
Compteur d'alertes            2
Première alerte              mer. 17 févr. 2010 18:14:32 CET
Dernière alerte              mer. 17 févr. 2010 23:55:17 CET
ID local                      5dde3c76-192e-4a71-83f1-ff21a05c2f26
Numéros des lignes           

Messages d'audit bruts        

node=(removed) type=AVC msg=audit(1266447317.685:24188): avc:  denied  { read } for  pid=1497 comm="bluetoothd" name="rfcomm0" dev=devtmpfs ino=69741 scontext=system_u:system_r:bluetooth_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

node=(removed) type=SYSCALL msg=audit(1266447317.685:24188): arch=40000003 syscall=5 success=no exit=-13 a0=f9aa98 a1=100 a2=0 a3=fae9a0 items=0 ppid=1 pid=1497 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="bluetoothd" exe="/usr/sbin/bluetoothd" subj=system_u:system_r:bluetooth_t:s0-s0:c0.c1023 key=(null)



Hash String generated from  device,bluetoothd,bluetooth_t,device_t,chr_file,read
audit2allow suggests:

#============= bluetooth_t ==============
allow bluetooth_t device_t:chr_file read;
Comment 1 Michael Scherer 2010-02-17 18:01:26 EST
The rfcomm0 file was created using blueman, and a regular nokia e65 phone, using DUN.

Using restorecon correct the context.
Comment 2 Daniel Walsh 2010-02-17 18:12:17 EST
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.
Comment 3 Michael Scherer 2010-02-17 18:44:13 EST
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.
Comment 4 Daniel Walsh 2010-02-18 08:44:51 EST
Ok, My mistake.  I tried to install blueman but you did not find it.
Comment 5 Daniel Walsh 2010-02-18 08:49:24 EST
So the question is who/what creates the /dev/rfcomm0 device?  Is it the kernel/devicedriver, something in bluetooth, or udev?  Whoever created it, created it with the wrong label.
Comment 6 Daniel Walsh 2010-03-05 09:46:52 EST
*** Bug 570815 has been marked as a duplicate of this bug. ***
Comment 7 Daniel Walsh 2010-03-05 09:58:27 EST
Eric, could you check if the kernel module is creating the /dev/rfcomm0 device?
Comment 8 Miroslav Grepl 2010-03-10 05:59:41 EST
*** Bug 572082 has been marked as a duplicate of this bug. ***
Comment 9 Michael Scherer 2010-04-22 04:54:53 EDT
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 ).
Comment 10 Daniel Walsh 2010-04-22 07:40:40 EDT
Eric, shouldn't the kernel be telling udev to create the device?
Comment 11 Adam Williamson 2010-05-19 22:48:13 EDT
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).
Comment 12 Nicholas Kudriavtsev 2010-05-20 03:35:27 EDT
Created attachment 415328 [details]
semodule to workaround the problem.

checkmodule -M -m -o bluetoothd.mod bluetoothd.te

semodule_package -o bluetoothd.pp -m bluetoothd.mod

semodule -i ./bluetoothd.pp
Comment 13 Daniel Walsh 2010-05-21 09:55:59 EDT
Adam/Nicholas if you look at the device is it labelled device_t?


ls -lZ /dev/rfcomm0
Comment 14 Nicholas Kudriavtsev 2010-05-21 13:02:43 EDT
crw-rw----. root dialout system_u:object_r:tty_device_t:s0 /dev/rfcomm0
Comment 15 Daniel Walsh 2010-05-24 11:36:21 EDT
Which is correct.  It looks like we have some kind of race condition, where someone (kernel?) creates the device and then some other process (udev?) comes in and fixes the label.
Comment 16 wdc 2010-06-03 21:51:33 EDT
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
Comment 17 Miroslav Grepl 2010-06-23 07:35:08 EDT
*** Bug 606838 has been marked as a duplicate of this bug. ***
Comment 18 Eric Paris 2010-06-30 13:40:57 EDT
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)
Comment 19 Nicholas Kudriavtsev 2010-06-30 15:32:15 EDT
Created attachment 428077 [details]
audit.log

It seems that rfcomm0 was created as device_t and then retyped as tty_device_t. But before rfcomm0 was retyped it was touched by bluetoothd already.
Comment 20 Eric Paris 2010-06-30 15:45:50 EDT
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....
Comment 21 Michael Scherer 2010-06-30 20:35:44 EDT
Created attachment 428141 [details]
ausearch -i -ts recent
Comment 22 Michael Scherer 2010-06-30 20:37:16 EDT
Here is mine, there is two consecutive test, each time with a avc.
Comment 23 Mika Kuusela 2010-07-06 17:38:14 EDT
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
Comment 24 Mika Kuusela 2010-07-06 17:39:28 EDT
Created attachment 429916 [details]
audit log
Comment 25 Michael Scherer 2010-07-22 21:40:05 EDT
I check the semanage command, and it seems ok : 

$ sudo semanage fcontext -l | grep rfcomm
/dev/rfcomm[0-9]+                                  character device   system_u:object_r:tty_device_t:s0 
/usr/bin/rfcomm                                    regular file       system_u:object_r:bluetooth_exec_t:s0 

And yes, /dev/rfcomm do not exist on clean reboot.
Comment 26 Daniel Walsh 2010-07-28 12:59:35 EDT
Is this happening on resume or just on boot up?
Comment 27 Michael Scherer 2010-07-29 11:53:12 EDT
It is happening each time, so definitly on bootup too.
Comment 28 Christoph Wickert 2010-08-03 15:28:52 EDT
(In reply to comment #26)
> Is this happening on resume or just on boot up?    

For me this happens after finishing the bluetooth-wizard and when I try to connect with NM via bluetooth to 3G.
Comment 29 Eric Paris 2010-08-05 17:15:06 EDT
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.
Comment 30 Michael Scherer 2010-08-05 17:48:40 EDT
mhh are you sure of the command ? 

bash-4.1# auditctl -a exit,always -f arch=b32 -S mknod
Failure must be 0, 1, or 2 was arch=b32
Comment 31 Michael Scherer 2010-08-05 17:54:46 EDT
Created attachment 436987 [details]
Latest log
Comment 32 Michael Scherer 2010-08-05 17:55:54 EDT
( for the record, the command "auditctl -a exit,always -F arch=b32 -S mknod" )
Comment 33 wdc 2010-08-05 18:00:15 EDT
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!
Comment 34 Mika Kuusela 2010-08-05 19:03:54 EDT
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.
Comment 35 Eric Paris 2010-08-05 20:11:55 EDT
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
Comment 36 Mika Kuusela 2010-08-05 20:49:20 EDT
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.
Comment 37 Michael Scherer 2010-08-05 21:59:42 EDT
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.
Comment 39 Eric Paris 2010-08-27 19:06:48 EDT
Opening upstream discussion of what I think the problem is:

http://marc.info/?l=linux-kernel&m=128295007600443&w=2

I think it's devtmpfs.
Comment 40 Eric Paris 2010-08-30 19:01:20 EDT
Turns out this is most likely a udev bug introduced in 

http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=578cc8a8085a47c963b5940459e475ac5f07219c

If you look at the old logic it always called udev_selinux_lsetfilecon() but in the new logic that will only be called if the mode, uid, or gid is wrong.  This should be called even if those are still correct.
Comment 41 Eric Paris 2010-08-30 19:01:51 EDT
*** Bug 627710 has been marked as a duplicate of this bug. ***
Comment 42 Eric Paris 2010-08-30 19:04:49 EDT
*** Bug 628077 has been marked as a duplicate of this bug. ***
Comment 43 Daniel Walsh 2010-08-31 11:18:17 EDT
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.
Comment 44 Eric Paris 2010-08-31 11:34:58 EDT
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'
Comment 45 Harald Hoyer 2010-08-31 11:53:20 EDT
fix for udev to set selinux context on "add" events:
 https://bugzilla.redhat.com/show_bug.cgi?id=575128#c14
Comment 46 Harald Hoyer 2010-08-31 11:55:31 EDT
Please test
http://people.redhat.com/harald/downloads/udev/udev-147-2.29.el6/
Comment 47 Michael Scherer 2010-08-31 14:35:45 EDT
As I assume it wouldn'tbe safe to test on f13, sinc this would requires to install a older udev than released, is there a way to help without installing RHEL6 ?
Comment 48 Miroslav Grepl 2010-09-02 08:07:37 EDT
*** Bug 629521 has been marked as a duplicate of this bug. ***
Comment 49 Craig Ringer 2010-09-05 02:13:42 EDT
This can be reproduced in FC13, though as bluetoothd is in permissive mode it only raises a warning.
Comment 50 Daniel Walsh 2010-09-08 11:59:43 EDT
*** Bug 631673 has been marked as a duplicate of this bug. ***
Comment 51 Fedora Update System 2010-09-22 08:09:48 EDT
udev-153-4.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/udev-153-4.fc13
Comment 52 Fedora Update System 2010-09-23 00:58:39 EDT
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
Comment 53 William Makowski 2010-09-23 07:27:44 EDT
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.
Comment 54 Harald Hoyer 2010-09-23 08:17:40 EDT
(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
Comment 55 Fedora Update System 2010-09-26 00:36:44 EDT
udev-153-4.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 56 Michael Scherer 2010-09-26 04:36:04 EDT
As I said in bodhi, I still have the error. Maybe I did it wrong, but kernel was upgraded, initrd was regenerated and I check that udev and libudev were updated. Is the bug fixed for others ?
Comment 57 Nicholas Kudriavtsev 2010-09-26 15:14:21 EDT
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"
Comment 58 Christoph Wickert 2010-09-26 15:59:42 EDT
I can confirm this is still not fixed with udev-153-4.fc13 and selinux-policy-targeted.

$ ls -Z /dev/rfcomm0 
crw-rw----. root dialout system_u:object_r:tty_device_t:s0 /dev/rfcomm0

Zusammenfassung:

SELinux hindert /usr/sbin/bluetoothd "read" am Zugriff auf das Gerät rfcomm0.

Detaillierte Beschreibung:

[SELinux ist in freizügigem Modus. Dieser Zugriff wurde nicht verweigert.]

SELinux hinderte bluetoothd "read" am Zugriff auf das Gerät rfcomm0. rfcomm0 ist
fehlerhaft gekennzeichnet, das Gerät hat das Standard-Label des
/dev-Verzeichnisses, was nicht passieren sollte. Alle Zeichen- und/oder
Blockgeräte sollten ein Label besitzen. Sie können wie folgt versuchen, das
Label der Datei zu ändern: restorecon -v 'rfcomm0'. Wenn dieses Gerät weiterhin
als device_t gekennzeichnet bleibt, ist dies ein Fehler in der
SELinux-Richtlinie. Bitte reichen Sie einen Fehlerbericht ein. Wenn Sie einen
Blick auf andere, ähnliche Geräte-Kennzeichnungen werfen, ls -lZ /dev/SIMILAR,
und einen für rfcomm0 passenden Typ finden sollten, können Sie chcon -t
SIMILAR_TYPE 'rfcomm0' verwenden. Falls dies das Problem behebt, können Sie dies
mit semanage fcontext -a -t SIMILAR_TYPE 'rfcomm0' dauerhaft machen. Falls
restorecon den Kontext ändert, zeigt dies an, dass die Anwendung, die das Gerät
angelegt hat, dieses ohne SELinux APIs tat. Wenn Sie herausfinden, welche
Anwendung das Gerät anlegte, reichen Sie bitte einen Fehlerbericht für diese
Anwendung

Zugriff erlauben:

Versuchen Sie es mit restorecon -v rfcomm0 oder chcon -t SIMILAR_TYPE rfcomm0

Zusätzliche Informationen:

Quellkontext                  system_u:system_r:bluetooth_t:s0-s0:c0.c1023
Zielkontext                   system_u:object_r:device_t:s0
Zielobjekte                   rfcomm0 [ chr_file ]
Quelle                        bluetoothd
Quellpfad                     /usr/sbin/bluetoothd
Port                          <Unbekannt>
Host                          wicktop.localdomain
RPM-Pakete der Quelle         bluez-4.64-1.fc13
RPM-Pakete des Ziels          
Richtlinien-RPM               selinux-policy-3.7.19-57.fc13
SELinux aktiviert             True
Richtlinientyp                targeted
Enforcing-Modus               Permissive
Plugin-Name                   device
Rechnername                   wicktop.localdomain
Plattform                     Linux wicktop.localdomain 2.6.34.7-56.fc13.x86_64
                              #1 SMP Wed Sep 15 03:36:55 UTC 2010 x86_64 x86_64
Anzahl der Alarme             2
Zuerst gesehen                So 26 Sep 2010 21:56:15 CEST
Zuletzt gesehen               So 26 Sep 2010 21:56:15 CEST
Lokale ID                     62a04daf-c0c2-49b0-9958-e4f6955c8950
Zeilennummern                 

Raw-Audit-Meldungen           

node=wicktop.localdomain type=AVC msg=audit(1285530975.779:304): avc:  denied  { read } for  pid=1427 comm="bluetoothd" name="rfcomm0" dev=devtmpfs ino=543790 scontext=system_u:system_r:bluetooth_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

node=wicktop.localdomain type=AVC msg=audit(1285530975.779:304): avc:  denied  { open } for  pid=1427 comm="bluetoothd" name="rfcomm0" dev=devtmpfs ino=543790 scontext=system_u:system_r:bluetooth_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

node=wicktop.localdomain type=SYSCALL msg=audit(1285530975.779:304): arch=c000003e syscall=2 success=yes exit=25 a0=7f06e2809a40 a1=100 a2=0 a3=7fffe82135c0 items=0 ppid=1 pid=1427 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="bluetoothd" exe="/usr/sbin/bluetoothd" subj=system_u:system_r:bluetooth_t:s0-s0:c0.c1023 key=(null)
Comment 59 Michael Scherer 2010-10-19 20:56:01 EDT
For the record, the bug also appear on Fedora 14 ( freshly updated and rebooted this afternoon ).
Comment 60 Daniel Walsh 2010-10-20 09:08:47 EDT
Michael, are  you in enforcing mode or permissive?  In enforcing mode does the bluetooth device succeed?  I could add a dontaudit if the device ends up with the correct context.
Comment 61 Michael Scherer 2010-10-20 14:45:46 EDT
enforcing mode. And the device still do not appear in network-manager. I can try to reboot in permissive mode to check if it is not a problem on nm side.
Comment 62 Harald Hoyer 2010-10-26 05:29:01 EDT
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.
Comment 63 Carl G. 2010-10-31 14:11:48 EDT
udev-161-4.fc14.x86_64

Résumé:

SELinux empêche /usr/sbin/acpid d'« read » au périphérique event12.

Description détaillée:

SELinux a refusé l'accès de acpid « read » au périphérique event12. event12 est
mal étiqueté, ce périphérique porte l'étiquetage par défaut du répertoire /dev,
ce qui ne devrait pas se produire. Tous les caractères et/ou les blocs de
périphériques devraient être étiquetés. Vous pouvez tenter de modifier
l'étiquetage du fichier en utilisant restorecon -v event12. Si ce périphérique
reste étiqueté, il s'agit alors d'un bug de la stratégie de SELinux. Merci de
remplir un rapport de bug. Si vous cherchez des étiquetages de périphériques
semblables, ls -lZ /dev/SIMILAR, et trouvez un type qui fonctionnerait pour
event12, vous pouvez utiliser chcon -t SIMILAR_TYPE 'event12'. Si cela corrige
le problème, vous pouvez rendre le tout permanent en exécutant semanage fcontext
-a -t SIMILAR_TYPE 'event12' Si restorecon modifie le contexte, cela signifie
que l'application qui a créé le périphérique l'a créé sans utiliser les API de
SELinux. Si vous arrivez à déterminer quelle application a créé le périphérique,
merci de remplir un rapport de

Autoriser l'accès:

Essayez restorecon -v 'event12' or chcon -t SIMILAR_TYPE event12

Informations complémentaires:

Contexte source               system_u:system_r:apmd_t:s0
Contexte cible                system_u:object_r:device_t:s0
Objets du contexte            event12 [ chr_file ]
source                        acpid
Chemin de la source           /usr/sbin/acpid
Paquetages RPM source         acpid-2.0.5-3.fc14
Paquetages RPM cible          
Politique RPM                 selinux-policy-3.9.7-7.fc14
Selinux activé                True
Type de politique             targeted
Mode strict                   Enforcing          

Messages d'audit bruts        

type=AVC msg=audit(1288547721.780:27670): avc:  denied  { read } for  pid=1449 comm="acpid" name="event12" dev=devtmpfs ino=6710218 scontext=system_u:system_r:apmd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

type=SYSCALL msg=audit(1288547721.780:27670): arch=c000003e syscall=2 success=no exit=-13 a0=7fff7e6844d0 a1=800 a2=7fff7e6844bf a3=3c items=0 ppid=1 pid=1449 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="acpid" exe="/usr/sbin/acpid" subj=system_u:system_r:apmd_t:s0 key=(null)

^ I got this AVC when i connected my webcam.
Comment 64 Harald Hoyer 2010-11-24 05:32:10 EST
(In reply to comment #63)
> udev-161-4.fc14.x86_64
> 
> Résumé:
> 
> SELinux empêche /usr/sbin/acpid d'« read » au périphérique event12.
> 
> Description détaillée:
> 
> SELinux a refusé l'accès de acpid « read » au périphérique event12. event12 est
> mal étiqueté, ce périphérique porte l'étiquetage par défaut du répertoire /dev,
> ce qui ne devrait pas se produire. Tous les caractères et/ou les blocs de
> périphériques devraient être étiquetés. Vous pouvez tenter de modifier
> l'étiquetage du fichier en utilisant restorecon -v event12. Si ce périphérique
> reste étiqueté, il s'agit alors d'un bug de la stratégie de SELinux. Merci de
> remplir un rapport de bug. Si vous cherchez des étiquetages de périphériques
> semblables, ls -lZ /dev/SIMILAR, et trouvez un type qui fonctionnerait pour
> event12, vous pouvez utiliser chcon -t SIMILAR_TYPE 'event12'. Si cela corrige
> le problème, vous pouvez rendre le tout permanent en exécutant semanage
> fcontext
> -a -t SIMILAR_TYPE 'event12' Si restorecon modifie le contexte, cela signifie
> que l'application qui a créé le périphérique l'a créé sans utiliser les API de
> SELinux. Si vous arrivez à déterminer quelle application a créé le
> périphérique,
> merci de remplir un rapport de
> 
> Autoriser l'accès:
> 
> Essayez restorecon -v 'event12' or chcon -t SIMILAR_TYPE event12
> 
> Informations complémentaires:
> 
> Contexte source               system_u:system_r:apmd_t:s0
> Contexte cible                system_u:object_r:device_t:s0
> Objets du contexte            event12 [ chr_file ]
> source                        acpid
> Chemin de la source           /usr/sbin/acpid
> Paquetages RPM source         acpid-2.0.5-3.fc14
> Paquetages RPM cible          
> Politique RPM                 selinux-policy-3.9.7-7.fc14
> Selinux activé                True
> Type de politique             targeted
> Mode strict                   Enforcing          
> 
> Messages d'audit bruts        
> 
> type=AVC msg=audit(1288547721.780:27670): avc:  denied  { read } for  pid=1449
> comm="acpid" name="event12" dev=devtmpfs ino=6710218
> scontext=system_u:system_r:apmd_t:s0 tcontext=system_u:object_r:device_t:s0
> tclass=chr_file
> 
> type=SYSCALL msg=audit(1288547721.780:27670): arch=c000003e syscall=2
> success=no exit=-13 a0=7fff7e6844d0 a1=800 a2=7fff7e6844bf a3=3c items=0 ppid=1
> pid=1449 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsgid=0 tty=(none) ses=4294967295 comm="acpid" exe="/usr/sbin/acpid"
> subj=system_u:system_r:apmd_t:s0 key=(null)
> 
> ^ I got this AVC when i connected my webcam.

this might be something different
Comment 65 Eugene Kanter 2010-12-07 23:24:36 EST
I still observe the original race condition in /dev/rfcomm0 device. Updated F13.
Comment 66 Eugene Kanter 2010-12-07 23:51:03 EST
after installing provided blootothd module audit errors are gone but my bluetooth modem is not working.
Comment 67 Nicholas Kudriavtsev 2010-12-08 06:07:01 EST
Eugene, try to remove your bluetooth device from bt manager and pair it again.
Comment 68 Eugene Kanter 2010-12-08 16:34:47 EST
I tried it several times. I could upload relevant /var/log/messages fragment but it belongs to a another bug.
Comment 69 Bug Zapper 2011-06-02 12:27:27 EDT
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
Comment 70 Bug Zapper 2011-06-27 11:00:26 EDT
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.