Bug 1070268 - SELinux is preventing /usr/bin/clamscan from 'write' accesses on the fifo_file .
Summary: SELinux is preventing /usr/bin/clamscan from 'write' accesses on the fifo_file .
Keywords:
Status: CLOSED DUPLICATE of bug 864143
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:750c53dd486fbd18a282827c7b5...
: 1069958 1070496 1070944 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-26 14:08 UTC by D. Charles Pyle
Modified: 2014-04-24 01:31 UTC (History)
29 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-04-24 01:31:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description D. Charles Pyle 2014-02-26 14:08:28 UTC
Description of problem:
Keep seeing this error constantly.  Clamscan should be able to write to pretty much anything.
SELinux is preventing /usr/bin/clamscan from 'write' accesses on the fifo_file .

*****  Plugin leaks (86.2 confidence) suggests   *****************************

If you want to ignore clamscan trying to write access the  fifo_file, because you believe it should not need this access.
Then you should report this as a bug.  
You can generate a local policy module to dontaudit this access.
Do
# grep /usr/bin/clamscan /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

*****  Plugin catchall (14.7 confidence) suggests   **************************

If you believe that clamscan should be allowed write access on the  fifo_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep clamscan /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:antivirus_t:s0-s0:c0.c1023
Target Context                system_u:object_r:systemd_logind_sessions_t:s0
Target Objects                 [ fifo_file ]
Source                        clamscan
Source Path                   /usr/bin/clamscan
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           clamav-0.98.1-1.fc21.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-27.fc21.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 3.14.0-0.rc4.git0.1.fc21.x86_64 #1
                              SMP Mon Feb 24 14:01:55 UTC 2014 x86_64 x86_64
Alert Count                   1
First Seen                    2014-02-26 03:50:33 MST
Last Seen                     2014-02-26 03:50:33 MST
Local ID                      5abd2d2a-4e40-46ce-8668-70599f30bce1

Raw Audit Messages
type=AVC msg=audit(1393411833.299:277): avc:  denied  { write } for  pid=20058 comm="clamscan" path="/run/systemd/sessions/10.ref" dev="tmpfs" ino=1159373 scontext=system_u:system_r:antivirus_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_logind_sessions_t:s0 tclass=fifo_file


type=SYSCALL msg=audit(1393411833.299:277): arch=x86_64 syscall=execve success=yes exit=0 a0=17c0970 a1=17ace70 a2=17b7130 a3=0 items=0 ppid=19817 pid=20058 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=10 comm=clamscan exe=/usr/bin/clamscan subj=system_u:system_r:antivirus_t:s0-s0:c0.c1023 key=(null)

Hash: clamscan,antivirus_t,systemd_logind_sessions_t,fifo_file,write

Additional info:
reporter:       libreport-2.1.12
hashmarkername: setroubleshoot
kernel:         3.14.0-0.rc4.git0.1.fc21.x86_64
type:           libreport

Comment 1 D. Charles Pyle 2014-02-26 19:36:32 UTC
Description of problem:
So far as I am aware, clamscan needs to be able to write to this process.  There is no step by step.  It simply pops up shortly after logon and periodically thereafter.

Additional info:
reporter:       libreport-2.1.12
hashmarkername: setroubleshoot
kernel:         3.14.0-0.rc4.git0.1.fc21.x86_64
type:           libreport

Comment 2 Daniel Walsh 2014-02-26 21:49:41 UTC
This looks like a leak.   We see lots of domains checking for write access on /run/systemd/sessions/10.ref which we label as systemd_logind_sessions_t.  Is this a leak or are lots of domains supposed to be writing to this fifo file?

Comment 3 D. Charles Pyle 2014-02-26 22:40:46 UTC
$ ls -l
total 8
-rw-r--r--. 1 root root 281 Feb 26 12:32 14
prw-------. 1 root root   0 Feb 26 12:32 14.ref
-rw-r--r--. 1 root root 249 Feb 26 12:32 c2

I do not have a 10.ref file there.

I am not sure this is a leak.  Virus scanning software needs to have permissions and the freedom to scan inside files, write to logs, and even clean and/or delete files.  I've also never gotten this selinux denial before rawhide.

