SELinux is preventing /usr/sbin/bluetoothd from 'setattr' accesses on the sock_file sdp. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that bluetoothd should be allowed setattr access on the sdp sock_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep bluetoothd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:bluetooth_t:s0 Target Context system_u:object_r:tmpfs_t:s0 Target Objects sdp [ sock_file ] Source bluetoothd Source Path /usr/sbin/bluetoothd Port <Unknown> Host (removed) Source RPM Packages bluez-4.87-2.fc15 Target RPM Packages Policy RPM selinux-policy-3.9.16-6.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 2.6.38.2-9.fc15.x86_64 #1 SMP Wed Mar 30 16:55:57 UTC 2011 x86_64 x86_64 Alert Count 1 First Seen Thu 31 Mar 2011 10:01:49 AM GMT Last Seen Thu 31 Mar 2011 10:01:49 AM GMT Local ID e56ab55a-ffd5-402a-989f-8406fa2e2605 Raw Audit Messages type=AVC msg=audit(1301565709.85:106): avc: denied { setattr } for pid=1060 comm="bluetoothd" name="sdp" dev=tmpfs ino=17698 scontext=system_u:system_r:bluetooth_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=sock_file type=SYSCALL msg=audit(1301565709.85:106): arch=x86_64 syscall=chmod success=yes exit=0 a0=7f00cbebcfd4 a1=1b6 a2=6e a3=7fffa7be1a30 items=0 ppid=1 pid=1060 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 key=(null) Hash: bluetoothd,bluetooth_t,tmpfs_t,sock_file,setattr audit2allow #============= bluetooth_t ============== allow bluetooth_t tmpfs_t:sock_file setattr; audit2allow -R #============= bluetooth_t ============== allow bluetooth_t tmpfs_t:sock_file setattr;
These are all do to the /run addition by systemd.
*** Bug 692460 has been marked as a duplicate of this bug. ***
*** Bug 692462 has been marked as a duplicate of this bug. ***
*** Bug 692456 has been marked as a duplicate of this bug. ***
*** Bug 692463 has been marked as a duplicate of this bug. ***
*** Bug 692464 has been marked as a duplicate of this bug. ***
*** Bug 692473 has been marked as a duplicate of this bug. ***
*** Bug 692478 has been marked as a duplicate of this bug. ***
*** Bug 692476 has been marked as a duplicate of this bug. ***
*** Bug 692482 has been marked as a duplicate of this bug. ***
*** Bug 692481 has been marked as a duplicate of this bug. ***
*** Bug 692484 has been marked as a duplicate of this bug. ***
*** Bug 692486 has been marked as a duplicate of this bug. ***
*** Bug 692454 has been marked as a duplicate of this bug. ***
*** Bug 692451 has been marked as a duplicate of this bug. ***
*** Bug 692493 has been marked as a duplicate of this bug. ***
*** Bug 692492 has been marked as a duplicate of this bug. ***
*** Bug 692489 has been marked as a duplicate of this bug. ***
*** Bug 692508 has been marked as a duplicate of this bug. ***
*** Bug 692509 has been marked as a duplicate of this bug. ***
*** Bug 692504 has been marked as a duplicate of this bug. ***
*** Bug 692503 has been marked as a duplicate of this bug. ***
*** Bug 692502 has been marked as a duplicate of this bug. ***
*** Bug 692499 has been marked as a duplicate of this bug. ***
*** Bug 692498 has been marked as a duplicate of this bug. ***
*** Bug 692497 has been marked as a duplicate of this bug. ***
*** Bug 692505 has been marked as a duplicate of this bug. ***
*** Bug 692655 has been marked as a duplicate of this bug. ***
*** Bug 692712 has been marked as a duplicate of this bug. ***
*** Bug 692728 has been marked as a duplicate of this bug. ***
*** Bug 692729 has been marked as a duplicate of this bug. ***
*** Bug 692731 has been marked as a duplicate of this bug. ***
*** Bug 692809 has been marked as a duplicate of this bug. ***
There is a new policy build http://koji.fedoraproject.org/koji/buildinfo?buildID=237057 which should work together with a new systemd http://koji.fedoraproject.org/koji/buildinfo?buildID=237015
(In reply to comment #34) > There is a new policy build > > http://koji.fedoraproject.org/koji/buildinfo?buildID=237057 > > which should work together with a new systemd > > http://koji.fedoraproject.org/koji/buildinfo?buildID=237015 Thanks for these updates. Booting in enforcing mode is now possible. [joeblow@fir ~]$ sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 24 Policy from config file: targeted [joeblow@fir ~]$ rpm -qa 'selinux*' 'systemd*' | sort selinux-policy-3.9.16-9.fc15.noarch selinux-policy-targeted-3.9.16-9.fc15.noarch systemd-22-1.fc15.x86_64 systemd-units-22-1.fc15.x86_64 [joeblow@fir ~]$
systemd-22-1.fc15, selinux-policy-3.9.16-9.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-9.fc15,systemd-22-1.fc15
*** Bug 692896 has been marked as a duplicate of this bug. ***
There is a new policy build with some additional fixes http://koji.fedoraproject.org/koji/buildinfo?buildID=237061
(In reply to comment #38) > There is a new policy build with some additional fixes > > http://koji.fedoraproject.org/koji/buildinfo?buildID=237061 I'm still getting these two, which are closed as duplicates of this one: Bug 692729 - SELinux is preventing /usr/sbin/pcscd from 'read' accesses on the file c189:128. Bug 692476 - SELinux is preventing /usr/bin/pulseaudio from 'read' accesses on the file +sound:card0. selinux-policy-3.9.16-10.fc15.noarch selinux-policy-targeted-3.9.16-10.fc15.noarch
(In reply to comment #39) > (In reply to comment #38) > > There is a new policy build with some additional fixes > > > > http://koji.fedoraproject.org/koji/buildinfo?buildID=237061 > > I'm still getting these two, which are closed as duplicates of this one: > Bug 692729 - SELinux is preventing /usr/sbin/pcscd from 'read' accesses on the > file c189:128. > Bug 692476 - SELinux is preventing /usr/bin/pulseaudio from 'read' accesses on > the file +sound:card0. > > selinux-policy-3.9.16-10.fc15.noarch > selinux-policy-targeted-3.9.16-10.fc15.noarch After doing a full relabelling and restarting, I am also getting these: Bug 692731 - SELinux is preventing /usr/sbin/modem-manager from 'read' accesses on the file n1. Bug 692508 - SELinux is preventing NetworkManager from 'read' accesses on the file database.
Could you check how those files and directories are labeled under /run?
(In reply to comment #41) > Could you check how those files and directories are labeled under /run? There could be a better way, but I simply ran, e.g. $ ls --lcontext -R run | grep n1 -rw-r--r--. 1 system_u:object_r:tmpfs_t:s0 root root 30 Apr 1 10:17 n1 -rw-r--r--. 1 system_u:object_r:tmpfs_t:s0 root root 223 Apr 1 10:17 n2 -rw-r--r--. 1 system_u:object_r:tmpfs_t:s0 root root 427 Apr 1 10:17 c189:768 -rw-r--r--. 1 system_u:object_r:tmpfs_t:s0 root root 280 Apr 1 10:17 +sound:card0 -r--r--r--. 1 system_u:object_r:default_t:s0 root root 0 Apr 1 10:17 +sound:card0
Did you updated to the latest systemd also? I am not sure what is going on here. On my test machine, I see most files labelled correctly and the system boots fine in enforcing mode. But I am seeing tmpfs_t for labels under /run/mdadm.
(In reply to comment #43) > Did you updated to the latest systemd also? Yes: selinux-policy-3.9.16-10.fc15.noarch selinux-policy-targeted-3.9.16-10.fc15.noarch systemd-22-1.fc15.x86_64 systemd-units-22-1.fc15.x86_64 > I am not sure what is going on here. On my test machine, I see most files > labelled correctly and the system boots fine in enforcing mode. But I am > seeing tmpfs_t for labels under /run/mdadm. I finally remembered restorecon: :-) [joeblow@fir ~]$ sudo restorecon -rnv /run | grep n1 restorecon reset /run/udev/data/n1 context system_u:object_r:tmpfs_t:s0->system_u:object_r:udev_tbl_t:s0 [joeblow@fir ~]$ sudo restorecon -rnv /run | grep n2 restorecon reset /run/udev/data/n2 context system_u:object_r:tmpfs_t:s0->system_u:object_r:udev_tbl_t:s0 [joeblow@fir ~]$ sudo restorecon -rnv /run | grep c189:768 restorecon reset /run/udev/data/c189:768 context system_u:object_r:tmpfs_t:s0->system_u:object_r:udev_tbl_t:s0 [joeblow@fir ~]$ sudo restorecon -rnv /run | grep '+sound:card0' restorecon reset /run/udev/tags/systemd/+sound:card0 context system_u:object_r:default_t:s0->system_u:object_r:udev_tbl_t:s0 restorecon reset /run/udev/data/+sound:card0 context system_u:object_r:tmpfs_t:s0->system_u:object_r:udev_tbl_t:s0 [joeblow@fir ~]$
Steve, try to test it with the latest policy selinux-policy-3.9.16-11.fc15 which is available from koji.
systemd-22-1.fc15, selinux-policy-3.9.16-10.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #45) > Steve, > try to test it with the latest policy > > selinux-policy-3.9.16-11.fc15 > > which is available from koji. Unfortunately, the same four alerts are occurring, even after running "touch /.autorelabel" and rebooting. [joeblow@fir ~]$ sudo restorecon -rnv /run | grep n2 restorecon reset /run/udev/data/n2 context system_u:object_r:tmpfs_t:s0->system_u:object_r:udev_var_run_t:s0 [joeblow@fir ~]$ sudo restorecon -rnv /run | grep n1 restorecon reset /run/udev/data/n1 context system_u:object_r:tmpfs_t:s0->system_u:object_r:udev_var_run_t:s0 [joeblow@fir ~]$ sudo restorecon -rnv /run | grep 'c189:768' restorecon reset /run/udev/data/c189:768 context system_u:object_r:tmpfs_t:s0->system_u:object_r:udev_var_run_t:s0 [joeblow@fir ~]$ sudo restorecon -rnv /run | grep '+sound:card0' restorecon reset /run/udev/tags/systemd/+sound:card0 context system_u:object_r:default_t:s0->system_u:object_r:udev_var_run_t:s0 restorecon reset /run/udev/data/+sound:card0 context system_u:object_r:tmpfs_t:s0->system_u:object_r:udev_var_run_t:s0 [joeblow@fir ~]$ rpm -qa 'selinux*' 'systemd*' NetworkManager ModemManager pcsc-lite pulseaudio | sort ModemManager-0.4-7.git20110201.fc15.x86_64 NetworkManager-0.8.997-8.git20110331.fc15.x86_64 pcsc-lite-1.7.2-1.fc15.x86_64 pulseaudio-0.9.22-3.fc15.x86_64 selinux-policy-3.9.16-11.fc15.noarch selinux-policy-targeted-3.9.16-11.fc15.noarch systemd-22-1.fc15.x86_64 systemd-units-22-1.fc15.x86_64
*** Bug 693012 has been marked as a duplicate of this bug. ***
*** Bug 693051 has been marked as a duplicate of this bug. ***
*** Bug 693063 has been marked as a duplicate of this bug. ***
*** Bug 693724 has been marked as a duplicate of this bug. ***
*** Bug 693632 has been marked as a duplicate of this bug. ***
I filed Bug 693012. I think the worst AVC denial there applied to dbus -- the desktop wouldn't start up, and console logins didn't work either, meaning that the machine could only start in runlevel 1. Was that fixed in the last update? (I can't test on the relevant machine right now.)
yes
(In reply to comment #53) > I filed Bug 693012. I think the worst AVC denial there applied to dbus -- the > desktop wouldn't start up, and console logins didn't work either, meaning that > the machine could only start in runlevel 1. Was that fixed in the last update? > (I can't test on the relevant machine right now.) This seems to fix everything: https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-12.fc15,udev-167-2.fc15,systemd-23-1.fc15
*** Bug 693933 has been marked as a duplicate of this bug. ***
*** Bug 694424 has been marked as a duplicate of this bug. ***
I just got this on Fedora 15 with updated RPMs: SELinux is preventing /bin/systemd-tty-ask-password-agent from read access on the fifo_file 136:2. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that systemd-tty-ask-password-agent should be allowed read access on the 136:2 fifo_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep systemd-tty-ask /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context unconfined_u:system_r:systemd_passwd_agent_t:s0 Target Context unconfined_u:object_r:init_var_run_t:s0 Target Objects 136:2 [ fifo_file ] Source systemd-tty-ask Source Path /bin/systemd-tty-ask-password-agent Port <Unknown> Host larch.ezono.net Source RPM Packages systemd-26-10.fc15 Target RPM Packages Policy RPM selinux-policy-3.9.16-39.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name larch.ezono.net Platform Linux larch.ezono.net 2.6.40.6-0.fc15.i686.PAE #1 SMP Tue Oct 4 00:44:38 UTC 2011 i686 i686 Alert Count 5 First Seen Mon Oct 17 14:07:13 2011 Last Seen Mon Oct 17 14:33:15 2011 Local ID c8f9f375-24b1-48fb-b59f-5fcc7f301016 Raw Audit Messages type=AVC msg=audit(1318854795.241:4485): avc: denied { read } for pid=26046 comm="systemd-tty-ask" name="136:2" dev=tmpfs ino=2725891 scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0 tcontext=unconfined_u:object_r:init_var_run_t:s0 tclass=fifo_file type=AVC msg=audit(1318854795.241:4485): avc: denied { open } for pid=26046 comm="systemd-tty-ask" name="136:2" dev=tmpfs ino=2725891 scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0 tcontext=unconfined_u:object_r:init_var_run_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1318854795.241:4485): arch=i386 syscall=open success=yes exit=ESRCH a0=8f44080 a1=88900 a2=0 a3=bfc5c3a4 items=0 ppid=26045 pid=26046 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=362 comm=systemd-tty-ask exe=/bin/systemd-tty-ask-password-agent subj=unconfined_u:system_r:systemd_passwd_agent_t:s0 key=(null) Hash: systemd-tty-ask,systemd_passwd_agent_t,init_var_run_t,fifo_file,read audit2allow #============= systemd_passwd_agent_t ============== allow systemd_passwd_agent_t init_var_run_t:fifo_file { read open }; audit2allow -R #============= systemd_passwd_agent_t ============== allow systemd_passwd_agent_t init_var_run_t:fifo_file { read open };
It happens on a system using LDAP for authentication when TLS is enabled, UsePAM is disabled in sshd_config and I ssh to the system as LDAP user.
Could you try to run restorecon -R -v /var/run/systemd/ask-password-block/ and see if you can re-create this issue.
The command suggested has fixed the issue: # restorecon -R -v /var/run/systemd/ask-password-block/ restorecon reset /run/systemd/ask-password-block/136:1 context unconfined_u:object_r:init_var_run_t:s0->system_u:object_r:systemd_device_t:s0 restorecon reset /run/systemd/ask-password-block/136:0 context unconfined_u:object_r:init_var_run_t:s0->system_u:object_r:systemd_device_t:s0 After that the problem doesn't occur.
But do they get mislabeled on the next reboot?
After reboot /var/run/systemd/ask-password-block/ is empty. Then when trying to ssh as LDAP user fifos get created there with incorrect label. Sometimes there's more than one fifo in that directory. I saw a case when one of them had the correct label (most likely from previous restorecon) and the other two were mislabeled.
Btw, the actual authorization setup on this system is incorrect. I used by mistake --enableldaptls and a URL starting with ldaps:// at the same time. Problem doesn't happen if --disableldaptls is used or a URL starting with ldap:// With that mistake the authorization for SSH does work if I disable UsePAM in /etc/ssh/sshd_config but according bug 746660 that is not supported.
Slawomir please bring this bug to a new bug report.
Done, bug 747012