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(a)epoch.ncsc.mil>
National Security Agency