Bug 858137

Summary: SELinux is preventing /usr/bin/bash from read access on the lnk_file /var/lock.
Product: [Fedora] Fedora Reporter: Mamoru TASAKA <mtasaka>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: dominick.grift, dwalsh, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-10-17 08:03:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
restorecon result none

Description Mamoru TASAKA 2012-09-18 06:07:21 UTC
Description of problem:
From env LANG=C LC_ALL=C sealert -l 647a47d2-7e4a-4cab-a8ce-724db303b1ce

SELinux is preventing /usr/bin/bash from read access on the lnk_file /var/lock.

*****  Plugin restorecon (94.8 confidence) suggests  *************************

If you want to fix the label. 
/var/lock default label should be var_lock_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /var/lock

*****  Plugin catchall_labels (5.21 confidence) suggests  ********************

If you want to allow bash to have read access on the lock lnk_file
Then you need to change the label on /var/lock
Do
# semanage fcontext -a -t FILE_TYPE '/var/lock'
where FILE_TYPE is one of the following: etc_runtime_t, udev_var_run_t, textrel_shlib_t, etc_t, cert_t, home_root_t, rpm_script_tmp_t, var_run_t, var_run_t, device_t, devlog_t, cgroup_t, locale_t, var_lock_t, dhcpc_t, etc_t, ypbind_t, bin_t, cert_t, proc_t, init_t, sysfs_t, nscd_t, ntpd_t, usr_t, dhcp_etc_t, var_run_t, device_t, net_conf_t, device_t, tmp_t, abrt_t, bin_t, ld_so_t, proc_t, lib_t, root_t, tmp_t, chronyd_t, proc_net_t, proc_xen_t, var_run_t, var_run_t, var_run_t. 
Then execute: 
restorecon -v '/var/lock'


*****  Plugin catchall (1.44 confidence) suggests  ***************************

If you believe that bash should be allowed read access on the lock lnk_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 dhclient-script /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:dhcpc_t:s0
Target Context                system_u:object_r:var_t:s0
Target Objects                /var/lock [ lnk_file ]
Source                        dhclient-script
Source Path                   /usr/bin/bash
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           bash-4.2.37-2.fc17.i686
Target RPM Packages           filesystem-3-2.fc17.i686
Policy RPM                    selinux-policy-3.10.0-149.fc17.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 3.5.3-1.fc17.i686 #1
                              SMP Wed Aug 29 19:25:38 UTC 2012 i686 i686
Alert Count                   1
First Seen                    2012-09-18 14:16:20 JST
Last Seen                     2012-09-18 14:16:20 JST
Local ID                      647a47d2-7e4a-4cab-a8ce-724db303b1ce

Raw Audit Messages
type=AVC msg=audit(1347945380.760:38): avc:  denied  { read } for  pid=896 comm="dhclient-script" name="lock" dev="dm-1" ino=14123 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=lnk_file


type=SYSCALL msg=audit(1347945380.760:38): arch=i386 syscall=stat64 success=no exit=EACCES a0=8db9208 a1=bfdeef40 a2=b7741ff4 a3=3 items=0 ppid=858 pid=896 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=dhclient-script exe=/usr/bin/bash subj=system_u:system_r:dhcpc_t:s0 key=(null)

Hash: dhclient-script,dhcpc_t,var_t,lnk_file,read

audit2allow

#============= dhcpc_t ==============
allow dhcpc_t var_t:lnk_file read;

audit2allow -R

#============= dhcpc_t ==============
allow dhcpc_t var_t:lnk_file read;

Version-Release number of selected component (if applicable):
kernel-3.5.3-1.fc17.i686
selinux-policy-3.10.0-149.fc17.noarch
dhclient-4.2.4-13.P2.fc17.i686
initscripts-9.37.1-1.fc17.i686
systemd-44-17.fc17.i686

How reproducible:
Seems firstly occrred

Steps to Reproduce:
1. boot (perhaps)
2. check /var/log/messages /var/log/audit/audit.log
3.
  
Actual results:
See above

Expected results:
No AVC denial

Additional info:
For my machine's settings, see "Additional info" of https://bugzilla.redhat.com/show_bug.cgi?id=858125#c0

Comment 1 Miroslav Grepl 2012-09-18 08:56:21 UTC
*** Bug 858125 has been marked as a duplicate of this bug. ***

Comment 2 Daniel Walsh 2012-09-18 12:34:16 UTC
Does restorecon -v -R /var
change the label on /var/lock?

Comment 3 Mamoru TASAKA 2012-09-18 12:52:53 UTC
(In reply to comment #2)
> Does restorecon -v -R /var
> change the label on /var/lock?

Will try tomorrow.

Comment 4 Mamoru TASAKA 2012-09-19 00:22:30 UTC
Created attachment 614161 [details]
restorecon result

(In reply to comment #2)
> Does restorecon -v -R /var
> change the label on /var/lock?

Looks like so (log attached). Maybe with usrmove /var/lock symlink is created during filesystem %postinstall, however selinux context was not correctly set?

Comment 5 Miroslav Grepl 2012-10-17 08:03:55 UTC
There was some issues with usrmove where restorecon was needed as in this case.