labelling issues

[Stephen Smalley]

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 at 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 at 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 at 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 at epoch.ncsc.mil>
National Security Agency