Comment 4 Miroslav Grepl 2014-02-27 09:27:14 UTC
*** Bug 1070496 has been marked as a duplicate of this bug. ***

Comment 5 Daniel Walsh 2014-02-27 14:06:31 UTC
D. Charles Pyle, 

type=SYSCALL ... syscall=execve

Indicates the AVC happens when the executable is started.  This means the file descriptor is open for write by an ancestor process, and leaked into the executable.  Similar to STDIN, STDOUT and STDERR.  We are seeing this on lots of different executables not just virus scanners.

Comment 6 D. Charles Pyle 2014-02-27 14:23:43 UTC
In the case of my clamscan configuration, I have it set from rc.local to update signatures every half hour.  That has been about the rate I am seeing this clamscan error from SELinux.  What can be done about such leaks, if this indeed is a leak?

Comment 7 Miroslav Grepl 2014-02-28 13:23:09 UTC
*** Bug 1069958 has been marked as a duplicate of this bug. ***

Comment 8 Miroslav Grepl 2014-02-28 13:23:12 UTC
*** Bug 1070944 has been marked as a duplicate of this bug. ***

Comment 9 Lennart Poettering 2014-02-28 14:52:43 UTC
those are fifos that stay around between the PAM session begin and end hooks. We use them to detect abnormal session termination. They are marked O_CLOEXEC though, so that the finally executed session child won't inherit them.

The fifos exist in the file system so that we can restart logind in the middle and get a reference back to them.

Comment 10 Daniel Walsh 2014-02-28 22:25:54 UTC
Why are all these apps getting the fifo file then?

Comment 11 Adam Williamson 2014-02-28 22:47:03 UTC
I've got some more this morning - I didn't file them as I presumed they're all the same basic thing, but I have fifo denials for tumbler, sendmail.postfix, bash (three of 'em) and logrotate.

Comment 12 Hans de Goede 2014-03-02 10:14:37 UTC
Description of problem:
I do not remember doing anything special, after upgrading to the latest rawhide setroubleshoot started reporting this problem.

Additional info:
reporter:       libreport-2.1.12
hashmarkername: setroubleshoot
kernel:         3.14.0-0.rc4.git1.1.fc21.x86_64
type:           libreport

Comment 13 Christopher Meng 2014-03-11 02:13:58 UTC
SELinux is preventing /usr/bin/bash from write access on the fifo_file .

*****  Plugin leaks (86.2 confidence) suggests   *****************************

If you want to ignore bash trying to write access the  fifo_file, because you believe it should not need this access.
Then you should report this as a bug.  
You can generate a local policy module to dontaudit this access.
Do
# grep /usr/bin/bash /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

*****  Plugin catchall (14.7 confidence) suggests   **************************

If you believe that bash should be allowed write access on the  fifo_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep sa1 /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:sysstat_t:s0-s0:c0.c1023
Target Context                system_u:object_r:systemd_logind_sessions_t:s0
Target Objects                 [ fifo_file ]
Source                        sa1
Source Path                   /usr/bin/bash
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           bash-4.3.0-1.fc21.i686
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-29.fc21.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux fab.cicku.me 3.14.0-0.rc5.git2.2.fc21.i686
                              #1 SMP Fri Mar 7 02:02:51 UTC 2014 i686 i686
Alert Count                   1
First Seen                    2014-03-11 10:10:01 CST
Last Seen                     2014-03-11 10:10:01 CST
Local ID                      e8451f45-3bd1-4b82-8ce1-7fa7b612079b

Raw Audit Messages
type=AVC msg=audit(1394503801.353:395): avc:  denied  { write } for  pid=3274 comm="sa1" path="/run/systemd/sessions/4.ref" dev="tmpfs" ino=127159 scontext=system_u:system_r:sysstat_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_logind_sessions_t:s0 tclass=fifo_file


type=SYSCALL msg=audit(1394503801.353:395): arch=i386 syscall=execve success=yes exit=0 a0=905bf50 a1=905bf80 a2=905b4e8 a3=905bf80 items=0 ppid=3272 pid=3274 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4 comm=sa1 exe=/usr/bin/bash subj=system_u:system_r:sysstat_t:s0-s0:c0.c1023 key=(null)

