Bug 1677325
| Summary: | dac_override capability for sbd has been removed in rhel-8.0 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Miroslav Lisik <mlisik> |
| Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Milos Malik <mmalik> |
| Severity: | urgent | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.0 | CC: | cfeist, jfriesse, jpokorny, kgaillot, kwenning, lvrabec, mmalik, plautrba, ssekidde, wchadwic, zpytela |
| Target Milestone: | rc | Keywords: | Patch, TestBlocker |
| Target Release: | 8.0 | Flags: | pm-rhel:
mirror+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | selinux-policy-3.14.1-61.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-06-14 01:25:48 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: | |||
commit 01421deef863514d35029c3534ee63514e4d0822 (HEAD -> rawhide)
Author: Lukas Vrabec <lvrabec>
Date: Thu Feb 14 17:14:08 2019 +0100
Add dac_override capability for sbd_t SELinux domain
Fix from Fedora.
I believe that https://github.com/ClusterLabs/sbd/pull/69 together with: > 2. ensure this server side (pacemaker) does allow group-derived access > (i.e., the access permissions for group are as relaxed as needed, > umask notwithstanding) -- outside of the sbd's scope would help here orthogonally to this poor man's workaround (IIUIC) is applied. Related SELinux question: is my understanding correct that within the allowed label (domain) based accesses, DAC_OVERRIDE is still virtually acknowledged? See "sesearch -A | less": > [...] > allow cluster_t cluster_t:capability { ... dac_override ... }; > [...] > allow clvmd_t clvmd_t:capability { ... dac_override ... }; > [...] with pattern: > allow X_t X_t:capability { ... dac_override ... }; If so, that might explain why pacemaker (combination of cluster_t sub-daemons, some of them running as root, some not), appears to work, even if there's no explicit assignment of dac_override (like is made here with sbd) in rhcs.te. Also, if that's the case, additional question: is it a hard rule, or is it just a matter of application of some very generic rule in the policy, hence generally a "configuration", i.e., can this provision be disabled at will/by maintainer's decision in the future and hence should not be relied upon? I'm not sure if I understood your question, but maybe this can help: https://lukas-vrabec.com/index.php/2018/07/03/why-do-you-see-dac_override-selinux-denials/ (In reply to Lukas Vrabec from comment #4) > I'm not sure if I understood your question, but maybe this can help: > https://lukas-vrabec.com/index.php/2018/07/03/why-do-you-see-dac_override- > selinux-denials/ Not sure if this really is the question from poki but it would be mine: How does e.g. cluster_t get dac_override capability while it isn't found in rhcs.te? And as a followup: Should/Can we rely on that mechanism to be there in future? Of course I'm aware that the issue should be solved within the daemons so that dac_override isn't needed anymore on the longer run. Lukáší, that blog post (which I've read prior to asking) is unfortunately superficial to the extent that it doesn't touch the question how comes that reflexive rules for a label that are not tracked explicitly (at least not in the end-use form along other rules in the same file in question, like rhcs.te) will magically appear in run-time/said sesearch listing. Klaus just reiterates my questions. Can you advise us here, please? (In reply to Jan Pokorný [poki] from comment #7) > > Klaus just reiterates my questions. That was my intention to just put it into different words - for the case I had gotten it right ;-) The reason why cluster_t has dac_override in sesearch output and there is no allow rule allowing dac_override in rhcs.te is that cluster_t is part of unconfined_domain_type:
# seinfo -xtcluster_t
Types: 1
type cluster_t alias { corosync_t aisexec_t rgmanager_t pacemaker_t }, can_read_shadow_passwords, can_write_shadow_passwords, can_relabelto_shadow_passwords, nsswitch_domain, can_change_object_identity, can_load_kernmodule, can_load_policy, can_setbool, can_setenforce, can_setsecparam, corenet_unconfined_type, corenet_unlabeled_type, devices_unconfined_type, domain, files_unconfined_type, filesystem_unconfined_type, fixed_disk_raw_read, kern_unconfined, kernel_system_state_reader, named_filetrans_domain, netlabel_peer_type, process_uncond_exempt, selinux_unconfined_type, storage_unconfined_type, unconfined_domain_type, dbusd_unconfined, initrc_transition_domain, daemon, initrc_domain, syslog_client_type, sepgsql_unconfined_type, cluster_domain, can_relabelto_binary_policy, userdom_filetrans_type, virsh_transition_domain, x_domain, xserver_unconfined_type;
And for unconfined_domain_type is this action allowed. unconfined_domain_type is attribute and attribute is set of types.
I hope this helped.
Thanks a lot. I guess any sort of recursive resolving like that is not currently available with the standard shipped SELinux tooling -- might be a good thing if users were able to observe this explanation on their own. Anyway, second, less critical part of this question was whether we can be reasonably sure that dac_override is not going away from this unconfined_domain_type attribute, and, for that matter, that cluster_t will remain part of this attribute, in the foreseeable future. It might influence something currently under development. Thanks. (note that the alternative solution referenced from [comment 3] would require allowing `setgid` rather than `dac_override` [thanks to Ken Gaillot for raising that], which is a desired progress in a security sense, correct?) |
Description of problem: The dac_override capability for sbd was removed in current rhel-8.0 which caused that sbd does not work properly. Version-Release number of selected component (if applicable): [root@virt-009 ~]# rpm -qa selinux-policy* selinux-policy-3.14.1-57.el8.noarch selinux-policy-targeted-3.14.1-57.el8.noarch selinux-policy-devel-3.14.1-57.el8.noarch How reproducible: always Steps to Reproduce: 1. Setup cluster with enabled sbd 2. Start the cluster and look for AVCs Actual results: Sbd fencing does not work properly. Expected results: Sbd fencing works properly. Additional info: [root@virt-026 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.6 (Maipo) [root@virt-026 ~]# sesearch -A -s sbd_t -c capability Found 1 semantic av rules: allow sbd_t sbd_t : capability { dac_override dac_read_search ipc_lock sys_admin sys_boot sys_nice mknod } ; [root@virt-009 ~]# cat /etc/redhat-release Red Hat Enterprise Linux release 8.0 Beta (Ootpa) [root@virt-009 ~]# sesearch -A -s sbd_t -c capability allow sbd_t sbd_t:capability { dac_read_search ipc_lock mknod sys_admin sys_boot sys_nice }; After turning full auditing on and cluster start with enabled sbd I'm getting AVCs: [root@virt-009 ~]# auditctl -w /etc/shadow -p w [root@virt-009 ~]# pcs cluster start --all ... [root@virt-009 ~]# ausearch -m avc -ts recent ... --- time->Thu Feb 14 14:25:28 2019 type=PROCTITLE msg=audit(1550150728.671:118): proctitle=7362643A20776174636865723A20506163656D616B6572 type=PATH msg=audit(1550150728.671:118): item=0 name="/dev/shm/qb-cib_ro-request-8019-8005-15-header" inode=38073 dev=00:14 mode=0100600 ouid=189 ogid=189 rdev=00:00 obj=system_u:object_r:cluster_tmpfs_t:s0 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=CWD msg=audit(1550150728.671:118): cwd="/var/lib/pacemaker/cores" type=SYSCALL msg=audit(1550150728.671:118): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7fffc6a10d00 a2=2 a3=0 items=1 ppid=8004 pid=8005 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sbd" exe="/usr/sbin/sbd" subj=system_u:system_r:sbd_t:s0 key=(null) type=AVC msg=audit(1550150728.671:118): avc: denied { dac_override } for pid=8005 comm="sbd" capability=1 scontext=system_u:system_r:sbd_t:s0 tcontext=system_u:system_r:sbd_t:s0 tclass=capability permissive=0 ---- time->Thu Feb 14 14:25:29 2019 type=PROCTITLE msg=audit(1550150729.683:119): proctitle=7362643A20776174636865723A20506163656D616B6572 type=PATH msg=audit(1550150729.683:119): item=0 name="/dev/shm/qb-cib_ro-request-8019-8005-15-header" inode=38179 dev=00:14 mode=0100600 ouid=189 ogid=189 rdev=00:00 obj=system_u:object_r:cluster_tmpfs_t:s0 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=CWD msg=audit(1550150729.683:119): cwd="/var/lib/pacemaker/cores" type=SYSCALL msg=audit(1550150729.683:119): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7fffc6a10d00 a2=2 a3=0 items=1 ppid=8004 pid=8005 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sbd" exe="/usr/sbin/sbd" subj=system_u:system_r:sbd_t:s0 key=(null) type=AVC msg=audit(1550150729.683:119): avc: denied { dac_override } for pid=8005 comm="sbd" capability=1 scontext=system_u:system_r:sbd_t:s0 tcontext=system_u:system_r:sbd_t:s0 tclass=capability permissive=0 This shows that sbd is trying to access files /dev/shm/qb-cib_ro-request-* which have following permissions: [root@virt-009 ~]# for i in $(seq 1 10000); do ls -lZ /dev/shm/qb-cib_ro-request-* 2>/dev/null; done -rw------- 1 hacluster haclient ? 528384 Feb 14 14:41 /dev/shm/qb-cib_ro-request-8019-8005-15-data -rw-------. 1 hacluster haclient system_u:object_r:cluster_tmpfs_t:s0 528384 Feb 14 14:41 /dev/shm/qb-cib_ro-request-8019-8005-15-data -rw-------. 1 hacluster haclient system_u:object_r:cluster_tmpfs_t:s0 8252 Feb 14 14:41 /dev/shm/qb-cib_ro-request-8019-8005-15-header [root@virt-009 ~]# sesearch -A -s sbd_t -t cluster_tmpfs_t allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True allow domain file_type:file map; [ domain_can_mmap_files ]:True allow sbd_t cluster_tmpfs_t:dir { getattr ioctl lock open remove_name search write }; allow sbd_t cluster_tmpfs_t:file { append getattr ioctl lock map open read unlink write }; [root@virt-009 ~]# ps -eo comm,user,group,cmd | grep -E 'sbd|corosync|pacemaker|pcsd' | grep -v grep pcsd root root /usr/libexec/platform-python -Es /usr/sbin/pcsd corosync root root /usr/sbin/corosync -f sbd root root sbd: inquisitor sbd root root sbd: watcher: Pacemaker sbd root root sbd: watcher: Cluster pacemakerd root root /usr/sbin/pacemakerd -f pacemaker-based haclust+ haclient /usr/libexec/pacemaker/pacemaker-based pacemaker-fence root root /usr/libexec/pacemaker/pacemaker-fenced pacemaker-execd root root /usr/libexec/pacemaker/pacemaker-execd pacemaker-attrd haclust+ haclient /usr/libexec/pacemaker/pacemaker-attrd pacemaker-sched haclust+ haclient /usr/libexec/pacemaker/pacemaker-schedulerd pacemaker-contr haclust+ haclient /usr/libexec/pacemaker/pacemaker-controld [root@virt-009 ~]# ausearch -c 'sbd' --raw | audit2allow #============= sbd_t ============== allow sbd_t self:capability dac_override; This could be fixed on either side (SELinux or Cluster) so I'm adding cluster devs into cc list.