Bug 858137 - SELinux is preventing /usr/bin/bash from read access on the lnk_file /var/lock.
Summary: SELinux is preventing /usr/bin/bash from read access on the lnk_file /var/lock.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 858125 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-18 06:07 UTC by Mamoru TASAKA
Modified: 2012-10-17 08:03 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-10-17 08:03:55 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
restorecon result (7.17 KB, text/plain)
2012-09-19 00:22 UTC, Mamoru TASAKA
no flags Details

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.


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