Hash: sa1,sysstat_t,systemd_logind_sessions_t,fifo_file,write

Comment 14 D. Charles Pyle 2014-03-12 03:02:18 UTC
Description of problem:
clamscan is set to update the antivirus signatures every half hour, as well as log the result.  I have to set SELinux at permissive or the system does not get updated properly and clamscan generated logs don't get written or rotated.  But, I still see this error every half hour.  Clamscan as well as related files need write ability and the ability to write and rotate their log entries.

SELinux is preventing /usr/bin/clamscan from 'write' accesses on the fifo_file .

*****  Plugin leaks (86.2 confidence) suggests   *****************************

If you want to ignore clamscan trying to write access the  fifo_file, because you believe it should not need this access.
Then you should report this as a bug.  
You can generate a local policy module to dontaudit this access.
Do
# grep /usr/bin/clamscan /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

*****  Plugin catchall (14.7 confidence) suggests   **************************

If you believe that clamscan should be allowed write access on the  fifo_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep clamscan /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:antivirus_t:s0-s0:c0.c1023
Target Context                system_u:object_r:systemd_logind_sessions_t:s0
Target Objects                 [ fifo_file ]
Source                        clamscan
Source Path                   /usr/bin/clamscan
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           clamav-0.98.1-1.fc21.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-31.fc21.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 3.14.0-0.rc6.git0.1.fc21.x86_64 #1
                              SMP Mon Mar 10 13:56:29 UTC 2014 x86_64 x86_64
Alert Count                   13
First Seen                    2014-03-11 00:52:13 MDT
Last Seen                     2014-03-11 20:54:50 MDT
Local ID                      8838fd38-6002-48ba-966d-83fcd4530493

Raw Audit Messages
type=AVC msg=audit(1394592890.925:169): avc:  denied  { write } for  pid=5468 comm="clamscan" path="/run/systemd/sessions/2.ref" dev="tmpfs" ino=44529 scontext=system_u:system_r:antivirus_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_logind_sessions_t:s0 tclass=fifo_file


type=SYSCALL msg=audit(1394592890.925:169): arch=x86_64 syscall=execve success=yes exit=0 a0=17ad860 a1=1796f80 a2=17a2cd0 a3=1794b80 items=0 ppid=3574 pid=5468 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm=clamscan exe=/usr/bin/clamscan subj=system_u:system_r:antivirus_t:s0-s0:c0.c1023 key=(null)

Hash: clamscan,antivirus_t,systemd_logind_sessions_t,fifo_file,write

Additional info:
reporter:       libreport-2.2.0
hashmarkername: setroubleshoot
kernel:         3.14.0-0.rc6.git0.1.fc21.x86_64
type:           libreport

Comment 15 ILMostro 2014-03-12 10:41:25 UTC
I just received this error as well as noted in Bug 1070944 after installing group "Development and Creative Workstation". 

Journal shows cron jobs starting about 4mins after installation resulting in sealert; I was away from machine to confirm what happened during that time.

Comment 16 ILMostro 2014-03-12 10:54:16 UTC
Seems I jumped the gun there; the alerts started during the installation of the packages in the above-mentioned group. 

Mar 12 04:23:18 fedraw64 yum[17684]: Installed: eclipse-packagekit-0.1.0-6.fc20.noarch     [1811/1885]
Mar 12 04:23:19 fedraw64 yum[17684]: Installed: evolution-data-server-devel-3.11.91-1.fc21.x86_64
Mar 12 04:23:20 fedraw64 groupadd[18648]: group added to /etc/group: name=squid, GID=23
Mar 12 04:23:20 fedraw64 groupadd[18648]: group added to /etc/gshadow: name=squid
Mar 12 04:23:20 fedraw64 groupadd[18648]: new group: name=squid, GID=23
Mar 12 04:23:20 fedraw64 useradd[18653]: new user: name=squid, UID=23, GID=23, home=/var/spool/squid, 
shell=/sbin/nologin
Mar 12 04:23:24 fedraw64 systemd[1]: Reloading.
Mar 12 04:23:24 fedraw64 systemd[1]: Configuration file /usr/lib/systemd/system/auditd.service is mark
ed world-inaccessible. This has no effect as configuration data is accessible via APIs without restric
tions. Proceeding anyway.
Mar 12 04:23:24 fedraw64 groupadd[18671]: group added to /etc/group: name=wbpriv, GID=88
Mar 12 04:23:24 fedraw64 groupadd[18671]: group added to /etc/gshadow: name=wbpriv
Mar 12 04:23:24 fedraw64 usermod[18675]: add 'squid' to group 'wbpriv'
Mar 12 04:23:24 fedraw64 usermod[18675]: add 'squid' to shadow group 'wbpriv'
Mar 12 04:23:24 fedraw64 yum[17684]: Installed: 7:squid-3.4.3-1.fc21.x86_64

