Bug 600123 - O SELinux está impedindo o acesso a /usr/sbin/abrtd "read write" on abrt-db
O SELinux está impedindo o acesso a /usr/sbin/abrtd "read write" on abrt-db
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
rawhide
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
setroubleshoot_trace_hash:2385b712859...
:
: 600122 600124 600125 600126 600127 600129 600130 600131 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-03 21:43 EDT by gelo
Modified: 2011-09-27 21:49 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-04 03:39:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description gelo 2010-06-03 21:43:48 EDT
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 01:33:06 EDT
*** Bug 600122 has been marked as a duplicate of this bug. ***
Comment 2 Miroslav Grepl 2010-06-04 01:33:29 EDT
*** Bug 600124 has been marked as a duplicate of this bug. ***
Comment 3 Miroslav Grepl 2010-06-04 01:33:44 EDT
*** Bug 600125 has been marked as a duplicate of this bug. ***
Comment 4 Miroslav Grepl 2010-06-04 01:34:01 EDT
*** Bug 600126 has been marked as a duplicate of this bug. ***
Comment 5 Miroslav Grepl 2010-06-04 01:34:21 EDT
*** Bug 600127 has been marked as a duplicate of this bug. ***
Comment 6 Miroslav Grepl 2010-06-04 01:34:38 EDT
*** Bug 600129 has been marked as a duplicate of this bug. ***
Comment 7 Miroslav Grepl 2010-06-04 01:35:00 EDT
*** Bug 600130 has been marked as a duplicate of this bug. ***
Comment 8 Miroslav Grepl 2010-06-04 01:35:32 EDT
*** Bug 600131 has been marked as a duplicate of this bug. ***
Comment 9 Miroslav Grepl 2010-06-04 03:39:07 EDT
restorecon -R -v /var/spool
Comment 10 datahal42 2010-08-22 11:09:47 EDT
not work for my
Comment 11 datahal42 2010-08-22 12:56:13 EDT
miroslav works thaks.
Comment 12 Dirk Hoffmann 2010-09-21 12:54:19 EDT
(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 08:41:39 EDT
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 09:34:58 EDT
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 11:03:27 EDT
So it could have been an update issue or some script let is doing it.  Repoen if it goes back to being bad.

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