Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1514272
Summary: | SELinux breaks snapper {status,diff,undochange,xadiff} | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dag Odenhall <dag.odenhall> | ||||||||
Component: | selinux-policy | Assignee: | LVM and device-mapper development team <lvm-team> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | unspecified | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 27 | CC: | agk, dwalsh, ignatenko, lvm-team, lvrabec, mgrepl, msnitzer, nmorell, okozina, plautrba, pmoore | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | selinux-policy-3.13.1-283.26.fc27 | Doc Type: | If docs needed, set a value | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2018-02-27 17:21:51 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
Dag Odenhall
2017-11-16 23:30:06 UTC
Trying $ sudo restorecon -Rvn /.snapshots I get stuff like this for seemingly every file in the snapshot: Would relabel /.snapshots/1/snapshot/etc/system-release from system_u:object_r:etc_t:s0 to system_u:object_r:snapperd_data_t:s0 I don't dare run it without -n to see if that fixes anything, because I don't know how to revert that if it ends up making things worse. So I tried restorecon on two throwaway snapshots: # snapper create # echo test > test # snapper create # restorecon -Rv /.snapshots/55 # restorecon -Rv /.snapshots/56 # snapper diff 55..56 IO Error (open failed path://.snapshots/56/snapshot/etc/polkit-1 errno:1 (Operation not permitted)). So that didn't fix anything, but the restorecons didn't really manage to do much, and mostly produced output like this: [...] restorecon: Could not set context for /.snapshots/56/snapshot/usr/src: Read-only file system restorecon: Could not set context for /.snapshots/56/snapshot/usr/src/debug: Read-only file system restorecon: Could not set context for /.snapshots/56/snapshot/usr/src/kernels: Read-only file system Relabeled /.snapshots/56/snapshot/.snapshots from system_u:object_r:unlabeled_t:s0 to system_u:object_r:snapperd_data_t:s0 Makes sense; snapper snapshots are read-only. This also breaks the snapper-cleanup.timeline systemd timer: # /usr/libexec/snapper/systemd-helper --cleanup IO Error (open failed path://.snapshots/104/snapshot/etc/polkit-1 errno:1 (Operation not permitted)). Meaning snapshots never get pruned. It also breaks pam_snapper. For some reason it still works with the sudo and sudo-i services, but not with any other PAM service I tried, such as login. I tried # semanage permissive -a snapperd_t which seems to be enough to make the snapper commands work without making all of SELinux permissive. However, pam_snapper still isn't working, and of course this fix means running snapper without SELinux protection. I followed the advice in the journal and did: # ausearch -c 'snapperd' --raw | audit2allow -M my-snapperd # semodule -X 300 -i my-snapperd.pp # semanage permissive -d snapperd_t That seems to have made snapper work in Enforcing, however pam_snapper still isn't working and there's no such advice in the journal. If I see this in the journal: Nov 26 12:10:57 vaio audit[862]: USER_AVC pid=862 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.opensuse.Snapper member=CreatePreSnapshot dest=org.opensuse.Snapper spid=12204 tpid=12206 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:system_r:snapperd_t:s0-s0:c0.c1023 tclass=dbus permissive=0 does that then mean I can do this using that auid? # ausearch -a 4294967295 | audit2allow -M my-pam_snapper # semodule -X 300 -i my-pam_snapper.pp Well I did, and it seems to have made pam_snapper work for login. I'll have to reboot and see if everything works in Enforcing now, and I'll post the .te files audit2allow produced. Created attachment 1359139 [details]
ausearch -c 'snapperd' --raw | audit2allow -M my-snapperd
Created attachment 1359140 [details]
ausearch -a 4294967295 --raw | audit2allow -M my-pam_snapper
Contains a lot of this:
#!!!! This avc is allowed in the current policy
I'm guessing it's because of overlap with the above my-snapperd module.
Hi Dag, Could you remove your local SELinux module, then try to reproduce the scenario and attach output of: # ausearch -m AVC, USER_AVC -ts today THanks, Lukas. Created attachment 1368049 [details] ausearch -m AVC,USER_AVC -ts today Some notes: * I collected these AVCs in Enforcing mode. Would it be better to do it in Permissive, so that early AVCs don't block later ones? * Snapper creates an arbitrary and growing number of snapshots of whole subvolumes, and walks the whole tree to compute differences, so the paths you see in this AVC log are arbitrary. The snapshots are numbered and kept under SUBVOL/.snapshot/NUMBER/snapshot * Snapper wants to be able to read all files in the snapshots to be able to compute differences between snapshots. That rather sounds like a security nightmare, but maybe I'm misunderstanding how it works because it's supposed to have some support for SELinux built in, for example https://github.com/openSUSE/snapper/blob/master/snapper/Selinux.cc and https://github.com/openSUSE/snapper/blob/master/doc/selinux-readme.txt * That readme mentions a snapperd_data_t context/type, and that seems to be applied to the .snapshots subvolume, the numbered directories containing the snapshots, and the snapshot metadata files, but not to the snapshots themselves which are root_t. I don't know of that is correct or not, although the readme only says that the metadata should have that context and doesn't specifically dictate a context for the snapshots themselves, so maybe it's right. # ls -lZ /.snapshots/726 total 640 -rw-------. 1 root root system_u:object_r:snapperd_data_t:s0 650817 Dec 13 22:12 filelist-681.txt -rw-------. 1 root root system_u:object_r:snapperd_data_t:s0 434 Dec 13 22:11 info.xml dr-xr-xr-x. 1 root root system_u:object_r:root_t:s0 172 Dec 11 14:34 snapshot # ls -lZd /.snapshots/726 drwxr-xr-x. 1 root root system_u:object_r:snapperd_data_t:s0 64 Dec 13 22:12 /.snapshots/726 # ls -lZd /.snapshots drwxr-x---. 1 root root system_u:object_r:snapperd_data_t:s0 608 Dec 14 15:36 /.snapshots Regarding the potential security nightmare, I've confirmed through testing that the process for creating a comparison between snapshots runs with root privileges, regardless of the calling user, but only root is allowed to be the calling user unless configured otherwise with SYNC_ACL and ALLOW_USERS/ALLOW_GROUPS. With SYNC_ACL=yes ALLOW_GROUPS=wheel I'm able to create such a comparison as non-root that spots a change to /etc/shadow, but I'm not able to see what the change is nor read that file in either snapshot. Snapper will simply say, $ snapper -c root status 788..789 c..... /etc/shadow But if I try, $ snapper -c root diff 788..789 /usr/bin/diff: /.snapshots/788/snapshot/etc/shadow: Permission denied /usr/bin/diff: /.snapshots/789/snapshot/etc/shadow: Permission denied $ cat /.snapshots/78{8,9}/snapshot/etc/shadow cat: /.snapshots/788/snapshot/etc/shadow: Permission denied cat: /.snapshots/789/snapshot/etc/shadow: Permission denied With the default configuration, you have to be root to do anything; with a configuration allowing access to other users, all they can do is spot changes without seeing what the changes are. (This is with my policy modules installed, to make snapper work as intended.) selinux-policy-3.13.1-283.26.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-a9711c96b2 selinux-policy-3.13.1-283.26.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-a9711c96b2 selinux-policy-3.13.1-283.26.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report. Still seems to be broken for me: # snapper diff 111..113 IO Error (open failed path://.snapshots/113/snapshot/etc/polkit-1 errno:1 (Operation not permitted)). # ausearch -m AVC,USER_AVC -ts today --raw | tail -4 type=AVC msg=audit(1520383234.761:2266): avc: denied { getattr } for pid=4815 comm="snapperd" path="/.snapshots/113/snapshot/etc/httpd/run" dev="sda4" ino=8522 scontext=system_u:system_r:snapperd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:httpd_config_t:s0 tclass=lnk_file permissive=0 type=AVC msg=audit(1520383234.778:2267): avc: denied { fowner } for pid=4815 comm="snapperd" capability=3 scontext=system_u:system_r:snapperd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:snapperd_t:s0-s0:c0.c1023 tclass=capability permissive=0 type=AVC msg=audit(1520383234.778:2268): avc: denied { fowner } for pid=4815 comm="snapperd" capability=3 scontext=system_u:system_r:snapperd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:snapperd_t:s0-s0:c0.c1023 tclass=capability permissive=0 type=AVC msg=audit(1520383234.723:2253): avc: denied { getattr } for pid=4815 comm="snapperd" path="/.snapshots/111/snapshot/etc/NetworkManager/dispatcher.d/no-wait.d/10-ifcfg-rh-routes.sh" dev="sda4" ino=4970 scontext=system_u:system_r:snapperd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:NetworkManager_initrc_exec_t:s0 tclass=lnk_file permissive=0 All seem to be issues reported earlier about this. # rpm -q selinux-policy selinux-policy-3.13.1-283.26.fc27.noarch |