Bug 566332

The rfcomm0 file was created using blueman, and a regular nokia e65 phone, using DUN.

Using restorecon correct the context.

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, My mistake.  I tried to install blueman but you did not find it.

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.

*** Bug 570815 has been marked as a duplicate of this bug. ***

Eric, could you check if the kernel module is creating the /dev/rfcomm0 device?

*** Bug 572082 has been marked as a duplicate of this bug. ***

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 ).

Eric, shouldn't the kernel be telling udev to create the device?

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).

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

Adam/Nicholas if you look at the device is it labelled device_t?


ls -lZ /dev/rfcomm0

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

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.

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

*** Bug 606838 has been marked as a duplicate of this bug. ***

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)

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.

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....

Created attachment 428141 [details]
ausearch -i -ts recent

Here is mine, there is two consecutive test, each time with a avc.

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

Created attachment 429916 [details]
audit log

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.

Is this happening on resume or just on boot up?

It is happening each time, so definitly on bootup too.

(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.

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.

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

Created attachment 436987 [details]
Latest log

( for the record, the command "auditctl -a exit,always -F arch=b32 -S mknod" )

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.

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.

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.

*** Bug 627710 has been marked as a duplicate of this bug. ***

*** Bug 628077 has been marked as a duplicate of this bug. ***

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'

fix for udev to set selinux context on "add" events:
 https://bugzilla.redhat.com/show_bug.cgi?id=575128#c14

Please test
http://people.redhat.com/harald/downloads/udev/udev-147-2.29.el6/

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 ?

*** Bug 629521 has been marked as a duplicate of this bug. ***

This can be reproduced in FC13, though as bluetoothd is in permissive mode it only raises a warning.

*** Bug 631673 has been marked as a duplicate of this bug. ***

udev-153-4.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/udev-153-4.fc13

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

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.

(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

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.

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 ?

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"

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)

For the record, the bug also appear on Fedora 14 ( freshly updated and rebooted this afternoon ).

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.

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.

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.

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.

(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

I still observe the original race condition in /dev/rfcomm0 device. Updated F13.

after installing provided blootothd module audit errors are gone but my bluetooth modem is not working.

Eugene, try to remove your bluetooth device from bt manager and pair it again.

I tried it several times. I could upload relevant /var/log/messages fragment but it belongs to a another bug.

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.