I guess cron.daily jobs started running as new users/groups were being added? Meanwhile, the following shows that dbus-daemon is starting SETroubleshootD for the first time?

Mar 12 04:24:01 fedraw64 yum[17684]: Installed: xorg-x11-docs-1.6-7.fc20.noarch
Mar 12 04:24:01 fedraw64 anacron[16998]: Job `cron.daily' started
Mar 12 04:24:01 fedraw64 run-parts[18699]: (/etc/cron.daily) starting 00webalizer
Mar 12 04:24:01 fedraw64 run-parts[18703]: (/etc/cron.daily) finished 00webalizer
Mar 12 04:24:01 fedraw64 run-parts[18705]: (/etc/cron.daily) starting certwatch
Mar 12 04:24:01 fedraw64 dbus-daemon[547]: dbus[547]: [system] Activating service name='org.fedoraproj
ect.Setroubleshootd' (using servicehelper)
Mar 12 04:24:01 fedraw64 dbus[547]: [system] Activating service name='org.fedoraproject.Setroubleshoot
d' (using servicehelper)
Mar 12 04:24:01 fedraw64 run-parts[18711]: (/etc/cron.daily) finished certwatch
Mar 12 04:24:01 fedraw64 run-parts[18713]: (/etc/cron.daily) starting logrotate
Mar 12 04:24:03 fedraw64 run-parts[18718]: (/etc/cron.daily) finished logrotate
Mar 12 04:24:03 fedraw64 run-parts[18720]: (/etc/cron.daily) starting man-db.cron
Mar 12 04:24:03 fedraw64 yum[17684]: Installed: ltrace-0.7.91-7.fc21.x86_64
Mar 12 04:24:04 fedraw64 yum[17684]: Installed: lockdev-devel-1.0.4-0.15.20111007git.fc21.x86_64
Mar 12 04:24:04 fedraw64 yum[17684]: Installed: bzip2-devel-1.0.6-11.fc21.x86_64
Mar 12 04:24:05 fedraw64 yum[17684]: Installed: indent-2.2.11-12.fc20.x86_64
Mar 12 04:24:06 fedraw64 yum[17684]: Installed: byacc-1.9.20130304-2.fc20.x86_64
Mar 12 04:24:08 fedraw64 dbus-daemon[547]: dbus[547]: [system] Successfully activated service 'org.fed
oraproject.Setroubleshootd'
Mar 12 04:24:08 fedraw64 dbus[547]: [system] Successfully activated service 'org.fedoraproject.Setroub
leshootd'
Mar 12 04:24:08 fedraw64 setroubleshoot[18709]: RunFaultServer(10)
Mar 12 04:24:08 fedraw64 setroubleshoot[18709]: created new database: name=setroubleshoot, friendly_na
me=Audit Listener, filepath=/var/lib/setroubleshoot/setroubleshoot_database.xml

Comment 17 ILMostro 2014-03-12 11:04:14 UTC
Mar 12 04:24:08 fedraw64 setroubleshoot[18709]: AuditRecordReceiver.add_record_to_cache(): node=fedraw
64 type=SYSCALL msg=audit(1394616243.246:536): arch=c000003e syscall=59 success=yes exit=0 a0=2507060 
a1=2508950 a2=24fff60 a3=3f0b27f items=0 ppid=18696 pid=18721 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0
 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="man-db.cron" exe="/usr/bin/bash" subj=system_u:system_r:
mandb_t:s0-s0:c0.c1023 key=(null)
Mar 12 04:24:08 fedraw64 setroubleshoot[18709]: AuditRecordReceiver.add_record_to_cache(): node=fedraw
64 type=EOE msg=audit(1394616243.246:536):
Mar 12 04:24:09 fedraw64 setroubleshoot[18709]: Plugin Exception restorecon_source
Mar 12 04:24:09 fedraw64 setroubleshoot[18709]: lookup_signature: found 0 matches with scores
Mar 12 04:24:09 fedraw64 setroubleshoot[18709]: not in database yet
Mar 12 04:24:09 fedraw64 setroubleshoot[18709]: writing database (/var/lib/setroubleshoot/setroublesho
ot_database.xml) modified_count=1
Mar 12 04:24:09 fedraw64 setroubleshoot[18709]: sending alert to all clients
Mar 12 04:24:09 fedraw64 setroubleshoot[18709]: SELinux is preventing /usr/bin/bash from write access 
on the fifo_file . For complete SELinux messages. run sealert -l ba006749-9048-4d62-b552-de346374bb4e
Mar 12 04:24:09 fedraw64 setroubleshoot[18709]: load_plugins() names=['disable_ipv6', 'allow_ftpd_use_
cifs', 'httpd_write_content', 'device', 'catchall', 'restorecon', 'xen_image', 'dac_override', 'httpd_
can_sendmail', 'allow_anon_write', 'allow_execheap', 'leaks', 'wine', 'selinuxpolicy', 'mozplugger_rem
ove', 'rsync_data', 'allow_ftpd_use_nfs', 'public_content', 'allow_execmod', 'vbetool', 'catchall_labe
ls', 'qemu_file_image', 'kernel_modules', 'sshd_root', 'mmap_zero', 'restorecon_source', 'openvpn', 's
amba_share', 'catchall_boolean', 'chrome', 'sandbox_connect', 'bind_ports', 'mozplugger', 'allow_execs
tack', 'sys_module', 'automount_exec_config', 'cvs_data', 'swapfile', 'filesystem_associate', 'sys_res
ource', 'connect_ports', 'mounton', 'file', 'setenforce', 'qemu_blk_image', 'associate']
Mar 12 04:24:09 fedraw64 setroubleshoot[18709]: load_plugins() plugins.disable_ipv6 previously importe
d
Mar 12 04:24:09 fedraw64 setroubleshoot[18709]: load_plugins() plugins.allow_ftpd_use_cifs previously 
imported
Mar 12 04:24:09 fedraw64 setroubleshoot[18709]: load_plugins() plugins.httpd_write_content previously 
imported
Mar 12 04:24:09 fedraw64 setroubleshoot[18709]: load_plugins() plugins.device previously imported
Mar 12 04:24:09 fedraw64 setroubleshoot[18709]: load_plugins() plugins.catchall previously imported
Mar 12 04:24:09 fedraw64 setroubleshoot[18709]: load_plugins() plugins.restorecon previously imported
Mar 12 04:24:09 fedraw64 setroubleshoot[18709]: load_plugins() plugins.xen_image previously imported
Mar 12 04:24:09 fedraw64 setroubleshoot[18709]: load_plugins() plugins.dac_override previously importe
d
Mar 12 04:24:09 fedraw64 setroubleshoot[18709]: load_plugins() plugins.httpd_can_sendmail previously i
mported

Comment 18 Michal Nowak 2014-03-13 09:19:36 UTC
Description of problem:
yum upgrade

Additional info:
reporter:       libreport-2.2.0
hashmarkername: setroubleshoot
kernel:         3.14.0-0.rc5.git1.1.fc21.x86_64
type:           libreport

Comment 19 Hans de Goede 2014-03-15 13:18:06 UTC
Description of problem:
I've been seeing this selinux denial for a while now, since upgrading to rawhide. IIRC I've already filed a bug for this a while back, but since it is still present I'm letting setroubleshoot file another one.

Additional info:
reporter:       libreport-2.2.0
hashmarkername: setroubleshoot
kernel:         3.14.0-0.rc6.git2.1.fc21.x86_64
type:           libreport

Comment 20 Moez Roy 2014-03-19 14:43:57 UTC
Description of problem:
its rawhide

Additional info:
reporter:       libreport-2.2.0
hashmarkername: setroubleshoot
kernel:         3.14.0-0.rc6.git4.1.fc21.x86_64
type:           libreport

Comment 21 Moez Roy 2014-03-20 02:43:21 UTC
Description of problem:
SELinux is preventing /usr/lib64/tumbler-1/tumblerd from 'write' accesses on the fifo_file .

*****  Plugin leaks (86.2 confidence) suggests   *****************************

If you want to ignore tumblerd trying to write access the  fifo_file, because you believe it should not need this access.
Then you should report this as a bug.  
You can generate a local policy module to dontaudit this access.
Do
# grep /usr/lib64/tumbler-1/tumblerd /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

*****  Plugin catchall (14.7 confidence) suggests   **************************

If you believe that tumblerd should be allowed write access on the  fifo_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep tumblerd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023
Target Context                system_u:object_r:systemd_logind_sessions_t:s0
Target Objects                 [ fifo_file ]
Source                        tumblerd
Source Path                   /usr/lib64/tumbler-1/tumblerd
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           tumbler-0.1.30-1.fc21.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-38.fc21.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.14.0-0.rc7.git0.1.fc21.x86_64 #1
                              SMP Mon Mar 17 13:48:26 UTC 2014 x86_64 x86_64
Alert Count                   4
First Seen                    2014-03-19 09:47:31 PDT
Last Seen                     2014-03-19 19:41:23 PDT
Local ID                      b95da7d7-4ab3-4666-b0ba-ab1bab012cf1

Raw Audit Messages
type=AVC msg=audit(1395283283.356:391): avc:  denied  { write } for  pid=1829 comm="tumblerd" path="/run/systemd/sessions/1.ref" dev="tmpfs" ino=21599 scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_logind_sessions_t:s0 tclass=fifo_file


type=SYSCALL msg=audit(1395283283.356:391): arch=x86_64 syscall=execve success=yes exit=0 a0=7f36a7cb40a0 a1=7f36a7cb42e0 a2=7f36a7cb43a0 a3=7f36a7220b10 items=0 ppid=1828 pid=1829 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=1 comm=tumblerd exe=/usr/lib64/tumbler-1/tumblerd subj=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 key=(null)

Hash: tumblerd,thumb_t,systemd_logind_sessions_t,fifo_file,write

Additional info:
reporter:       libreport-2.2.0
hashmarkername: setroubleshoot
kernel:         3.14.0-0.rc7.git0.1.fc21.x86_64
type:           libreport

Comment 22 Ed Greshko 2014-03-30 08:11:47 UTC
Description of problem:
Problem occurs with a konsole window open and doing nothing.

Additional info:
reporter:       libreport-2.2.0
hashmarkername: setroubleshoot
kernel:         3.14.0-0.rc8.git0.1.fc21.x86_64
type:           libreport

Comment 23 Ed Greshko 2014-03-30 08:32:36 UTC
The selinux troubleshooting/reporting tool indicates this is a duplicate of the above.


SELinux is preventing /usr/bin/bash from write access on the fifo_file .

*****  Plugin leaks (86.2 confidence) suggests   *****************************

If you want to ignore bash trying to write access the  fifo_file, because you believe it should not need this access.
Then you should report this as a bug.  
You can generate a local policy module to dontaudit this access.
Do
# grep /usr/bin/bash /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

*****  Plugin catchall (14.7 confidence) suggests   **************************

If you believe that bash should be allowed write access on the  fifo_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep sa1 /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:sysstat_t:s0-s0:c0.c1023
Target Context                system_u:object_r:systemd_logind_sessions_t:s0
Target Objects                 [ fifo_file ]
Source                        sa1
Source Path                   /usr/bin/bash
Port                          <Unknown>
Host                          f20kde
Source RPM Packages           bash-4.3.0-1.fc21.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-39.fc21.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     f20kde
Platform                      Linux f20kde 3.14.0-0.rc8.git0.1.fc21.x86_64 #1
                              SMP Tue Mar 25 14:01:40 UTC 2014 x86_64 x86_64
Alert Count                   449
First Seen                    2014-03-20 06:30:02 CST
Last Seen                     2014-03-30 16:30:01 CST
Local ID                      52d1255a-730c-4445-b06a-488575050dde

Raw Audit Messages
type=AVC msg=audit(1396168201.524:2347): avc:  denied  { write } for  pid=21187 comm="sa1" path="/run/systemd/sessions/160.ref" dev="tmpfs" ino=180436 scontext=system_u:system_r:sysstat_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_logind_sessions_t:s0 tclass=fifo_file


type=SYSCALL msg=audit(1396168201.524:2347): arch=x86_64 syscall=execve success=yes exit=0 a0=18a5bf0 a1=18a5e10 a2=18a4d00 a3=8 items=0 ppid=21177 pid=21187 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=160 comm=sa1 exe=/usr/bin/bash subj=system_u:system_r:sysstat_t:s0-s0:c0.c1023 key=(null)

Hash: sa1,sysstat_t,systemd_logind_sessions_t,fifo_file,write

Comment 24 Ed Greshko 2014-04-06 05:07:02 UTC
FWIW, I've stopped getting these AVCs after installing the non-Debug kernel 3.15.0-0.rc0.git9.1.fc21.x86_64

Comment 25 D. Charles Pyle 2014-04-06 05:52:17 UTC
(In reply to Ed Greshko from comment #24)
> FWIW, I've stopped getting these AVCs after installing the non-Debug kernel
> 3.15.0-0.rc0.git9.1.fc21.x86_64

That is interesting.  I cannot even get to desktop using that kernel.  LightDM locks up just before the Desktop should appear whenever I run that kernel.  I wonder why that AVC would stop with the new kernel.

Comment 26 Ed Greshko 2014-04-06 06:03:17 UTC
Just be a bit more specific....  I was getting the AVC with the 3.15.0-0.rc0.git9.1.fc21.x86_64 kernel from the rawhide repository.  I wanted to do some comparison testing of between that and the non-debug version in the fedora-rawhide-kernel-nodebug.repo.  It was after installing the kernel from that repo that the AVCs ceased.

I'm running only KDE/kdm on the test system.

Comment 27 Ed Greshko 2014-04-06 20:56:47 UTC
Well, my observation proved wrong after all.  It took quite a long time, over 12 hours, but the AVC did finally pop up.  Previously, the AVC would pop up within minutes of opening a konsole window.

Comment 28 Daniel Walsh 2014-04-09 12:40:17 UTC
D. Charles Pyle, this AVC has nothing to do with the lockup.  It is just a leak.

Comment 29 D. Charles Pyle 2014-04-09 17:16:00 UTC
(In reply to Daniel Walsh from comment #28)
> D. Charles Pyle, this AVC has nothing to do with the lockup.  It is just a
> leak.

I don't recall writing that the AVC was the cause of the lockup, but that I cannot even get to desktop with the kernel that the user was using.  I then stated that I wondered why that AVC would stop with that kernel (which later turned out to be an incorrect observation).

Comment 30 Adam Williamson 2014-04-10 18:26:38 UTC
9.2 hangs during boot here too, but we should file that separately.

Comment 31 D. Charles Pyle 2014-04-11 00:47:20 UTC
(In reply to Adam Williamson from comment #30)
> 9.2 hangs during boot here too, but we should file that separately.

I wasn't filing that here, or anywhere.  I just expressed my surprise to the poster that the poster was even able to boot this kernel and also have this AVC disappear.

Comment 32 Jared Smith 2014-04-11 13:47:45 UTC
Description of problem:
Got this SELinux alert on a new installation of rawhide.

Additional info:
reporter:       libreport-2.2.1
hashmarkername: setroubleshoot
kernel:         3.15.0-0.rc0.git9.1.fc21.x86_64
type:           libreport

Comment 33 Jared Smith 2014-04-15 14:22:50 UTC
Description of problem:
Booted my system and ran Firefox and Evolution and Pidgin and LibreOffice.  I don't know which program actually triggered the SE alert.

Version-Release number of selected component:
selinux-policy-3.13.1-45.fc21.noarch

Additional info:
reporter:       libreport-2.2.1
hashmarkername: setroubleshoot
kernel:         3.15.0-0.rc0.git12.2.fc21.x86_64
type:           libreport

Comment 34 Daniel Walsh 2014-04-24 01:31:30 UTC

*** This bug has been marked as a duplicate of bug 864143 ***


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