Description of problem: SELinux is preventing /usr/lib/systemd/systemd-importd from 'read' accesses on the directory /var/lib/machines. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-importd should be allowed read access on the machines directory 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 systemd-importd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:init_t:s0 Target Context system_u:object_r:systemd_machined_var_lib_t:s0 Target Objects /var/lib/machines [ dir ] Source systemd-importd Source Path /usr/lib/systemd/systemd-importd Port <Unknown> Host (removed) Source RPM Packages systemd-container-229-6.fc24.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-178.fc24.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.5.0-0.rc7.git0.2.fc24.x86_64 #1 SMP Tue Mar 8 02:20:08 UTC 2016 x86_64 x86_64 Alert Count 8 First Seen 2016-03-15 18:56:22 AEDT Last Seen 2016-03-15 18:56:38 AEDT Local ID 45ed6061-0631-45e6-9223-2f48d64e9ae4 Raw Audit Messages type=AVC msg=audit(1458028598.622:2091): avc: denied { read } for pid=21146 comm="systemd-import" name="machines" dev="sdc4" ino=136321 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:systemd_machined_var_lib_t:s0 tclass=dir permissive=0 type=SYSCALL msg=audit(1458028598.622:2091): arch=x86_64 syscall=open success=no exit=EACCES a0=5622d60a5240 a1=90800 a2=6e a3=5622d78a6000 items=1 ppid=20971 pid=21146 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=systemd-import exe=/usr/lib/systemd/systemd-import subj=system_u:system_r:init_t:s0 key=(null) type=CWD msg=audit(1458028598.622:2091): cwd=/ type=PATH msg=audit(1458028598.622:2091): item=0 name=/var/lib/machines inode=136321 dev=00:26 mode=040700 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:systemd_machined_var_lib_t:s0 nametype=NORMAL Hash: systemd-importd,init_t,systemd_machined_var_lib_t,dir,read Version-Release number of selected component: selinux-policy-3.13.1-178.fc24.noarch Additional info: reporter: libreport-2.6.4 hashmarkername: setroubleshoot kernel: 4.5.0-0.rc7.git0.2.fc24.x86_64 type: libreport
Description of problem: I called this command: machinectl pull-raw http://download.eng.brq.redhat.com/pub/fedora/development/latest-24/CloudImages/x86_64/images/Fedora-Cloud-Base-24-20160614.n.0.x86_64.raw.xz and get "Failed transfer image: Access denied" as response. I don't think selinux should block this one. Version-Release number of selected component: selinux-policy-3.13.1-190.fc24.noarch Additional info: reporter: libreport-2.7.1 hashmarkername: setroubleshoot kernel: 4.5.5-300.fc24.x86_64 reproducible: Not sure how to reproduce the problem type: libreport
FWIW, the SELinux failure on /var/lib/machines is just the start. After installing a SELinux module allowing systemd-import read access to /var/lib/machines it fails attempting to access the network (in my case port 443).
Description of problem: While trying to import Fedora Cloud Image with command: sudo machinectl pull-raw --verify=no http://spo1.linux.edu.lv/fedora/releases/24/CloudImages/x86_64/images/Fedora-Cloud-Base-24-1.2.x86_64.raw.xz Version-Release number of selected component: selinux-policy-3.13.1-191.17.fc24.noarch Additional info: reporter: libreport-2.7.2 hashmarkername: setroubleshoot kernel: 4.7.5-200.fc24.x86_64 type: libreport
Fedora 25 is also affected: SELinux is preventing systemd-importd from read access on the directory /var/lib/machines. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-importd should be allowed read access on the machines directory 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: # ausearch -c 'systemd-importd' --raw | audit2allow -M my-systemdimportd # semodule -X 300 -i my-systemdimportd.pp Additional Information: Source Context system_u:system_r:init_t:s0 Target Context system_u:object_r:systemd_machined_var_lib_t:s0 Target Objects /var/lib/machines [ dir ] Source systemd-importd Source Path systemd-importd Port <Unknown> Host <hostname> Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-224.fc25.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name <hostname> Platform Linux <hostname> 4.8.8-300.fc25.x86_64 #1 SMP Tue Nov 15 18:10:06 UTC 2016 x86_64 x86_64 Alert Count 2 First Seen 2016-11-26 22:13:46 EST Last Seen 2016-11-26 22:13:52 EST Local ID aeafc9c7-e757-43d2-b6aa-4aa337452ac7 Raw Audit Messages type=AVC msg=audit(1480216432.912:257): avc: denied { read } for pid=10489 comm="systemd-importd" name="machines" dev="dm-0" ino=3154989 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:systemd_machined_var_lib_t:s0 tclass=dir permissive=0 Hash: systemd-importd,init_t,systemd_machined_var_lib_t,dir,read
Running audit2allow and friends gives (eventually...) the modules below. This is still not enough, I get errors for d-bus on stopping/listing containers and also trying to set root password on a F25 container. But that's a story for another bug. root@maa ~]# cat *te module my-systemdimportd 1.0; require { type init_t; type systemd_machined_var_lib_t; class dir { ioctl read }; } #============= init_t ============== allow init_t systemd_machined_var_lib_t:dir { ioctl read }; --8<-- module my-systemdimport 1.0; require { type init_t; type unlabeled_t; type systemd_machined_var_lib_t; class file { create getattr ioctl open read rename setattr unlink write }; class dir { add_name ioctl read remove_name write }; } #============= init_t ============== allow init_t systemd_machined_var_lib_t:dir { add_name ioctl read remove_name write }; allow init_t systemd_machined_var_lib_t:file ioctl; allow init_t systemd_machined_var_lib_t:file { create getattr open read rename setattr unlink write }; allow init_t unlabeled_t:dir write;
We should create new domain for systemd-import domain.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. 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 EOL if it remains open with a Fedora 'version' of '24'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 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 change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Lukas Vrabec or Andrew Cook: Please change the affected version on this bug to at least Fedora 25 so it is not closed. (I haven't tried Fedora 26 yet, but I assume this has not changed...)
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. 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 EOL if it remains open with a Fedora 'version' of '25'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 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 change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Lukas Vrabec or Andrew Cook: Please change the affected version on this bug to Fedora 27. $ machinectl pull-raw http://mirrors.mit.edu/fedora/linux/releases/27/CloudImages/x86_64/images/Fedora-Cloud-Base-27-1.6.x86_64.raw.xz Failed to transfer image: Access denied The audit log still reports: type=AVC msg=audit(1513830987.786:1967): avc: denied { read } for pid=27957 comm="systemd-importd" name="machines" dev="dm-0" ino=2645286 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:systemd_machined_var_lib_t:s0 tclass=dir permissive=0
Description of problem: Ran "machinectl pull-raw https://dl.fedoraproject.org/pub/fedora/linux/releases/27/CloudImages/x86_64/images/Fedora-Cloud-Base-27-1.6.x86_64.raw.xz". Version-Release number of selected component: selinux-policy-3.13.1-283.26.fc27.noarch Additional info: reporter: libreport-2.9.3 hashmarkername: setroubleshoot kernel: 4.15.4-300.fc27.x86_64 type: libreport
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. 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 EOL if it remains open with a Fedora 'version' of '27'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 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 change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Lukas Vrabec or Andrew Cook: Please change the affected version on this bug to Fedora 29. $ machinectl import-raw Fedora-Cloud-Base-29-1.2.x86_64.raw.xz Failed to transfer image: Access denied There is now a systemd-importd domain, but this is still very broken -- these are just the start: type=AVC msg=audit(1543632636.789:500): avc: denied { create } for pid=3189 comm="systemd-importd" name="machines.lock" scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1543632636.789:501): avc: denied { read write open } for pid=3189 comm="systemd-importd" path="/run/systemd/machines.lock" dev="tmpfs" ino=56225 scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1543632636.789:502): avc: denied { lock } for pid=3189 comm="systemd-importd" path="/run/systemd/machines.lock" dev="tmpfs" ino=56225 scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1543632636.789:503): avc: denied { getattr } for pid=3189 comm="systemd-importd" path="/run/systemd/machines.lock" dev="tmpfs" ino=56225 scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(1543632636.790:504): avc: denied { execute } for pid=3189 comm="systemd-importd" name="mkfs.btrfs" dev="dm-0" ino=935678 scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:fsadm_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(1543632636.790:505): avc: denied { write } for pid=3189 comm="systemd-importd" name="lib" dev="dm-0" ino=154286 scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir permissive=1
David/Andrew, As I cannot reproduce, can you help me with it? I would also appreciate full audit logs as syscalls and full path are not recorded by default. The following commands should help: # to delete the implicit rule for not auditing auditctl -d never,task # to enable full auditing auditctl -w /etc/shadow -p w -k shadow-write And then after reproducing, better if ran in permissive domain or permissive mode, run: # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts recent In particular, I would like to see which file is to be written in the last AVC, the previous ones are quite clear.
*** Bug 1462382 has been marked as a duplicate of this bug. ***
Another reproducer here. With: $> uname -r; rpm -q selinux-policy 5.0.16-200.fc29.x86_64 selinux-policy-3.14.2-57.fc29.noarch Can observe the same here, via: $> machinectl pull-raw --verify=no \ https://download.fedoraproject.org/pub/fedora/linux/releases/30/Cloud/x86_64/images/Fedora-Cloud-Base-30-1.2.x86_64.raw.xz Results in an AVC that's preventing "systemd-importd from create access on the file machines.lock". Here is the full AVC: -------------------------------------------------------------------- SELinux is preventing systemd-importd from create access on the file machines.lock. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-importd should be allowed create access on the machines.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: # ausearch -c 'systemd-importd' --raw | audit2allow -M my-systemdimportd # semodule -X 300 -i my-systemdimportd.pp Additional Information: Source Context system_u:system_r:systemd_importd_t:s0 Target Context system_u:object_r:init_var_run_t:s0 Target Objects machines.lock [ file ] Source systemd-importd Source Path systemd-importd Port <Unknown> Host paraplu Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.2-57.fc29.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name paraplu Platform Linux paraplu 5.0.16-200.fc29.x86_64 #1 SMP Tue May 14 18:27:35 UTC 2019 x86_64 x86_64 Alert Count 5 First Seen 2019-05-20 15:21:34 CEST Last Seen 2019-05-20 15:25:21 CEST Local ID 257fb953-4d23-40f6-a374-cd6deaf8860c Raw Audit Messages type=AVC msg=audit(1558358721.897:1188): avc: denied { create } for pid=10571 comm="systemd-importd" name="machines.lock" scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=0 Hash: systemd-importd,systemd_importd_t,init_var_run_t,file,create --------------------------------------------------------------------
I've put SELinux in `permissive`, there are several other AVCs: ---- $> sudo ausearch -m avc -ts recent ---- time->Mon May 20 15:53:20 2019 type=AVC msg=audit(1558360400.080:1198): avc: denied { read write open } for pid=16432 comm="systemd-importd" path="/run/systemd/machines.lock" dev="tmpfs" ino=3281141 scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=0 ---- time->Mon May 20 15:56:34 2019 type=AVC msg=audit(1558360594.841:1204): avc: denied { lock } for pid=17108 comm="systemd-importd" path="/run/systemd/machines.lock" dev="tmpfs" ino=3281141 scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=0 ---- time->Mon May 20 15:57:49 2019 type=AVC msg=audit(1558360669.030:1208): avc: denied { lock } for pid=17342 comm="systemd-importd" path="/run/systemd/machines.lock" dev="tmpfs" ino=3281141 scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=0 ---- time->Mon May 20 15:58:15 2019 type=AVC msg=audit(1558360695.098:1212): avc: denied { lock } for pid=17342 comm="systemd-importd" path="/run/systemd/machines.lock" dev="tmpfs" ino=3281141 scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1 ---- time->Mon May 20 15:58:15 2019 type=AVC msg=audit(1558360695.098:1213): avc: denied { getattr } for pid=17342 comm="systemd-importd" path="/run/systemd/machines.lock" dev="tmpfs" ino=3281141 scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1 ---- time->Mon May 20 15:58:15 2019 type=AVC msg=audit(1558360695.098:1214): avc: denied { unlink } for pid=17342 comm="systemd-importd" name="machines.lock" dev="tmpfs" ino=3281141 scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1 ---- time->Mon May 20 15:58:15 2019 type=AVC msg=audit(1558360695.099:1216): avc: denied { execute } for pid=17438 comm="(sd-transfer)" name="systemd-pull" dev="nvme0n1p3" ino=6036858 scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:init_exec_t:s0 tclass=file permissive=1 ---- time->Mon May 20 15:58:15 2019 type=AVC msg=audit(1558360695.099:1217): avc: denied { read open } for pid=17438 comm="(sd-transfer)" path="/usr/lib/systemd/systemd-pull" dev="nvme0n1p3" ino=6036858 scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:init_exec_t:s0 tclass=file permissive=1 ---- time->Mon May 20 15:58:15 2019 type=AVC msg=audit(1558360695.099:1218): avc: denied { execute_no_trans } for pid=17438 comm="(sd-transfer)" path="/usr/lib/systemd/systemd-pull" dev="nvme0n1p3" ino=6036858 scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:init_exec_t:s0 tclass=file permissive=1 ---- time->Mon May 20 15:58:15 2019 type=AVC msg=audit(1558360695.099:1219): avc: denied { map } for pid=17438 comm="systemd-pull" path="/usr/lib/systemd/systemd-pull" dev="nvme0n1p3" ino=6036858 scontext=system_u:system_r:systemd_importd_t:s0 tcontext=system_u:object_r:init_exec_t:s0 tclass=file permissive=1 ----
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. 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 EOL if it remains open with a Fedora 'version' of '29'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 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 change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Just tried this on F30. The good news is that the pull-raw command seems to work, e.g. $ sudo machinectl pull-raw --verify=no http://mirror.bytemark.co.uk/fedora/linux//releases/31/Cloud/x86_64/images/Fedora-Cloud-Base-31-1.9.x86_64.raw.xz F31 Enqueued transfer job 1. Press C-c to continue download in background. Pulling 'http://mirror.bytemark.co.uk/fedora/linux//releases/31/Cloud/x86_64/images/Fedora-Cloud-Base-31-1.9.x86_64.raw.xz', saving as 'F31'. [...] Created new local image 'F31'. Operation completed successfully. Exiting. $ machinectl list-images NAME TYPE RO USAGE CREATED MODIFIED F31 raw no 4.0G Thu 2019-10-24 00:07:22 BST Thu 2019-10-24 00:07:22 BST 1 images listed. However removing the image fails: $ sudo machinectl remove F31 Could not remove image: Access denied AVC denial: type=AVC msg=audit(1572716141.780:792): avc: denied { create } for pid=12140 comm="(sd-imgrm)" name="inode-2052:1835115" scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=0
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Andrew Cook, please reopen this bug and assign it to current Fedora version. It's still reproducible on Fedora 32.