Bug 818528

Summary: SELinux is preventing /usr/bin/python2.7 from 'write' accesses on the file network.state.
Product: [Fedora] Fedora Reporter: nordaux
Component: bluemanAssignee: Juan Manuel Rodriguez <nushio>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: christoph.wickert, dominick.grift, dwalsh, mgrepl, misek, netwizurd, nordaux, nushio
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:2c0e332e26ee419d19664a7958b24da6e991155ead89f8d61929f0a0392d61ef
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-01 18:47:00 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 nordaux 2012-05-03 09:23:47 UTC
libreport version: 2.0.10
executable:     /usr/bin/python2.7
hashmarkername: setroubleshoot
time:           Thu 03 May 2012 12:08:09 PM EEST

description:
:SELinux is preventing /usr/bin/python2.7 from 'write' accesses on the file network.state.
:
:*****  Plugin catchall_labels (83.8 confidence) suggests  ********************
:
:If you want to allow python2.7 to have write access on the network.state file
:Then you need to change the label on network.state
:Do
:# semanage fcontext -a -t FILE_TYPE 'network.state'
:where FILE_TYPE is one of the following: blueman_t, afs_cache_t. 
:Then execute: 
:restorecon -v 'network.state'
:
:
:*****  Plugin catchall (17.1 confidence) suggests  ***************************
:
:If you believe that python2.7 should be allowed write access on the network.state 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 blueman-mechani /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:
:Additional Information:
:Source Context                system_u:system_r:blueman_t:s0-s0:c0.c1023
:Target Context                system_u:object_r:var_lib_t:s0
:Target Objects                network.state [ file ]
:Source                        blueman-mechani
:Source Path                   /usr/bin/python2.7
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           python-2.7.3-6.fc17.x86_64
:Target RPM Packages           
:Policy RPM                    selinux-policy-3.10.0-118.fc17.noarch
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Enforcing
:Host Name                     (removed)
:Platform                      Linux (removed) 3.3.4-1.nrdx.fc17.x86_64 #1 SMP Thu
:                              May 3 10:42:44 EEST 2012 x86_64 x86_64
:Alert Count                   1
:First Seen                    Thu 03 May 2012 12:06:14 PM EEST
:Last Seen                     Thu 03 May 2012 12:06:14 PM EEST
:Local ID                      9449fdf1-76a5-49c8-aaea-c2f298ec21e2
:
:Raw Audit Messages
:type=AVC msg=audit(1336035974.118:84): avc:  denied  { write } for  pid=1677 comm="blueman-mechani" name="network.state" dev="dm-1" ino=1049894 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file
:
:
:type=SYSCALL msg=audit(1336035974.118:84): arch=x86_64 syscall=open success=yes exit=ENOEXEC a0=1e9a020 a1=241 a2=1b6 a3=238 items=0 ppid=1 pid=1677 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=blueman-mechani exe=/usr/bin/python2.7 subj=system_u:system_r:blueman_t:s0-s0:c0.c1023 key=(null)
:
:Hash: blueman-mechani,blueman_t,var_lib_t,file,write
:
:audit2allowunable to open /sys/fs/selinux/policy:  Permission denied
:
:
:audit2allow -Runable to open /sys/fs/selinux/policy:  Permission denied
:
:

Comment 1 Daniel Walsh 2012-05-03 14:14:17 UTC
Do you know what directory is blueman trying to write 
network.state in?

Comment 2 Daniel Walsh 2012-05-03 14:15:42 UTC
Does blueman need to write content into the /var/lib directory?

Comment 3 MotherDawg 2012-05-03 23:46:44 UTC
Hey Dan, 

I've been reading your Selinux blog... man I got things to learn !

I'm getting roughly the same thing as Nordaux.
But it is not coming out in Abrt, I'm only getting Selinux Alerts.
I could not automatically post this.
So I did not know if I needed to open a new bug.
Since it's on the same file and seams to be from "blueman_t" too... thought I would post it here.
My install is Xfce and LXDE only... no Gnome3 "Crazies".
http://digitizor.com/2011/08/04/linus-torvalds-ditches-gnome-for-xfce/
I do run GDM as LXDM was starting but not showing a login box.

I have 4 the alerts : Read, Open, getattr and Write. 
Only the getattribute display full path, the 3 others only specify the file name. 
-rw-r--r--. 1 root root 136 May  3 15:44 /var/lib/blueman/network.state
*******************************************************************************
SELinux is preventing blueman-mechani from getattr access on the file /var/lib/blueman/network.state.

