SELinux in mock

[Stephen Smalley]

On Tue, 2009-01-13 at 22:08 -0700, Jerry James wrote:
> Josh Boyer was kind enough to give me a login on a ppc64 machine so I
> can try to debug the issue I'm having with GCL.  Unfortunately, I
> cannot even get off the ground.  I'm using a 'mock -r
> fedora-rawhide-ppc64' command to try things out.  Inside the chroot, I
> see this:
> 
> $ mock -r fedora-rawhide-ppc64 --shell
> INFO: mock.py version 0.9.13 starting...
> State Changed: init plugins
> State Changed: start
> State Changed: lock buildroot
> mock-chroot> selinuxenabled
> mock-chroot> echo $?
> 0
> mock-chroot> /usr/sbin/semodule -i /tmp/gcl.pp
> /usr/sbin/semodule: SELinux policy is not managed or store cannot be accessed.
> 
> 
> How is that supposed to work?  This is blocking the GCL build, which
> has to change dumped images to type gcl_exec_t when SELinux is active
> (checked with selinuxenabled).  If the policy is not managed or the
> store cannot be accessed, then selinuxenabled should be setting its
> exit code to 1, should it not?  As it is, the GCL build fails when
> trying to invoke chcon because selinuxenabled is apparently lying.

selinuxenabled just tests for the presence of SELinux in the kernel by
probing for the selinuxfs filesystem (typically mounted on /selinux).

semodule is testing whether the policy store
(under /etc/selinux/$SELINUXTYPE/modules/active) exists and can be
accessed by the current process before proceeding to try to install your
module.  strace semodule -i /tmp/gcl.pp would show the precise point of
failure, but offhand I'd guess that /etc/selinux/targeted/modules/active
either does not exist or is not readable by the process.

-- 
Stephen Smalley
National Security Agency