Bug 972962
| Summary: | iscsid denied from lockfile when socket activated | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Chris Leech <cleech> |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | cleech, dominick.grift, dwalsh, mgrepl |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | selinux-policy-3.12.1-52.fc19 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-06-15 03:07:00 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: | |||
Chris, what does # ls -dZ /var/lock/iscsi it looks you have mislabeled this directory caused by testing. I see # rpm -qf /var/lock/iscsi iscsi-initiator-utils-6.2.0.873-5.fc19.x86_64 # ls -dZ drwxr-xr-x. root root staff_u:object_r:iscsi_lock_t:s0 /var/lock/iscsi Also what does # rpm -qf selinux-policy commit 7c3caf353e3e17b6654411176be7172d6a6759af
Author: Miroslav Grepl <mgrepl>
Date: Tue Jun 11 12:32:48 2013 +0200
Add labeling for /usr/sbin/iscsiadm
The added labeling for iscsiadm works when it's being called as part of the iscsi.service unit file from systemd. It does not fix the issue when iscsiadm is run from a command line shell. Is that because transitions directly from a manually run command to the iscsid_exec_t domain are prohibited? (sorry, I'm still trying to wrap my head around this all) I'm thinking I should probably make use of the systemd tmpfiles service to make sure these are created with proper labels before any manual admin commands can be run. If you run it from the command line then there is no transition and you stay as unconfined_t.
But I found the problem. I added additional fixes. You can test it with the following local policy
# cat mypol.te
policy_module(mypol,1.0)
require{
type unconfined_t;
type iscsi_lock_t;
}
files_lock_filetrans(unconfined_t, iscsi_lock_t, dir, "iscsi")
(In reply to Miroslav Grepl from comment #4) > If you run it from the command line then there is no transition and you stay > as unconfined_t. > > But I found the problem. I added additional fixes. You can test it with the > following local policy > > # cat mypol.te > policy_module(mypol,1.0) > > require{ > type unconfined_t; > type iscsi_lock_t; > } > > files_lock_filetrans(unconfined_t, iscsi_lock_t, dir, "iscsi") That works, thanks! selinux-policy-3.12.1-52.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-52.fc19 selinux-policy-3.12.1-52.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: If the iscsi lock file is first created by iscsiadm (either run directly or from the iscsi.service to check for sessions configured for auto-login) then iscsid is denied access to it once it starts. This always happens if iscsid is configured for socket activation, instead of having it start before any iscsiadm commands are run. When iscsid.service started first (good): # ls -Z /var/lock/iscsi/lock -rw-------. root root system_u:object_r:iscsi_lock_t:s0 /var/lock/iscsi/lock When iscsi.service and iscsid.socket are started: # ls -Z /var/lock/iscsi/lock -rw-------. root root system_u:object_r:var_lock_t:s0 /var/lock/iscsi/lock When juts iscsid.socket is started, and iscsiadm is run from the command line: # ls -Z /var/lock/iscsi/lock -rw-------. root root unconfined_u:object_r:var_lock_t:s0 /var/lock/iscsi/lock So if iscsiadm creates the lock file, it does not have the same security context as if iscsid creates it. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. Disable direct iscsid service start and enable socket activation (should be the default in f19) # systemctl stop iscsid.service # systemctl start iscsid.socket 2. Make sure the lockfile doesn't already exist from a previous iscsid run # rm -rf /var/lock/iscsi 3. Use iscsiadm or the iscsi.service to request login to a configured iscsi target # iscsiadm -m node --login (or, with a target record configured for automatic login) # systemctl start iscsi.service Actual results: iscsid reports errors in the journal # journalctl -u iscsid.service Jun 10 15:28:40 localhost.localdomain systemd[1]: Starting Open-iSCSI... Jun 10 15:28:40 localhost.localdomain iscsid[735]: iSCSI logger with pid=736 started! Jun 10 15:28:40 localhost.localdomain systemd[1]: Failed to read PID from file /var/run/iscsid.pid: Invalid argument Jun 10 15:28:40 localhost.localdomain systemd[1]: Started Open-iSCSI. Jun 10 15:28:41 localhost.localdomain iscsid[736]: iSCSI daemon with pid=737 started! Jun 10 15:28:41 localhost.localdomain iscsid[736]: Maybe you are not root? Jun 10 15:28:41 localhost.localdomain iscsid[736]: Could not lock discovery DB: /var/lock/iscsi/lock.write: Permission denied Jun 10 15:28:41 localhost.localdomain iscsid[736]: Could not read discovery record for 192.168.122:3260. Jun 10 15:28:41 localhost.localdomain iscsid[736]: Maybe you are not root? Jun 10 15:28:41 localhost.localdomain iscsid[736]: Could not lock discovery DB: /var/lock/iscsi/lock.write: Permission denied Jun 10 15:28:41 localhost.localdomain iscsid[736]: Could not read discovery record for 192.168.122.1:3260. Jun 10 15:28:41 localhost.localdomain iscsid[736]: Could not set session1 priority. READ/WRITE throughout and latency could be affected. Jun 10 15:28:41 localhost.localdomain iscsid[736]: Connection1:0 to [target: iqn.1992-01.com.example:target.0, portal: 192.168.122.1,3260] through [iface: default] is operational now /var/log/audit/audit.log contains related entries type=SERVICE_START msg=audit(1370903321.621:392): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="iscsid" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' type=AVC msg=audit(1370903320.623:393): avc: denied { read write } for pid=737 comm="iscsid" name="lock" dev="tmpfs" ino=14755 scontext=system_u:system_r:iscsid_t:s0 tcontext=unconfined_u:object_r:var_lock_t:s0 tclass=file type=SYSCALL msg=audit(1370903320.623:393): arch=c000003e syscall=2 success=no exit=-13 a0=44c059 a1=42 a2=1b6 a3=0 items=0 ppid=1 pid=737 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="iscsid" exe="/usr/sbin/iscsid" subj=system_u:system_r:iscsid_t:s0 key=(null) type=AVC msg=audit(1370903320.623:394): avc: denied { link } for pid=737 comm="iscsid" name="lock" dev="tmpfs" ino=14755 scontext=system_u:system_r:iscsid_t:s0 tcontext=unconfined_u:object_r:var_lock_t:s0 tclass=file type=SYSCALL msg=audit(1370903320.623:394): arch=c000003e syscall=86 success=no exit=-13 a0=44c059 a1=44c06e a2=1b6 a3=0 items=0 ppid=1 pid=737 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="iscsid" exe="/usr/sbin/iscsid" subj=system_u:system_r:iscsid_t:s0 key=(null) type=AVC msg=audit(1370903320.623:395): avc: denied { read write } for pid=737 comm="iscsid" name="lock" dev="tmpfs" ino=14755 scontext=system_u:system_r:iscsid_t:s0 tcontext=unconfined_u:object_r:var_lock_t:s0 tclass=file type=SYSCALL msg=audit(1370903320.623:395): arch=c000003e syscall=2 success=no exit=-13 a0=44c059 a1=42 a2=1b6 a3=0 items=0 ppid=1 pid=737 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="iscsid" exe="/usr/sbin/iscsid" subj=system_u:system_r:iscsid_t:s0 key=(null) type=AVC msg=audit(1370903320.623:396): avc: denied { link } for pid=737 comm="iscsid" name="lock" dev="tmpfs" ino=14755 scontext=system_u:system_r:iscsid_t:s0 tcontext=unconfined_u:object_r:var_lock_t:s0 tclass=file type=SYSCALL msg=audit(1370903320.623:396): arch=c000003e syscall=86 success=no exit=-13 a0=44c059 a1=44c06e a2=1b6 a3=0 items=0 ppid=1 pid=737 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="iscsid" exe="/usr/sbin/iscsid" subj=system_u:system_r:iscsid_t:s0 key=(null) Expected results: Starting via socket activation should work, and behave the same as directly starting the service Additional info: