On Wed, 2005-01-12 at 04:44, Joe Orton wrote: > I notice there are two different types of errors being reported here, is > that significant? The first is an open() failure: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140706 > Starting httpd: /usr/sbin/httpd: error while loading shared libraries: > libpcre.so.0: cannot open shared object file: Permission denied > > the second is, I presume, an mmap() failure, which means the open() must > have succeeded: > > http://bugs.php.net/bug.php?id=30952 > Cannot load /usr/lib/httpd/modules/libphp5.so into server: libpng.so.3: > failed to map segment from shared object: Permission denied > [FAILED] > > I've just got the second type of error happening on one of my FC3 test > boxes: > > [root@pepsi ~]# service httpd start > Starting httpd: /usr/sbin/httpd: error while loading shared libraries: > librt.so.1: failed to map segment from shared object: Permission denied > [FAILED] > [root@pepsi ~]# dmesg | tail -1 > audit(1105522884.846:0): avc: denied { execute } for pid=10455 > path=/lib/tls/librt-2.3.4.so dev=hda2 ino=3480245 > scontext=root:system_r:httpd_t tcontext=system_u:object_r:lib_t > tclass=file > [root@pepsi ~]# ls -lZ /lib/tls/librt-2.3.4.so > -rwxr-xr-x root root system_u:object_r:lib_t > /lib/tls/librt-2.3.4.so > > which appears to be the correct labelling, no? The box has the current > updates installed, there are no SELinux-related errors in prelink.log. Shared objects are supposed to have shlib_t, not lib_t. The open(2) denial is likely due to a lack of file read permission to lib_t, whereas the mmap(2) denial is likely due to a lack of file execute permission to lib_t. Suggestion for Russell/Dan/Colin/Jim to consider: What if we coalesced lib_t and shlib_t, e.g. made shlib_t a typealias for lib_t rather than a separate type? Then, the default inherit-from-parent-directory labeling would be adequate for preserving the type on shared objects. The downside is that this makes everything under lib directories executable, unless prohibited by DAC, and is a move away from what we ultimately want in a very strict policy (i.e. finer-grained shared object types so that we can bind specific trusted programs to only execute specific shared objects). Possibly only a change for targeted policy. Thoughts? -- Stephen Smalley <sds@xxxxxxxxxxxxxx> National Security Agency
