Bug 646225

Dmitri,
could you execute

# semanage permissive -a certmonger_t

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

This bug came from the list. I sent email and asked the person who reported the issue for help.

Created attachment 455556 [details]
detail of sealert -l command

I attached the sealert command for those AVC

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?

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

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

Miroslav add

dontaudit certmonger_t self:capability sys_tty_config;

auth_rw_cache(certmonger_t)
pcscd_read_pub_files(certmonger_t)

to certmonger.te

Fixed in selinux-policy-3.7.19-70.fc13

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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