*****  Plugin catchall_labels (83.8 confidence) suggests  ********************

If you want to allow blueman-mechani to have getattr access on the network.state file
Then you need to change the label on /var/lib/blueman/network.state
Do
# semanage fcontext -a -t FILE_TYPE '/var/lib/blueman/network.state'
where FILE_TYPE is one of the following: net_conf_t, userdomain, rpm_script_tmp_t, blueman_t, ld_so_cache_t, abrt_var_cache_t, sosreport_tmp_t, avahi_exec_t, rpm_tmp_t, abrt_var_run_t, cert_t, blueman_exec_t, etc_t, sysctl_crypto_t, system_dbusd_var_lib_t, sssd_public_t, locale_t, bin_t, etc_t, proc_t, passwd_file_t, krb5_conf_t, usr_t, abrt_t, lib_t, ld_so_t, cpu_online_t, abrt_helper_exec_t, passwd_file_t, samba_var_t, textrel_shlib_t, dbusd_etc_t, krb5_host_rcache_t. 
Then execute: 
restorecon -v '/var/lib/blueman/network.state'


*****  Plugin catchall (17.1 confidence) suggests  ***************************

If you believe that blueman-mechani should be allowed getattr access on the network.state 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 blueman-mechani /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:blueman_t:s0-s0:c0.c1023
Target Context                system_u:object_r:var_lib_t:s0
Target Objects                /var/lib/blueman/network.state [ file ]
Source                        blueman-mechani
Source Path                   blueman-mechani
Port                          <Unknown>
Host                          Think.Dawg
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-118.fc17.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     Think.Dawg
Platform                      Linux Think.Dawg 3.3.4-1.fc17.i686 #1 SMP Fri Apr
                              27 19:40:35 UTC 2012 i686 i686
Alert Count                   1
First Seen                    Thu 03 May 2012 03:44:23 PM EDT
Last Seen                     Thu 03 May 2012 03:44:23 PM EDT
Local ID                      c0409e0f-99cb-4051-a515-8cb6d15bf5ad

Raw Audit Messages
type=AVC msg=audit(1336074263.451:235): avc:  denied  { getattr } for  pid=1334 comm="blueman-mechani" path="/var/lib/blueman/network.state" dev="dm-1" ino=394995 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file


Hash: blueman-mechani,blueman_t,var_lib_t,file,getattr

audit2allowunable to open /sys/fs/selinux/policy:  Permission denied

audit2allow -Runable to open /sys/fs/selinux/policy:  Permission denied
*******************************************************************************

I hope this pertains to the same issue... if not... wath to do ?

Comment 4 Miroslav Grepl 2012-05-04 05:35:50 UTC
/var/lib/blueman is not owned by blueman package.

Is this directory created by the blueman-mechanism?

Also could you add this directory to the spec file, then we can add a label for it and this directory get the right labeling on the install.

Comment 5 Christoph Wickert 2012-05-06 09:09:33 UTC
(In reply to comment #2)
> Does blueman need to write content into the /var/lib directory?

Yes, it keeps a file called /var/lib/blueman/network.state

(In reply to comment #4)
> /var/lib/blueman is not owned by blueman package.

My bad.

> Is this directory created by the blueman-mechanism?

Yes.
 
> Also could you add this directory to the spec file, then we can add a label for
> it and this directory get the right labeling on the install.

Sure, I will push an update. Note: I am not the owner of the package, I just jumped in because this package has so many bugs.

Comment 6 Fedora Update System 2012-05-06 15:16:22 UTC
blueman-1.23-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/blueman-1.23-2.fc17

Comment 7 Fedora Update System 2012-05-06 15:16:25 UTC
blueman-1.23-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/blueman-1.23-2.fc16

Comment 8 MotherDawg 2012-05-08 02:14:33 UTC
Sweeeeeeeeeeeeeeeeeeeeet !

Comment 9 Fedora Update System 2012-05-26 07:55:41 UTC
blueman-1.23-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 MotherDawg 2012-05-26 23:32:22 UTC
Much obliged.

Comment 11 Fedora Update System 2012-06-02 03:54:00 UTC
blueman-1.23-2.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Fedora End Of Life 2013-07-04 07:03:23 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. 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 '17'.

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 17'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 17 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, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

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.

Comment 13 Fedora End Of Life 2013-08-01 18:47:05 UTC
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.