Bug 646225 - SELinux prevents certmonger from executing IPA client
Summary: SELinux prevents certmonger from executing IPA client
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 13
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-25 01:08 UTC by Dmitri Pal
Modified: 2011-05-31 11:51 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-31 11:51:16 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
detail of sealert -l command (7.79 KB, application/octet-stream)
2010-10-25 15:20 UTC, Ide
no flags Details

Description Dmitri Pal 2010-10-25 01:08:14 UTC
Oct 24 10:57:24 ulasi setroubleshoot: SELinux is preventing /usr/sbin/certmonger "execute" access on /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2
Oct 24 10:57:56 ulasi setroubleshoot: SELinux is preventing /usr/sbin/certmonger "execute" access on /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2
Oct 24 10:58:26 ulasi setroubleshoot: SELinux is preventing /usr/sbin/certmonger "execute" access on /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2
Oct 24 10:58:57 ulasi setroubleshoot: SELinux is preventing /usr/sbin/certmonger "execute" access on /usr/libexec/certmonger/ipa-submit. For complete SELinux messages. run sealert -l 8db766a3-6100-4be5-aec6-2a3a713290e2


Summary:

SELinux is preventing /usr/sbin/certmonger "execute" access on
/usr/libexec/certmonger/ipa-submit.

Detailed Description:

SELinux denied access requested by certmonger. It is not expected that this
access is required by certmonger 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://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug
report.

Additional Information:

Source Context                system_u:system_r:certmonger_t:s0
Target Context                system_u:object_r:bin_t:s0
Target Objects                /usr/libexec/certmonger/ipa-submit [ file ]
Source                        certmonger
Source Path                   /usr/sbin/certmonger
Port                          <Unknown>
Host                          ulasi.uzdomain.ca
Source RPM Packages           certmonger-0.32-0.2010101515git5920eca.fc13
Target RPM Packages           certmonger-0.32-0.2010101515git5920eca.fc13
Policy RPM                    selinux-policy-3.7.19-65.fc13
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     ulasi.uzdomain.ca
Platform                      Linux ulasi.uzdomain.ca 2.6.34.7-61.fc13.i686.PAE
                              #1 SMP Tue Oct 19 04:24:06 UTC 2010 i686 i686
Alert Count                   1646
First Seen                    Sat Oct 23 15:48:48 2010
Last Seen                     Sun Oct 24 10:59:52 2010
Local ID                      8db766a3-6100-4be5-aec6-2a3a713290e2
Line Numbers                 

Raw Audit Messages           

node=ulasi.uzdomain.ca type=AVC msg=audit(1287932392.282:21690): avc:  denied  { execute } for  pid=3472 comm="certmonger" name="ipa-submit" dev=dm-0 ino=790251 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file

node=ulasi.uzdomain.ca type=SYSCALL msg=audit(1287932392.282:21690): arch=40000003 syscall=11 success=no exit=-13 a0=9f99490 a1=9f99450 a2=9f98e60 a3=9f99450 items=0 ppid=1555 pid=3472 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="certmonger" exe="/usr/sbin/certmonger" subj=system_u:system_r:certmonger_t:s0 key=(null)

I was using certmonger-0.30-1.fc13.i686 from source [ freeipa-devel ] because of the problem I updated to the nightly build certmonger-0.32-0.2010101515git5920eca.fc13 but the problem continues.

These are the selinux rpms
selinux-policy-targeted-3.7.19-65.fc13.noarch
selinux-policy-3.7.19-65.fc13.noarch
libselinux-python-2.0.94-2.fc13.i686
libselinux-utils-2.0.94-2.fc13.i686

Comment 1 Miroslav Grepl 2010-10-25 08:33:48 UTC
Dmitri,
could you execute

# semanage permissive -a certmonger_t

You will get other AVC messages, which we want to see. Thanks.

Comment 2 Dmitri Pal 2010-10-25 12:15:54 UTC
This bug came from the list. I sent email and asked the person who reported the issue for help.

Comment 3 Ide 2010-10-25 15:20:51 UTC
Created attachment 455556 [details]
detail of sealert -l command

I attached the sealert command for those AVC

Comment 4 Daniel Walsh 2010-10-25 15:36:26 UTC
Now we have multiple avcs coming in on certmonger,  

