Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 438362 - =app-emulation/xen-tools-4.1.1-r6: build failure with SELinux enforcing
Summary: =app-emulation/xen-tools-4.1.1-r6: build failure with SELinux enforcing
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: SELinux (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Sven Vermeulen (RETIRED)
Whiteboard: sec-policy r6
Depends on:
Reported: 2012-10-14 18:19 UTC by Alex Brandt (RETIRED)
Modified: 2012-12-13 10:13 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

emerge --info '=app-emulation/xen-tools-4.1.1-r6' (file_438362.txt,4.74 KB, text/plain)
2012-10-14 18:22 UTC, Alex Brandt (RETIRED)
emerge -pqv '=app-emulation/xen-tools-4.1.1-r6' (file_438362.txt,153 bytes, text/plain)
2012-10-14 18:23 UTC, Alex Brandt (RETIRED)
Build Log (file_438362.txt,5.03 KB, text/plain)
2012-10-14 18:24 UTC, Alex Brandt (RETIRED)

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Brandt (RETIRED) gentoo-dev 2012-10-14 18:19:57 UTC
When building xen-tools-4.1.1-r6 while in enforcing mode the build fails during the configure phase with the following:

Checking check_zlib_lib: ./ line 52: /sbin/ldconfig: Operation not permitted

Reproducible: Always

Steps to Reproduce:
1. Setup SELinux in enforcing mode
2. emerge xen-tools
3. build failure
Actual Results:  
Checking check_crypto_lib: ./ line 52: /sbin/ldconfig: Operation not permitted

 *** check_crypto_lib FAILED: missing
Checking check_curl: unused, OK
Checking check_openssl_devel: OK
Checking check_python: OK
Checking check_python_devel: OK
Checking check_uuid_devel: OK
Checking check_xgettext: OK
Checking check_xml2: unused, OK
Checking check_zlib_devel: OK
Checking check_zlib_lib: ./ line 52: /sbin/ldconfig: Operation not permitted

 *** check_zlib_lib FAILED: can't find zlib

Expected Results:  
Successful build of xen-tools.

The following avcs correlate with the above errors:

type=AVC msg=audit(1350238357.866:652): avc:  denied  { read write } for  pid=15133 comm="ldconfig" path="/var/lib/portage/config" dev="xvda1" ino=532836 ipaddr= scontext=alunduil_u:sysadm_r:ldconfig_t tcontext=system_u:object_r:portage_cache_t tclass=file
type=AVC msg=audit(1350238453.603:653): avc:  denied  { ptrace } for  pid=15910 comm="check_crypto_li" ipaddr= scontext=alunduil_u:sysadm_r:portage_sandbox_t tcontext=alunduil_u:sysadm_r:ldconfig_t tclass=process
type=AVC msg=audit(1350238454.070:654): avc:  denied  { ptrace } for  pid=15941 comm="check_zlib_lib" ipaddr= scontext=alunduil_u:sysadm_r:portage_sandbox_t tcontext=alunduil_u:sysadm_r:ldconfig_t tclass=process
Comment 1 Alex Brandt (RETIRED) gentoo-dev 2012-10-14 18:22:52 UTC
Created attachment 326544 [details]
emerge --info '=app-emulation/xen-tools-4.1.1-r6'
Comment 2 Alex Brandt (RETIRED) gentoo-dev 2012-10-14 18:23:36 UTC
Created attachment 326546 [details]
emerge -pqv '=app-emulation/xen-tools-4.1.1-r6'
Comment 3 Alex Brandt (RETIRED) gentoo-dev 2012-10-14 18:24:15 UTC
Created attachment 326548 [details]
Build Log
Comment 4 Sven Vermeulen (RETIRED) gentoo-dev 2012-10-19 08:27:12 UTC
I initially wanted to mark the config file itself ldconfig_cache_t, but that's not the purpose of the file. I might allow ldconfig_t to rw on portage_cache_t, but I'm not sure this'll resolve things.

Can you first try
allow ldconfig_t portage_cache_t:file rw_file_perms;
and see if that helps?
Comment 5 Alex Brandt (RETIRED) gentoo-dev 2012-10-19 14:39:50 UTC
Adding that policy doesn't change the visible behavior of the configure script.  I still get the same errors during configure.
Comment 6 Sven Vermeulen (RETIRED) gentoo-dev 2012-10-19 19:26:16 UTC
Looks like the following works:

allow portage_sandbox_t ldconfig_t:process ptrace;

Since portage_sandbox_t also has ptrace abilities on its own domain, I gather it is a portage requirement all along, we just haven't found a previous case for the (single) domain transition towards ldconfig_t (portage_sandbox_t isn't allowed to transition to any other domain otherwise).

I'll probably need to introduce a libs_ptrace_ldconfig interface so that we can libs_ptrace_ldconfig(portage_sandbox_t).

However, I might want to test out not supporting a domain transition for ldconfig after all from within portage_sandbox_t and see how that goes. I don't know why it was introduced earlier. The only comment in the file sais "this violates the idea of sandbox, but regular sandbox allows it".
Comment 7 Alex Brandt (RETIRED) gentoo-dev 2012-10-20 00:06:09 UTC
I've verified that your recent policy (shown in [1]) does work and xen-tools builds correctly.

[1] allow portage_sandbox_t ldconfig_t:process ptrace;

As far as going against the sandbox ideal, I would agree but I wonder if this stems from autotools using ptrace to analyse symbols during runtime rather than trusting the symbols provided (during configure of course).  If this is the case then it seems like we should find the most restricted way for them to be ptraced without reducing this functionality.

On the other hand, I understood (and correct me if I'm mistaken) sandbox to restrict writes to the system at large but not the reading of that system.  Thus this wouldn't necessarily come down to a sandbox philosophy but would be a security policy of allowing ptrace (a scary prospect if exploited) for this particular use.

Let me know if I'm just spouting nothings again.  Thanks for the work on finding this one Sven.
Comment 8 Sven Vermeulen (RETIRED) gentoo-dev 2012-10-28 18:04:16 UTC
From the first looks of it, it seems that our compile dmoains don't need a transition towards ldconfig_t, regular execute rights suffice (and also fix this issue). I'll persue that track.

Will be in r6.
Comment 9 Sven Vermeulen (RETIRED) gentoo-dev 2012-11-03 17:38:10 UTC
In hardened-dev, r6 release
Comment 10 Sven Vermeulen (RETIRED) gentoo-dev 2012-11-18 15:27:10 UTC
In main tree, ~arch'ed
Comment 11 Sven Vermeulen (RETIRED) gentoo-dev 2012-12-13 10:13:27 UTC
r8 is now stable