| Summary: | =app-emulation/xen-tools-4.1.1-r6: build failure with SELinux enforcing | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alex Brandt (RETIRED) <alunduil> |
| Component: | SELinux | Assignee: | Sven Vermeulen (RETIRED) <swift> |
| Status: | VERIFIED FIXED | ||
| Severity: | normal | CC: | selinux |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | sec-policy r6 | ||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
emerge --info '=app-emulation/xen-tools-4.1.1-r6'
emerge -pqv '=app-emulation/xen-tools-4.1.1-r6' Build Log |
||
Created attachment 326544 [details]
emerge --info '=app-emulation/xen-tools-4.1.1-r6'
Created attachment 326546 [details]
emerge -pqv '=app-emulation/xen-tools-4.1.1-r6'
Created attachment 326548 [details]
Build Log
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? Adding that policy doesn't change the visible behavior of the configure script. I still get the same errors during configure. 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". 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. 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. In hardened-dev, r6 release In main tree, ~arch'ed r8 is now stable |
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: ./funcs.sh: 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: ./funcs.sh: line 52: /sbin/ldconfig: Operation not permitted *** check_crypto_lib FAILED: missing libcrypto.so 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: ./funcs.sh: 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=72.191.11.121 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=72.191.11.121 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=72.191.11.121 scontext=alunduil_u:sysadm_r:portage_sandbox_t tcontext=alunduil_u:sysadm_r:ldconfig_t tclass=process