Bug 533161
| Summary: | Two SELinux denials with default Corosync config | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tore Anderson <tore> |
| Component: | corosync | Assignee: | Christine Caulfield <ccaulfie> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 12 | CC: | agk, dwalsh, fdinitto, mgrepl, sdake |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-11-04 08:34:27 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Tore Anderson
2009-11-05 12:42:34 UTC
After having run it for a few minutes, two new denials appeared: Nov 5 13:48:09 cognac1 setroubleshoot: SELinux is preventing /usr/sbin/corosync "read write" access on control_buffer-YTA8he. For complete SELinux messages. run sealert -l 7eee9e3b-fe94-47da-8e80-77b5054fe992 Nov 5 13:48:10 cognac1 setroubleshoot: SELinux is preventing /usr/sbin/corosync "unlink" access on control_buffer-YTA8he. For complete SELinux messages. run sealert -l a53cc84e-e352-4509-abaf-c3c47f7d4021 [root@cognac1 corosync]# sealert -l 7eee9e3b-fe94-47da-8e80-77b5054fe992 Summary: SELinux is preventing /usr/sbin/corosync "read write" access on control_buffer-YTA8he. Detailed Description: [corosync has a permissive type (corosync_t). This access was not denied.] SELinux denied access requested by corosync. It is not expected that this access is required by corosync 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 unconfined_u:system_r:corosync_t:s0 Target Context unconfined_u:object_r:user_tmpfs_t:s0 Target Objects control_buffer-YTA8he [ file ] Source corosync Source Path /usr/sbin/corosync Port <Unknown> Host cognac1.vm Source RPM Packages corosync-1.1.2-1.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-40.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name cognac1.vm Platform Linux cognac1.vm 2.6.31.1-56.fc12.i686 #1 SMP Tue Sep 29 16:32:02 EDT 2009 i686 i686 Alert Count 2 First Seen Thu Nov 5 13:48:05 2009 Last Seen Thu Nov 5 13:48:05 2009 Local ID 7eee9e3b-fe94-47da-8e80-77b5054fe992 Line Numbers Raw Audit Messages node=cognac1.vm type=AVC msg=audit(1257425285.292:92): avc: denied { read write } for pid=10672 comm="corosync" name="control_buffer-YTA8he" dev=tmpfs ino=81070 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=unconfined_u:object_r:user_tmpfs_t:s0 tclass=file node=cognac1.vm type=AVC msg=audit(1257425285.292:92): avc: denied { open } for pid=10672 comm="corosync" name="control_buffer-YTA8he" dev=tmpfs ino=81070 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=unconfined_u:object_r:user_tmpfs_t:s0 tclass=file node=cognac1.vm type=SYSCALL msg=audit(1257425285.292:92): arch=40000003 syscall=5 success=yes exit=10 a0=9be83d4 a1=2 a2=180 a3=9be83d4 items=0 ppid=1 pid=10672 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="corosync" exe="/usr/sbin/corosync" subj=unconfined_u:system_r:corosync_t:s0 key=(null) [root@cognac1 corosync]# sealert -l a53cc84e-e352-4509-abaf-c3c47f7d4021 Summary: SELinux is preventing /usr/sbin/corosync "unlink" access on control_buffer-YTA8he. Detailed Description: [corosync has a permissive type (corosync_t). This access was not denied.] SELinux denied access requested by corosync. It is not expected that this access is required by corosync 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 unconfined_u:system_r:corosync_t:s0 Target Context unconfined_u:object_r:user_tmpfs_t:s0 Target Objects control_buffer-YTA8he [ file ] Source corosync Source Path /usr/sbin/corosync Port <Unknown> Host cognac1.vm Source RPM Packages corosync-1.1.2-1.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-40.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name cognac1.vm Platform Linux cognac1.vm 2.6.31.1-56.fc12.i686 #1 SMP Tue Sep 29 16:32:02 EDT 2009 i686 i686 Alert Count 1 First Seen Thu Nov 5 13:48:05 2009 Last Seen Thu Nov 5 13:48:05 2009 Local ID a53cc84e-e352-4509-abaf-c3c47f7d4021 Line Numbers Raw Audit Messages node=cognac1.vm type=AVC msg=audit(1257425285.292:93): avc: denied { unlink } for pid=10672 comm="corosync" name="control_buffer-YTA8he" dev=tmpfs ino=81070 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=unconfined_u:object_r:user_tmpfs_t:s0 tclass=file node=cognac1.vm type=SYSCALL msg=audit(1257425285.292:93): arch=40000003 syscall=10 success=yes exit=0 a0=9be83d4 a1=0 a2=44c0f8 a3=9be83d4 items=0 ppid=1 pid=10672 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="corosync" exe="/usr/sbin/corosync" subj=unconfined_u:system_r:corosync_t:s0 key=(null) Lets look at these one at a time. setrlimit added. Connect to udp port 5404, is this a standard port that coreosync should be allowed to listen on, or just your local customization? Currently coreosync can bind to UDP 5405 labeled netsupport_port_t. So you could add this port to this label # semanage port -a -t netsupport_port_t -p udp 5404 Which will allow it to work, and request that I make this change, if it is a default. The later avc's seem to be corosync communicating with a logged in user through the tmpfs directory probably under /dev/shm? Is this expected behaviour? To be quite honest, I don't know if it's the expected behaviour or not. I never played around with corosync before - what I was trying to do is make lvm2-cluster work (which depends on corosync). Figured out later on that you'll need cman also for it to work. In any case - everything is at its defaults, I only copied /etc/corosync/corosync.conf.example to /etc/corosync/corosync.conf and changed the bindnetaddr option to match my local network. Port 5404/udp was a default set in the example file - but I don't know if it's an IANA registered port or not though. After I got things up and running some more I got even more SELinux warnings so I ended up figuring that nobody have actually developed a proper policy corosync... My test environment is in a couple of KVM instances at work so I don't have access to it at the moment. I'll check tomorrow. Tore Port 5404 is a standard corosync port. it uses both 5405 and 5404 for communications, both UDP. Those denials look like things that should have been flushed out very early on in the testing of this policy. I remember seeing the shm ones quite frequently myself! To be honest, all of my SELinux testing was done using RHCS rather than corosync on its own so it will have been started from the cman script rather than the corosync one. I think the following command line should cure the trouble. Can you try it please and report back? # chcon -t initrc_exec_t /etc/init.d/corosync It works for me, so if it works for you too then I'll ask Dan to include it in the policy Thanks, Chrissie Fixed in selinux-policy-3.6.32-43.fc12.noarch Let's see. Just started up Corosync on my two cluster nodes after having run the chcon command suggested - the following warnings occur during startup: Nov 11 13:36:35 cognac2 setroubleshoot: SELinux is preventing /usr/sbin/corosync "setrlimit" access. For complete SELinux messages. run sealert -l 63a1aad0-8261-4b27-b43c-f3e1696c0f32 Nov 11 13:36:36 cognac2 setroubleshoot: SELinux is preventing /usr/sbin/corosync from binding to port 5404. For complete SELinux messages. run sealert -l 536c2a7b-5d36-4c14-bedc-af7fdfbb9547 Then a little bit later: Nov 11 13:37:51 cognac2 setroubleshoot: SELinux is preventing /usr/sbin/corosync "read write" access on control_buffer-lI6TB7. For complete SELinux messages. run sealert -l 1ee101c5-738e-4769-8257-1190e6e3eda1 Nov 11 13:37:52 cognac2 setroubleshoot: SELinux is preventing /usr/sbin/corosync "read write" access on control_buffer-lI6TB7. For complete SELinux messages. run sealert -l 1ee101c5-738e-4769-8257-1190e6e3eda1 Nov 11 13:37:52 cognac2 setroubleshoot: SELinux is preventing /usr/sbin/corosync "unlink" access on control_buffer-lI6TB7. For complete SELinux messages. run sealert -l c232d223-8724-4a88-bfb0-3758ef79485d And after some more time: Nov 11 13:40:31 cognac2 setroubleshoot: SELinux is preventing /usr/sbin/corosync "read write" access on control_buffer-KNuFq2. For complete SELinux messages. run sealert -l 6849508d-2c52-4cbb-89db-c21a013e455a Nov 11 13:40:32 cognac2 setroubleshoot: SELinux is preventing /usr/sbin/corosync "read write" access on control_buffer-KNuFq2. For complete SELinux messages. run sealert -l 6849508d-2c52-4cbb-89db-c21a013e455a Nov 11 13:40:32 cognac2 setroubleshoot: SELinux is preventing /usr/sbin/corosync "unlink" access on control_buffer-KNuFq2. For complete SELinux messages. run sealert -l 37d38763-10e8-41ee-862f-b7a4e7e55930 These _might_ be related to me running "corosync-cfgtool -s". Not sure, though. Tell me if you need any more info... Tore How are you starting corosync? When I started it using 'service corosync start' it ran cleanly, and I tried several connections to it from corosync tools. Check that the SELinux context is right on the file. It should look like this: # ls -lZ /etc/init.d/corosync -rwxr-xr-x. root root system_u:object_r:initrc_exec_t:s0 /etc/init.d/corosync Tore have you tried the newer policy? Daniel, no, I just did a yum upgrade and it pulled down a new policy (selinux-policy-3.6.32-41.fc12.noarch), so I don't know where to get 3.6.32-43. Perhaps my mirror is lagging behind? Tore Christine, yes, the context on the file should be correct. I used the "service" tool to start it, exactly like you suggest. $ ls -lZ /etc/init.d/corosync -rwxr-xr-x. root root system_u:object_r:initrc_exec_t:s0 /etc/init.d/corosync Tore 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 It looks like the -43 policy didn't make it into Fedora12 so you'll have to wait for the first updates to filter through for it. But the chcon should have fixed the problem. With that context on the corosync init script I can run it quite happily with no AVCs. Are you getting the same AVC error messages as before when you start corosync or are they different? If they are different can you post them please ? I accidentally nuked the images backing the virtual machines where I was testing this stuff, so I'll have to set it up from scratch again before I can test. I'll probably do so before the end of the week (but after F12 is out :-). Tore Ok. Now I've just installed two standard F12 virtual machines (on a F12 host machine), done a full yum upgrade to bring it up-to-date, and did the following (on both nodes): [root@corotest1 ~]# rpm -qa corosync selinux-policy corosync-1.1.2-1.fc12.x86_64 selinux-policy-3.6.32-41.fc12.noarch [root@corotest1 ~]# ls -lZ /etc/init.d/corosync -rwxr-xr-x. root root system_u:object_r:corosync_initrc_exec_t:s0 /etc/init.d/corosync [root@corotest1 ~]# mv /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf [root@corotest1 ~]# sed -i 's/192.168.1.1/192.168.122.0/' /etc/corosync/corosync.conf [root@corotest1 ~]# service corosync start Starter Corosync klyngemotor (corosync): [ OK ] I still get denials in /var/log/messages: Nov 22 16:58:24 localhost setroubleshoot: SELinux is preventing /usr/sbin/corosync "setrlimit" access. For complete SELinux messages. run sealert -l bbd1de95-7d78-433c-a624-d6ee2ec60f1e Nov 22 16:58:24 localhost setroubleshoot: SELinux is preventing /usr/sbin/corosync from binding to port 5404. For complete SELinux messages. run sealert -l 19f4566f-23e5-4c47-bcd2-4e84c68fc42b Afterwards I tried to change the contect on /etc/init.d/corosync: [root@corotest1 ~]# chcon system_u:object_r:initrc_exec_t:s0 /etc/init.d/corosync Rebooted and tried to start it again but it did not have any effect: Nov 22 17:04:35 localhost setroubleshoot: SELinux is preventing /usr/sbin/corosync "setrlimit" access. For complete SELinux messages. run sealert -l bbd1de95-7d78-433c-a624-d6ee2ec60f1e Nov 22 17:04:35 localhost setroubleshoot: SELinux is preventing /usr/sbin/corosync from binding to port 5404. For complete SELinux messages. run sealert -l 19f4566f-23e5-4c47-bcd2-4e84c68fc42b I'll be leaving it running for a while to see if the other messages show up as well. Tore No messages appeared in 45 minutes. So I ran "corosync-cfgtool -s" and then a few seconds later the following appeared in the log: Nov 22 17:46:56 localhost setroubleshoot: SELinux is preventing /usr/sbin/corosync "read write" access on control_buffer-FraBvB. For complete SELinux messages. run sealert -l a464693d-9f42-49cc-a2b5-24ec625d4675 Nov 22 17:46:56 localhost setroubleshoot: SELinux is preventing /usr/sbin/corosync "read write" access on control_buffer-FraBvB. For complete SELinux messages. run sealert -l a464693d-9f42-49cc-a2b5-24ec625d4675 Nov 22 17:46:56 localhost setroubleshoot: SELinux is preventing /usr/sbin/corosync "unlink" access on control_buffer-FraBvB. For complete SELinux messages. run sealert -l 2dcb12a1-4ac3-4c7d-9039-573a95eeb276 Tore Probably a leak, but I need to see the output from sealert -l a464693d-9f42-49cc-a2b5-24ec625d4675 Here you go: [root@corotest2 ~]# sealert -l a464693d-9f42-49cc-a2b5-24ec625d4675 Summary: SELinux is preventing /usr/sbin/corosync "read write" access on control_buffer-FraBvB. Detailed Description: [corosync has a permissive type (corosync_t). This access was not denied.] SELinux denied access requested by corosync. It is not expected that this access is required by corosync 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 unconfined_u:system_r:corosync_t:s0 Target Context unconfined_u:object_r:user_tmpfs_t:s0 Target Objects control_buffer-FraBvB [ file ] Source corosync Source Path /usr/sbin/corosync Port <Unknown> Host corotest2 Source RPM Packages corosync-1.1.2-1.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-41.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name corotest2 Platform Linux corotest2 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 Alert Count 2 First Seen Sun Nov 22 17:46:52 2009 Last Seen Sun Nov 22 17:46:52 2009 Local ID a464693d-9f42-49cc-a2b5-24ec625d4675 Line Numbers Raw Audit Messages node=corotest2 type=AVC msg=audit(1258908412.773:19437): avc: denied { read write } for pid=1486 comm="corosync" name="control_buffer-FraBvB" dev=tmpfs ino=12549 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=unconfined_u:object_r:user_tmpfs_t:s0 tclass=file node=corotest2 type=AVC msg=audit(1258908412.773:19437): avc: denied { open } for pid=1486 comm="corosync" name="control_buffer-FraBvB" dev=tmpfs ino=12549 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=unconfined_u:object_r:user_tmpfs_t:s0 tclass=file node=corotest2 type=SYSCALL msg=audit(1258908412.773:19437): arch=c000003e syscall=2 success=yes exit=10 a0=22cd4a0 a1=2 a2=180 a3=7fffd41dcce0 items=0 ppid=1 pid=1486 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="corosync" exe="/usr/sbin/corosync" subj=unconfined_u:system_r:corosync_t:s0 key=(null) The IPC client creates various files in /dev/shm using mkstemp(). If mkstemp fails, the ipc client fails. Once the IPC client has created the shared memory segments, it passes their filenames via unix sockets secured by UID/GID into the corosync server which then mmap's them into the Corosync address space for reading/writing. This is a common way of doing secure shared memory IPC. Regards -steve 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-48.fc12.noarch 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 |