Bug 787836

Summary: SELinux is preventing /sbin/iscsid from 'link' accesses on the None lock.
Product: [Fedora] Fedora Reporter: Ron Gonzalez <Lcstyle>
Component: iscsi-initiator-utilsAssignee: Mike Christie <mchristi>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: agrover, dominick.grift, dwalsh, hdegoede, mchristi, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:9fe14f50c47194a99398d4a52af67b72a61d577c03b024c76c5bcfb891b3c1b2
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-13 17:48:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Fix selinux iscsid lock errors none

Description Ron Gonzalez 2012-02-06 21:52:12 UTC
libreport version: 2.0.8
executable:     /usr/bin/python
hashmarkername: setroubleshoot
kernel:         3.2.3-2.fc16.x86_64
reason:         SELinux is preventing /sbin/iscsid from 'link' accesses on the None lock.
time:           Mon 06 Feb 2012 04:51:05 PM EST

description:
:SELinux is preventing /sbin/iscsid from 'link' accesses on the None lock.
:
:*****  Plugin catchall (100. confidence) suggests  ***************************
:
:If you believe that iscsid should be allowed link access on the lock <Unknown> 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 iscsid /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:
:Additional Information:
:Source Context                system_u:system_r:iscsid_t:s0
:Target Context                system_u:object_r:var_lock_t:s0
:Target Objects                lock [ None ]
:Source                        iscsid
:Source Path                   /sbin/iscsid
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           iscsi-initiator-utils-6.2.0.872-14.fc16.x86_64
:Target RPM Packages           
:Policy RPM                    selinux-policy-3.10.0-75.fc16.noarch
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Enforcing
:Host Name                     (removed)
:Platform                      Linux (removed) 3.2.3-2.fc16.x86_64 #1 SMP Fri
:                              Feb 3 20:08:08 UTC 2012 x86_64 x86_64
:Alert Count                   1
:First Seen                    Mon 06 Feb 2012 04:45:25 PM EST
:Last Seen                     Mon 06 Feb 2012 04:45:25 PM EST
:Local ID                      28b8b93c-9656-4c73-a62a-d7dc014dc5d8
:
:Raw Audit Messages
:type=AVC msg=audit(1328564725.512:84): avc:  denied  { link } for  pid=2462 comm="iscsid" name="lock" dev=tmpfs ino=27094 scontext=system_u:system_r:iscsid_t:s0 tcontext=system_u:object_r:var_lock_t:s0 tclass=filenode=(removed) type=SYSCALL msg=audit(1328564725.512:84): arch=c000003e syscall=86 success=no exit=-13 a0=44ba91 a1=44baa6 a2=d a3=1000 items=0 ppid=1 pid=2462 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iscsid" exe="/sbin/iscsid" subj=system_u:system_r:iscsid_t:s0 key=(null)
:
:
:Hash: iscsid,iscsid_t,var_lock_t,None,link
:
:audit2allow
:
:
:audit2allow -R
:
:

Comment 1 Ron Gonzalez 2012-02-06 21:53:13 UTC
This was fixed already?

Not sure why I am getting it again.

https://bugzilla.redhat.com/show_bug.cgi?id=744959

Comment 2 Ron Gonzalez 2012-02-06 21:54:54 UTC
#yum list installed selinux-policy
Installed Packages
selinux-policy.noarch3.10.0-75.fc16

Comment 3 Miroslav Grepl 2012-03-15 16:19:39 UTC
When are you getting it? What are you doing?

Comment 4 Ron Gonzalez 2012-03-15 17:17:27 UTC
There are two I am getting occasionally, so I am not monitoring the system for when the error occurs.  It appears to be problems with the policy on the lock file in tmpfs.

I am not sure I can reproduce it, because I do not know when it occurs.  I am assuming that this is happening when the process is starting.

This is the data that I have:

FIRST RELATED ERROR:
SELinux is preventing /sbin/iscsid from 'read, write' accesses on the file lock.

*****  Plugin catchall (100. confidence) suggests  ***************************

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

Additional Information:
Source Context                system_u:system_r:iscsid_t:s0
Target Context                system_u:object_r:var_lock_t:s0
Target Objects                lock [ file ]
Source                        iscsid
Source Path                   /sbin/iscsid
Port                          <Unknown>
Host                          talon.sky.net
Source RPM Packages           iscsi-initiator-utils-6.2.0.872-16.fc16.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-75.fc16.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     talon.sky.net
Platform                      Linux talon.sky.net 3.2.7-1.fc16.x86_64 #1 SMP Tue
                              Feb 21 01:40:47 UTC 2012 x86_64 x86_64
Alert Count                   1
First Seen                    Tue 06 Mar 2012 05:54:56 PM EST
Last Seen                     Tue 06 Mar 2012 05:54:56 PM EST
Local ID                      44139e54-aae5-4400-aad6-6766f818cfc9

