Bug 600123

Summary: O SELinux está impedindo o acesso a /usr/sbin/abrtd "read write" on abrt-db
Product: [Fedora] Fedora Reporter: gelo <emanwesk-2>
Component: selinux-policyAssignee: Daniel Walsh <dwalsh>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: bugsubmitter, cwolfe8, datahal42, dseroka, dwalsh, Ghiyasimehr, hoffmann, irsian2, joe_underscore, lucro, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:2385b71285942f97697ee7311fba888c693beabe79111a8041bc1de5e6977fc7
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-06-04 07:39:07 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 gelo 2010-06-04 01:43:48 UTC
Sumário:

O SELinux está impedindo o acesso a /usr/sbin/abrtd "read write" on abrt-db

Descrição detalhada:

[SElinux está em modo permissivo. Esse acesso não foi negado.]

O SELinux impediu o acesso requisitado pelo abrtd. Não é comum que este acesso
seja requisitado pelo abrtd e isto pode indicar uma tentativa de intrusão.
Também é possível que a versão ou configuração específicas do aplicativo
estejam fazendo com que o mesmo requisite o acesso adicio

Permitindo acesso:

Você pode gerar um módulo de política local para permitir este acesso - veja
o FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Por favor,
registre um relatório de erro.

Informações adicionais:

Contexto de origem            system_u:system_r:abrt_t:s0
Contexto de destino           unconfined_u:object_r:var_spool_t:s0
Objetos de destino            abrt-db [ file ]
Origem                        abrtd
Caminho da origem             /usr/sbin/abrtd
Porta                         <Desconhecido>
Máquina                      (removido)
Pacotes RPM de origem         abrt-1.1.4-1.fc14
Pacotes RPM de destino        
RPM da política              selinux-policy-3.8.1-4.fc14
Selinux habilitado            True
Tipo de política             targeted
Modo reforçado               Permissive
Nome do plugin                catchall
Nome da máquina              (removido)
Plataforma                    Linux (removido) 2.6.32.11-99.fc12.x86_64 #1 SMP Mon
                              Apr 5 19:59:38 UTC 2010 x86_64 x86_64
Contador de alertas           16
Visto pela primeira vez em    Qui 03 Jun 2010 12:04:43 BRT
Visto pela última vez em     Qui 03 Jun 2010 18:33:26 BRT
ID local                      05c1d1b3-f387-47d5-a650-d1bdc2261e79
Números de linha             

Mensagens de auditoria não p 

node=(removido) type=AVC msg=audit(1275600806.343:23): avc:  denied  { read write } for  pid=1742 comm="abrtd" name="abrt-db" dev=sda2 ino=135091 scontext=system_u:system_r:abrt_t:s0 tcontext=unconfined_u:object_r:var_spool_t:s0 tclass=file

node=(removido) type=AVC msg=audit(1275600806.343:23): avc:  denied  { open } for  pid=1742 comm="abrtd" name="abrt-db" dev=sda2 ino=135091 scontext=system_u:system_r:abrt_t:s0 tcontext=unconfined_u:object_r:var_spool_t:s0 tclass=file

node=(removido) type=SYSCALL msg=audit(1275600806.343:23): arch=c000003e syscall=2 success=yes exit=9 a0=1876260 a1=2 a2=1a4 a3=1a4 items=0 ppid=1 pid=1742 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="abrtd" exe="/usr/sbin/abrtd" subj=system_u:system_r:abrt_t:s0 key=(null)



Hash String generated from  catchall,abrtd,abrt_t,var_spool_t,file,read,write
audit2allow suggests:

