Description of problem: After customizing an image to contain extra packages, it is no longer possible to connect to the image due to AVC errors. Version-Release number of selected component (if applicable): libguestfs-tools-c-1.28.1-1.55.el7.centos.4.x86_64 How reproducible: 100% Steps to Reproduce: 1. wget wget http://download.eng.bos.redhat.com/brewroot/packages/rhel-guest-image/7.2/20160302.0.0/images/rhel-guest-image-7.2-20160302.0.x86_64.qcow2 2. virt-customize -a rhel-guest-image-7.2-20160302.0.x86_64.qcow2 \ --sm-credentials 'rhn_engineering_XXXX:password:mysecret' \ --sm-register --sm-attach auto \ --install "ntp" --sm-unregister 3. boot an openstack instance from this image and attach it to the network 4. ssh cloud-user@${INSTANCE_IP} Actual results: SSH connection is closed type=AVC msg=audit(1464065038.747:229): avc: denied { dyntransition } for pid=9993 comm="sshd" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:system_r:sshd_net_t:s0 tclass=process type=AVC msg=audit(1464065039.557:237): avc: denied { sigchld } for pid=9992 comm="sshd" scontext=system_u:system_r:sshd_net_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=process type=AVC msg=audit(1464065041.444:248): avc: denied { dyntransition } for pid=9995 comm="sshd" scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process Expected results: User can log in Additional info: If a password is set for the cloud-user user, then logging in from the console will also be rejected. Please advise if I'm doing this wrong. Comment from Dan: This looks like sshd is running as kernel_t, which means your machine is totally mislabeled. touch /.autorelabel; reboot [abeekhof: This doesn't seem appropriate for transient cloud instances] kernel_t is supposed to transition to init_t when running /sbin/init, and init_t is supposed to transition to sshd_t when it executes /usr/sbin/sshd. I would figure something went wrong during the install that left these machines mislabeled.
(In reply to Andrew Beekhof from comment #0) > virt-customize -a rhel-guest-image-7.2-20160302.0.x86_64.qcow2 \ > --sm-credentials 'rhn_engineering_XXXX:password:mysecret' \ > --sm-register --sm-attach auto \ > --install "ntp" > --sm-unregister I don't see --selinux-relabel among the arguments. Please use it, when customizing SELinux-enabled guests.
Ah, --selinux-relabel did indeed fix it, I've left a note on https://rwmj.wordpress.com/2015/10/03/tip-updating-rhel-7-1-cloud-images-using-virt-customize-and-subscription-manager for anyone that comes after me. Would it make sense to imply --selinux-relabel when --sm-* is in use? Do we ship any images without selinux enabled these days? Is there ever a case when you would want --sm-* and /not/ --selinux-relabel ?
(In reply to Andrew Beekhof from comment #2) > Would it make sense to imply --selinux-relabel when --sm-* is in use? > Is there ever a case when you would want --sm-* and /not/ --selinux-relabel ? There are few data points: a) determining whether SELinux is actually used is not easy, there are different places to check (/etc/selinux/config, bootloader configuration, firstboot/init scripts enabling/disabling it, etc) b) using --sm-* cannot imply you need SELinux (see also (a)) c) strictly speaking, you don't need to relabel at each virt-customize/virt-sysprep invocation, but only during the last one before actually using the guest; e.g.: $ virt-customize -a IMG --install foo etc.. [other stuff...] $ virt-customize -a IMG --edit /file etc.. [more stuff...] $ virt-customize -a IMG --selinux-relabel etc.. [boot the guest]
Closing as it isn't a bug, but a lack of appropriate SELinux option on the user side/