Raw Audit Messages
type=AVC msg=audit(1331074496.918:53): avc:  denied  { read write } for  pid=1579 comm="iscsid" name="lock" dev=tmpfs ino=20139 scontext=system_u:system_r:iscsid_t:s0 tcontext=system_u:object_r:var_lock_t:s0 tclass=file

type=SYSCALL msg=audit(1331074496.918:53): arch=x86_64 syscall=open success=no exit=EACCES a0=44ba91 a1=42 a2=1b6 a3=1000 items=0 ppid=1 pid=1579 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=iscsid exe=/sbin/iscsid subj=system_u:system_r:iscsid_t:s0 key=(null)

Hash: iscsid,iscsid_t,var_lock_t,file,read,write



SECOND ERROR:

SELinux is preventing /sbin/iscsid from link access on the file lock.

*****  Plugin catchall (100. confidence) suggests  ***************************

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

Additional Information:
Source Context                system_u:system_r:iscsid_t:s0
Target Context                system_u:object_r:var_lock_t:s0
Target Objects                lock [ file ]
Source                        iscsid
Source Path                   /sbin/iscsid
Port                          <Unknown>
Host                          talon.sky.net
Source RPM Packages           iscsi-initiator-utils-6.2.0.872-16.fc16.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-75.fc16.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     talon.sky.net
Platform                      Linux talon.sky.net 3.2.7-1.fc16.x86_64 #1 SMP Tue
                              Feb 21 01:40:47 UTC 2012 x86_64 x86_64
Alert Count                   1
First Seen                    Tue 06 Mar 2012 05:54:56 PM EST
Last Seen                     Tue 06 Mar 2012 05:54:56 PM EST
Local ID                      8a94aff9-f926-4d47-9561-4c6465df4bd1

Raw Audit Messages
type=AVC msg=audit(1331074496.918:54): avc:  denied  { link } for  pid=1579 comm="iscsid" name="lock" dev=tmpfs ino=20139 scontext=system_u:system_r:iscsid_t:s0 tcontext=system_u:object_r:var_lock_t:s0 tclass=file

type=SYSCALL msg=audit(1331074496.918:54): arch=x86_64 syscall=link success=no exit=EACCES a0=44ba91 a1=44baa6 a2=d a3=1000 items=0 ppid=1 pid=1579 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=iscsid exe=/sbin/iscsid subj=system_u:system_r:iscsid_t:s0 key=(null)

Hash: iscsid,iscsid_t,var_lock_t,file,link

Comment 5 Miroslav Grepl 2012-03-15 17:33:17 UTC
Ok I see what the problem is now. What does

$ ls -Z /var/lock/subsys/iscsid 

$ matchpathcon ls -Z /var/lock/subsys/iscsid 

and

$ grep -r touch -C 2 /etc/init.d/iscsi*

Comment 6 Ron Gonzalez 2012-03-15 17:45:43 UTC
[root@talon ~]# ls -Z /var/lock/subsys/iscsid
-rw-r--r--. root root system_u:object_r:var_lock_t:s0  /var/lock/subsys/iscsid


[root@talon ~]# matchpathcon 'ls -Z /var/lock/subsys/iscsid'
ls -Z /var/lock/subsys/iscsid   <<none>>

[root@talon ~]# matchpathcon /var/lock/subsys/iscsid
/var/lock/subsys/iscsid system_u:object_r:var_lock_t:s0


[root@talon ~]# grep -r touch -C 2 /etc/init.d/iscsi*
/etc/init.d/iscsi-    # some could be down temporarily.
/etc/init.d/iscsi-    success $"Starting $prog"
/etc/init.d/iscsi:    touch $lockfile
/etc/init.d/iscsi-    echo
/etc/init.d/iscsi-    return 0
--
/etc/init.d/iscsid-    retval=$?
/etc/init.d/iscsid-    echo
/etc/init.d/iscsid:    touch $lockfile
/etc/init.d/iscsid-}
/etc/init.d/iscsid-
--
/etc/init.d/iscsid-    start_iscsid
/etc/init.d/iscsid-    # a force start could imply the iscsi service is started due to how it
/etc/init.d/iscsid:    # lazy starts. We need to touch the lock file so it is shutdown later
/etc/init.d/iscsid:    touch $iscsi_lockfile
/etc/init.d/iscsid-}
/etc/init.d/iscsid-
[root@talon ~]#