One indicates it is executing ipa-submit.


The log shows it 

allow certmonger_t auth_cache_t:file { read write };
# ^^ Could this be a leak?

allow certmonger_t pcscd_var_run_t:file { read open };
# ^^ Certmonger wants to read /var/run/pcscd.pid?

allow certmonger_t self:capability sys_tty_config;
# Does certmonger do something with the terminal?  Usually see bash doing stuff like this?

Comment 5 Ide 2010-10-25 15:39:43 UTC
I ran the command 
 semanage permissive -a certmonger_t

There was not output.

I should point out that while I was battling with this issue yesterday, I ran the following commands

audit2allow  -a -M <filename>
then 
semodule -i <filename>

I did not see that AVC denials any longer after that but in log there were these entries

Oct 24 16:47:37 ulasi setroubleshoot: Deleting alert 5b0b757c-89a4-49d2-90c8-f10ee69691f1, it is allowed in current policy
Oct 24 16:51:17 ulasi setroubleshoot: Deleting alert 8db766a3-6100-4be5-aec6-2a3a713290e2, it is allowed in current policy 

8db766a3-6100-4be5-aec6-2a3a713290e2 happens to be the audit id. Also I started seeing other different AVC as shown below:



Oct 25 09:53:21 ulasi setroubleshoot: SELinux is preventing /usr/sbin/certmonger "read" access on /var/run/pcscd.pid. For complete SELinux messages. run sealert -l 50dd5c94-ec6f-465f-90b8-469830fc5895
Oct 25 09:53:21 ulasi setroubleshoot: SELinux is preventing /usr/sbin/certmonger "read" access on /var/run/pcscd.pid. For complete SELinux messages. run sealert -l 50dd5c94-ec6f-465f-90b8-469830fc5895
Oct 25 09:53:21 ulasi setroubleshoot: SELinux is preventing /usr/sbin/certmonger "sys_tty_config" access . For complete SELinux messages. run sealert -l 18baa05e-8b70-49a4-bffb-5fa25290c8c1
Oct 25 09:53:21 ulasi setroubleshoot: SELinux is preventing /usr/sbin/certmonger "read write" access on coolkeypk11sE-Gate 0 0-0. For complete SELinux messages. run sealert -l 02720c30-8ce4-4028-be4c-158dc234c4e2

I went ahead and reboot the system a couple of times with /.autorelabel set, but am still getting these AVCs.

The only difference that I noticed after running your command is that 
selinux flags these audit failures but say they are not denied because certmonger_t is permissive.

thanks

Ide

Comment 6 Nalin Dahyabhai 2010-10-26 14:13:26 UTC
(In reply to comment #4)
> Now we have multiple avcs coming in on certmonger,  
> 
> One indicates it is executing ipa-submit.

That's one of its submit-a-signing-request-to-a-CA helpers, yes.
 
> The log shows it 
> 
> allow certmonger_t auth_cache_t:file { read write };
> # ^^ Could this be a leak?
> 
> allow certmonger_t pcscd_var_run_t:file { read open };
> # ^^ Certmonger wants to read /var/run/pcscd.pid?

Anything that uses NSS can end up using PKCS11 modules by way of NSS, and it looks like the database we're using has the coolkey module registered.

> allow certmonger_t self:capability sys_tty_config;
> # Does certmonger do something with the terminal?  Usually see bash doing stuff
> like this?

This one I'm not entirely sure of.  Which syscalls end up using this access vector?

Comment 7 Daniel Walsh 2010-11-01 15:43:56 UTC
Miroslav add

dontaudit certmonger_t self:capability sys_tty_config;

auth_rw_cache(certmonger_t)
pcscd_read_pub_files(certmonger_t)

to certmonger.te

Comment 8 Miroslav Grepl 2010-11-02 16:07:36 UTC
Fixed in selinux-policy-3.7.19-70.fc13

Comment 9 Fedora Admin XMLRPC Client 2010-11-08 21:51:07 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 Fedora Admin XMLRPC Client 2010-11-08 21:52:22 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 11 Fedora Admin XMLRPC Client 2010-11-08 21:54:54 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 12 Bug Zapper 2011-05-31 10:43:24 UTC
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


Note You need to log in before you can comment on or make changes to this bug.