#============= abrt_t ==============
#!!!! The source type 'abrt_t' can write to a 'file' of the following type:
# abrt_var_run_t
#!!!! The source type 'abrt_t' can write to a 'file' of the following type:
# abrt_var_run_t
#!!!! The source type 'abrt_t' can write to a 'file' of the following types:
# abrt_var_run_t, sysfs_t
#!!!! The source type 'abrt_t' can write to a 'file' of the following types:
# abrt_var_run_t, sysfs_t, abrt_tmp_t
#!!!! The source type 'abrt_t' can write to a 'file' of the following types:
# abrt_var_run_t, sysfs_t, abrt_tmp_t, domain
#!!!! The source type 'abrt_t' can write to a 'file' of the following types:
# abrt_var_run_t, sysfs_t, abrt_tmp_t, domain, rpm_var_cache_t
#!!!! The source type 'abrt_t' can write to a 'file' of the following types:
# abrt_var_run_t, sysfs_t, abrt_tmp_t, domain, rpm_var_cache_t, abrt_var_cache_t
#!!!! The source type 'abrt_t' can write to a 'file' of the following types:
# abrt_var_run_t, sysfs_t, abrt_tmp_t, domain, rpm_var_cache_t, abrt_var_cache_t, abrt_etc_t
#!!!! The source type 'abrt_t' can write to a 'file' of the following types:
# abrt_var_run_t, sysfs_t, abrt_tmp_t, domain, rpm_var_cache_t, abrt_var_cache_t, abrt_etc_t, abrt_var_log_t
#!!!! The source type 'abrt_t' can write to a 'file' of the following types:
# abrt_var_run_t, sysfs_t, abrt_tmp_t, domain, rpm_var_cache_t, abrt_var_cache_t, abrt_etc_t, abrt_var_log_t, rpm_var_run_t
#!!!! The source type 'abrt_t' can write to a 'file' of the following types:
# abrt_var_run_t, sysfs_t, abrt_tmp_t, domain, rpm_var_cache_t, abrt_var_cache_t, abrt_etc_t, abrt_var_log_t, rpm_var_run_t, sysctl_kernel_t
#!!!! The source type 'abrt_t' can write to a 'file' of the following types:
# abrt_var_run_t, sysfs_t, abrt_tmp_t, domain, rpm_var_cache_t, abrt_var_cache_t, abrt_etc_t, abrt_var_log_t, rpm_var_run_t, sysctl_kernel_t, root_t

allow abrt_t var_spool_t:file { read write open };

Comment 1 Miroslav Grepl 2010-06-04 05:33:06 UTC
*** Bug 600122 has been marked as a duplicate of this bug. ***

Comment 2 Miroslav Grepl 2010-06-04 05:33:29 UTC
*** Bug 600124 has been marked as a duplicate of this bug. ***

Comment 3 Miroslav Grepl 2010-06-04 05:33:44 UTC
*** Bug 600125 has been marked as a duplicate of this bug. ***

Comment 4 Miroslav Grepl 2010-06-04 05:34:01 UTC
*** Bug 600126 has been marked as a duplicate of this bug. ***

Comment 5 Miroslav Grepl 2010-06-04 05:34:21 UTC
*** Bug 600127 has been marked as a duplicate of this bug. ***

Comment 6 Miroslav Grepl 2010-06-04 05:34:38 UTC
*** Bug 600129 has been marked as a duplicate of this bug. ***

Comment 7 Miroslav Grepl 2010-06-04 05:35:00 UTC
*** Bug 600130 has been marked as a duplicate of this bug. ***

Comment 8 Miroslav Grepl 2010-06-04 05:35:32 UTC
*** Bug 600131 has been marked as a duplicate of this bug. ***

Comment 9 Miroslav Grepl 2010-06-04 07:39:07 UTC
restorecon -R -v /var/spool

Comment 10 datahal42 2010-08-22 15:09:47 UTC
not work for my

Comment 11 datahal42 2010-08-22 16:56:13 UTC
miroslav works thaks.

Comment 12 Dirk Hoffmann 2010-09-21 16:54:19 UTC
(In reply to comment #9)
> restorecon -R -v /var/spool

Shouldn't this be done in the install/update process somewhere?

I applied it (sudo restorecon -R -v /var/spool) and am waiting, if the bug reappears.

Comment 13 Daniel Walsh 2010-09-22 12:41:39 UTC
The directory should be created during the install of abrt with the correct label. And updates attempt to figure out the difference between old labelling and new labelling on updates.  Some times it makes mistakes and sometimes admins or other scripts remove and create directories with the wrong label.  I do not know if this directory was mislabelled when it was originally created or if it got mislabelled during normal use.  If it happens again, we will know that some process is recreating the directory with the wrong label.

Comment 14 Dirk Hoffmann 2010-09-22 13:34:58 UTC
Hi Daniel, (In reply to comment #13)

> The directory should be created during the install of abrt with the correct
> label. And updates attempt to figure out the difference between old labelling
> and new labelling on updates.  Some times it makes mistakes and sometimes
> admins or other scripts remove and create directories with the wrong label.  I
> do not know if this directory was mislabelled when it was originally created or
> if it got mislabelled during normal use.  If it happens again, we will know
> that some process is recreating the directory with the wrong label.

I can attest that I (only admin/root on the machine in question) did not install the directory manually. Anything that has (mis)happened, did so in an automatic way. 

I did not observe the bug appear again in the usual situations (after reboot/login) up to now.

Comment 15 Daniel Walsh 2010-09-22 15:03:27 UTC
So it could have been an update issue or some script let is doing it.  Repoen if it goes back to being bad.