Comment 7 Ron Gonzalez 2012-03-15 17:48:16 UTC
[root@talon init.d]# ls -Z /var/lock/subsys/
-rw-r--r--. root root system_u:object_r:var_lock_t:s0  ip6tables
-rw-r--r--. root root system_u:object_r:var_lock_t:s0  iptables
-rw-r--r--. root root system_u:object_r:var_lock_t:s0  iscsi
-rw-r--r--. root root system_u:object_r:var_lock_t:s0  iscsid
-rw-r--r--. root root system_u:object_r:var_lock_t:s0  mediatomb
-rw-r--r--. root root system_u:object_r:var_lock_t:s0  netfs
-rw-r--r--. root root system_u:object_r:var_lock_t:s0  network
-rw-r--r--. root root system_u:object_r:var_lock_t:s0  sandbox

Comment 8 Miroslav Grepl 2012-04-26 11:48:35 UTC
*** Bug 816361 has been marked as a duplicate of this bug. ***

Comment 9 Miroslav Grepl 2012-04-26 11:55:01 UTC
Could we use

/var/lock/iscsi

directory for iscsi* lock files?

Comment 10 Mike Christie 2012-04-26 21:35:32 UTC
(In reply to comment #9)
> Could we use
> 
> /var/lock/iscsi
> 
> directory for iscsi* lock files?

If that is what I am supposed to be doing, I can change that in the iscsi code/scripts.

Comment 11 Miroslav Grepl 2012-04-27 09:56:28 UTC
Yeap, then it should work.

$ rpm -qf /var/lock/iscsi
iscsi-initiator-utils-6.2.0.872-18.fc17.x86_6

It means that /var/lock/iscsi will be labeled correctly and lock file will be created with the right label.

Comment 12 Mike Christie 2012-04-30 22:29:07 UTC
(In reply to comment #11)
> Yeap, then it should work.
> 
> $ rpm -qf /var/lock/iscsi
> iscsi-initiator-utils-6.2.0.872-18.fc17.x86_6
> 
> It means that /var/lock/iscsi will be labeled correctly and lock file will be
> created with the right label.

I do not think that is right. It does not help at least.

Selinux seems to be complaining about lock and lock.write. iscsid and iscsiadm use lock and lock.write to serialize access to some files. And those lock files are already in /var/lock/iscsi.

I think selinux is just not happy with iscsiadm/iscsid doing a link() and unlink() call on those files. It does:

#define LOCK_DIR                "/var/lock/iscsi"
#define LOCK_FILE               LOCK_DIR"/lock"
#define LOCK_WRITE_FILE         LOCK_DIR"/lock.write"

link(LOCK_FILE, LOCK_WRITE_FILE);

and

unlink(LOCK_WRITE_FILE);

Comment 13 Daniel Walsh 2012-05-01 22:41:11 UTC
ls -lZ /var/lock/iscsi

Comment 14 Ron Gonzalez 2012-05-02 03:33:10 UTC
[root@talon ~]# ls -lZ /var/lock/iscsi
-rw-------. root root system_u:object_r:var_lock_t:s0  lock
-rw-------. root root system_u:object_r:var_lock_t:s0  lock.write

Comment 15 Daniel Walsh 2012-05-02 19:49:38 UTC
restorecon -R -v /var/lock/iscsi

Change anything?

Comment 16 Ron Gonzalez 2012-05-02 19:58:41 UTC
[root@talon ~]# restorecon -R -v /var/lock/iscsi

restorecon reset /run/lock/iscsi context system_u:object_r:var_lock_t:s0->system_u:object_r:iscsi_lock_t:s0

restorecon reset /run/lock/iscsi/lock.write context system_u:object_r:var_lock_t:s0->system_u:object_r:iscsi_lock_t:s0


Now see output:

[root@talon ~]#  ls -lZ /var/lock/iscsi
-rw-------. root root system_u:object_r:iscsi_lock_t:s0 lock
-rw-------. root root system_u:object_r:iscsi_lock_t:s0 lock.write

Looks like that fixed it.

However please note that my SeLinux policy has been updated since I opened this case:
selinux-policy.noarch              3.10.0-84.fc16             @updates
selinux-policy-targeted.noarch     3.10.0-84.fc16             @updates

Comment 17 Miroslav Grepl 2012-05-03 06:47:42 UTC
And this is correct label for /var/lock/iscsi

So we need to get the right label for /var/lock/iscsi directory.

What does

$ rpm -qf /var/lock/iscsi

Comment 18 Ron Gonzalez 2012-05-03 13:56:30 UTC
[root@talon ~]# rpm -qf /var/lock/iscsi
iscsi-initiator-utils-6.2.0.872-16.fc16.x86_64

Comment 19 Daniel Walsh 2012-05-03 14:31:57 UTC
SO either something is deleting and recreating this directory or it was broken before the package was updated.

If you remove the directory and execute

yum reinstall iscsi-initiator-utils

What does the directory end up labeled?

Comment 20 Ron Gonzalez 2012-05-03 14:47:40 UTC
[root@talon ~]# yum reinstall iscsi-initiator-utils
[....]
Resolving Dependencies
--> Running transaction check
---> Package iscsi-initiator-utils.x86_64 0:6.2.0.872-16.fc16 will be reinstalled
[....]
Downloading Packages:
iscsi-initiator-utils-6.2.0.872-16.fc16.x86_64.rpm        
[....]
Running Transaction
  Installing : iscsi-initiator-utils-6.2.0.872-16.fc16.x86_64                                                                                                                       1/1
  Verifying  : iscsi-initiator-utils-6.2.0.872-16.fc16.x86_64                                                                                                                       1/1
Installed:
  iscsi-initiator-utils.x86_64 0:6.2.0.872-16.fc16

[root@talon ~]#  ls -lZ /var/lock/iscsi
-rw-------. root root system_u:object_r:iscsi_lock_t:s0 lock
-rw-------. root root system_u:object_r:iscsi_lock_t:s0 lock.write

#reboot
[rebooting system]
[system back up]

[root@talon ~]# ls -lZ /var/lock/iscsi
-rw-------. root root system_u:object_r:var_lock_t:s0  lock
-rw-------. root root system_u:object_r:var_lock_t:s0  lock.write

Looks like on reboot the files are created with the wrong labels.

Comment 21 Mike Christie 2012-05-08 06:26:28 UTC
Created attachment 582863 [details]
Fix selinux iscsid lock errors

I think I found the problem. The iscsi-initiator-utils.spec file was missing the lock.write definitions. If I add them to the spec like in the attached patch it fixes the problem for me.

Does this make sense?

Comment 22 Daniel Walsh 2012-05-08 14:46:58 UTC
No that would have no Effect.  Which app is doing the "mkdir /var/lock/iscsi"?  This directory is being created at boot time and is not resetting the context with the correct SELinux label.

Comment 23 Mike Christie 2012-05-09 04:18:38 UTC
(In reply to comment #22)
> No that would have no Effect.  Which app is doing the "mkdir /var/lock/iscsi"? 

iscsid.

> This directory is being created at boot time and is not resetting the context
> with the correct SELinux label.

How do I do that? Is there a syscall I need to do?

Comment 24 Daniel Walsh 2012-05-09 13:43:57 UTC
No that is our job.

Looking at selinux-policy-3.10.0-88.fc16 I see this policy.

manage_dirs_pattern(iscsid_t, iscsi_lock_t, iscsi_lock_t)
manage_files_pattern(iscsid_t, iscsi_lock_t, iscsi_lock_t)
files_lock_filetrans(iscsid_t, iscsi_lock_t, { dir file })

Which says if the iscdid_t process creates a directory or file in a directory labeled var_lock_t it will create this as iscsi_lock_t, which is not what we are seeing.

You can check for these rules on your machine using sesearch

 sesearch -T -s iscsid_t -t var_lock_t 2> /dev/null 
Found 2 semantic te rules:
   type_transition iscsid_t var_lock_t : file iscsi_lock_t; 
   type_transition iscsid_t var_lock_t : dir iscsi_lock_t;

Comment 25 Ron Gonzalez 2012-05-09 14:12:04 UTC
Oddly enough I apparently have these rules:
[root@talon ~]#  sesearch -T -s iscsid_t -t var_lock_t 2> /dev/null
Found 2 semantic te rules:
   type_transition iscsid_t var_lock_t : file iscsi_lock_t;
   type_transition iscsid_t var_lock_t : dir iscsi_lock_t;

[root@talon ~]# ls -alZ /var/lock/iscsi
drw-------. root root system_u:object_r:iscsi_lock_t:s0 .
drwxr-xr-x. root root system_u:object_r:var_lock_t:s0  ..
-rw-------. root root system_u:object_r:iscsi_lock_t:s0 lock
-rw-------. root root system_u:object_r:iscsi_lock_t:s0 lock.write


I'll retest by rebooting again and report back results.

Comment 26 Mike Christie 2012-05-14 02:46:47 UTC
(In reply to comment #23)
> (In reply to comment #22)
> > No that would have no Effect.  Which app is doing the "mkdir /var/lock/iscsi"? 
> 
> iscsid.
> 

Not sure if it matters, but iscsid is making the dir and lock file, but I just saw that in fedora recently something (I think it is systemd - still debugging) is removing the /var/lock/iscsi dir on shutdown/reboot. When the system starts again iscsid will then create the /var/lock/iscsi dir again.

Should iscsid normally be removing the /var/lock/iscsi dir when iscsid is stopped/killed, or is it ok for it to leave the /var/lock/iscsi dir there between runs.

Comment 27 Daniel Walsh 2012-05-16 03:20:28 UTC
I don't see where it matters.

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

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 16'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 16 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 to click on 
"Clone This Bug" and open it against that version of Fedora.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 29 Fedora End Of Life 2013-02-13 17:49:12 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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.