爱华网2007年07月03日 23:29
在Redhat Enterprise Linux 4.0或Fedora Core 2 Linux以上版本的Linux中，有不少用户经常会遇到诸如apache的Permission denied，X windows打不开等等问题，抛开一些常规配置错误外，很大一部分原因是因为激活了SELinux的缘故。
When building OpenJDK sources on Fedora 6, build fails with error:
./gamma: error while loading shared libraries: ./libjvm.so: cannot restore segment prot after reloc: Permission denied
make[7]: Leaving directory `/home/openjdk/Desktop/opensource-testing/openjdk-build10-output/hotspot/outputdir/linux_i486_compiler2/product'
make[6]: Leaving directory `/home/openjdk/Desktop/opensource-testing/openjdk-build10-output/hotspot/outputdir/linux_i486_compiler2/product'
All done.
make[5]: Leaving directory `/home/openjdk/Desktop/opensource-testing/openjdk-build10-output/hotspot/outputdir/linux_i486_compiler2/product'
cd linux_i486_compiler2/product && ./test_gamma
./gamma: error while loading shared libraries: ./libjvm.so: cannot restore segment prot after reloc: Permission denied
make[4]: *** [product] Error 127
make[4]: Leaving directory `/home/openjdk/Desktop/opensource-testing/openjdk-build10-output/hotspot/outputdir'
make[3]: *** [generic_build2] Error 2
make[3]: Leaving directory `/home/openjdk/Desktop/opensource-testing/hotspot/make'
make[2]: *** [product] Error 2
make[2]: Leaving directory `/home/openjdk/Desktop/opensource-testing/hotspot/make'
make[1]: *** [hotspot-build] Error 2
make[1]: Leaving directory `/home/openjdk/Desktop/opensource-testing/control/make'
make: *** [dev-build] Error 2
Posted Date : 2007-03-23 17:54:20.0
什么是 SELinux？SELinux全称是Security Enhanced Linux，由美国国家安全部(National Security Agency)领导开发的GPL项目，它拥有一个灵活而强制性的访问控制结构，旨在提高Linux系统的安全性，提供强健的安全保证，可防御未知攻击，据 称相当于B1级的军事安全性能。比MS NT所谓的C2等高得多。应用SELinux后，可以减轻恶意攻击或恶意软件带来的灾难，并提供对机密性和完整性有很高要求的信息很高的安全保障。 SELinux vs Linux普通Linux安全和传统Unix系统一样，基于自主存取控制方法，即DAC，只要符合规定的权限，如规定的所有者和文件属性等，就可存取资 源。在传统的安全机制下，一些通过setuid/setgid的程序就产生了严重安全隐患，甚至一些错误的配置就可引发巨大的漏洞，被轻易攻击。而 SELinux则基于强制存取控制方法，即MAC，透过强制性的安全策略，应用程序或用户必须同时符合DAC及对应SELinux的MAC才能进行正常操 作，否则都将遭到拒绝或失败，而这些问题将不会影响其他正常运作的程序和应用，并保持它们的安全系统结构。SELinux on Redhat Linux在RHEL4.0或FC3以上的版本中，可以在安装时就选择是否激活SELinux，系统自动会安装相应的内核、工具、程序等。由于 SELinux的MAC机制将极大的影响了现有引用，因此RHEL4/FC3中已预配置了大量兼容现有应用的安全策略。SELinux的配置相关文件都在 /etc/selinux下，其中/etc/selinux/targeted目录里就包含了策略的详细配置和context定义，以下是主要文件及功 用：/etc/selinux/targeted/contexts/*_context 默认的context设置/etc/selinux/targeted/contexts/files/* 精确的context类型划分/etc/selinux/targeted/policy/* 策略文件使用Redhat 默认的策略对正常应用带来的影响比较小，兼容性相对比较好。对于需要提供虚拟主机或大量应用的用户而言，则会带来不小的麻烦，需要仔细阅读SELinux 的手册进行调整。其中Fedora Core 的官方网站上有相关的Apache/SELinux的策略调整文档，建议web用户仔细阅读。激活SELinux的操作系统，需要对策略和模式进行变更 时，一般不需要重启动即可获得变化，主要就是透过libselinux软件包实现。 libselinux包含了对策略的控制/管理工具，其中getsebool/setsebool是读取/设置SELinux 布尔值的工具，getenforce/setenforce则是设置强制性的工具。Why SELinux?毫无疑问：安全！如今Internet上病毒、攻击层出不穷，信息安全受到了严重威胁，而普通Linux的安全性要做得很好并不容易，且 没有一个中央化的安全体系结构，因此使用SELinux可以使用强制的访问控制来进行小颗粒度的权限控制，并提高系统的稳定性，简化了防系统崩溃的调整工 作，达到信息保密和完整性的要求。SELinux主要的改进在于：# 对内核对象和服务的访问控制# 对进程初始化、继承和程序执行的访问控制# 对文件系统、目录、文件和打开文件描述的访问控制# 对端口、信息和网络接口的访问控制。SELinux still difficult控制的东西越多使用起来就越容易复杂，SELinux也不例外，目前SELinux还在不断完善中，管理和控制策略并不是一件轻松的 事，需要丰富的系统知识和经验，并且必须仔细阅读SELinux相关的文档，做大量的尝试。
Work Around
To disable SELinux:
1)$ su root
2)# system-config-securitylevel
3)In the window that appears, select the SELinux tab
4) Disable SELinux.
Disablining SELinux is applying a rather large hammer to work around this issue. One only needs to disable this one check.
1) Select System->Administration->SELinux Management
2) In the SELinux Management Tool which appears, Select "Boolean" from the menu on the left, creatively labeled "Select:"
3) Expand the "Memory Protection" group
4) Check the first item, labeled "Allow all unconfined executables to use libraries requiring text relocation ..."
Instead of allowing all unconfined executables to use libraries requiring text relocation, you could use an even smaller hammer, the unconfined_domain java_t type for java, and customize its policy.
From Dan Walsh's blog, http://danwalsh.livejournal.com/
"There are a few unconfined domains in a targeted policy, the main reason for this is different transition rules. As was stated in previous blogs, we have started added some confinement to the unconfined_domains, in the form of executable memory checking. This has led to a few new domains. For example we may want to turn off execstack for most of the unconfined domain, but java applications by design need this access. So an unconfined_domain java_t was added to java apps with no policy defined."
Evaluation
See the comments section for more details. In summary, the problem is caused by building non-PIC library with SELinux enabled. We don't have an easy way to get around this for now. So the temporary solution is to ask people to disable SELinux temporarily if they want to build hotspot.
The FAQ page will soon contain the problem and solution.
Posted Date : 2007-03-29 17:29:02.0
The root cause of seeing this error (cannot restore segment prot after reloc) can be explained as following. When a DSO (shared object libraries) is loaded, at some point, the runtime linker determines that is needs to perform some text relocations to the DSO, so it uses mprotect call to set the mapped region to read/write. After text relocation, the code needs to be mapped back to read/exec which triggers the access check. Normally, a DSO does not need to do text relocation. However, due to the significant benefit we saw from the non-PIC version of libjvm.so, we are now compiling libjvm.so as non-PIC. To avoid this, we basically do chcon -t textrel_shlib_t libjvm.so after it is built. Certain checks to make sure SELinux is enabled are required, otherwise, chcon will fail. It turns out checking the return result of /usr/sbin/selinuxenabled command will be sufficient to see whether SELinux is enabled or not.
