I've seen a few issues where file labels are getting lost:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140706 http://bugs.php.net/bug.php?id=30952
and another one reported to the httpd users' list. Is there a known cause of these problems? Is it prelink related, possibly?
Regards,
joe
On Fri, 2004-12-03 at 03:03, Joe Orton wrote:
I've seen a few issues where file labels are getting lost:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140706 http://bugs.php.net/bug.php?id=30952
and another one reported to the httpd users' list. Is there a known cause of these problems? Is it prelink related, possibly?
I've seen prior reports suggesting that it is prelink-related, but no hard evidence. On the other hand, I just checked my FC3 systems (all strict policy) and they don't have any mislabeled shared objects. While they have been getting regular updates via yum and the prelink cron job is present, I see that prelink has been getting denials because of the /etc/ld.so.cache mislabeling problem (problem in rpm, not sure if a fixed rpm has found its way into FC3 or not). So possibly if prelink wasn't encountering those denials on ld.so.cache, it would gone on to complete its processing and would have left the shared objects with the wrong label. I'll restorecon /etc/ld.so.cache again and see if the problem manifests upon the next prelink run.
On Fri, 2004-12-03 at 08:36, Stephen Smalley wrote:
I've seen prior reports suggesting that it is prelink-related, but no hard evidence. On the other hand, I just checked my FC3 systems (all strict policy) and they don't have any mislabeled shared objects. While they have been getting regular updates via yum and the prelink cron job is present, I see that prelink has been getting denials because of the /etc/ld.so.cache mislabeling problem (problem in rpm, not sure if a fixed rpm has found its way into FC3 or not). So possibly if prelink wasn't encountering those denials on ld.so.cache, it would gone on to complete its processing and would have left the shared objects with the wrong label. I'll restorecon /etc/ld.so.cache again and see if the problem manifests upon the next prelink run.
BTW, ask people who encounter the mislabeled shared objects to check their /var/log/prelink.log for errors, particularly "Could not get security context" or "Could not set security context", as prelink is supposed to log those errors when it cannot get or set the file context.
On Fri, Dec 03, 2004 at 08:42:18AM -0500, Stephen Smalley wrote:
BTW, ask people who encounter the mislabeled shared objects to check their /var/log/prelink.log for errors, particularly "Could not get security context" or "Could not set security context", as prelink is supposed to log those errors when it cannot get or set the file context.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142319
is that any use?
joe
On Wed, 2004-12-08 at 18:27, Joe Orton wrote:
On Fri, Dec 03, 2004 at 08:42:18AM -0500, Stephen Smalley wrote:
BTW, ask people who encounter the mislabeled shared objects to check their /var/log/prelink.log for errors, particularly "Could not get security context" or "Could not set security context", as prelink is supposed to log those errors when it cannot get or set the file context.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142319
is that any use?
The 'ls' output indicates that the libpcre shared object is labeled correctly, so I wonder if he had already relabeled it via fixfiles or restorecon prior to running that ls.
The prelink.log file does include some 'Could not get security context" errors (with errno ENODATA), which is interesting, but peculiar that there is no such error for the libpcre shared object, since that is the one that is triggering this denial. The lack of any context on those files is very odd unless he ran with SELinux disabled for a while (in which case the files would indeed end up with no context if they were updated while SELinux was disabled and he failed to relabel when he re-enabled SELinux).
On Thu, 2004-12-09 at 08:19, Stephen Smalley wrote:
The 'ls' output indicates that the libpcre shared object is labeled correctly, so I wonder if he had already relabeled it via fixfiles or restorecon prior to running that ls.
The prelink.log file does include some 'Could not get security context" errors (with errno ENODATA), which is interesting, but peculiar that there is no such error for the libpcre shared object, since that is the one that is triggering this denial. The lack of any context on those files is very odd unless he ran with SELinux disabled for a while (in which case the files would indeed end up with no context if they were updated while SELinux was disabled and he failed to relabel when he re-enabled SELinux).
Note: I added a comment to the bugzilla entry with this information and also asked the bug reporter several follow-up questions.
On Thu, Dec 09, 2004 at 08:26:34AM -0500, Stephen Smalley wrote:
On Thu, 2004-12-09 at 08:19, Stephen Smalley wrote:
The 'ls' output indicates that the libpcre shared object is labeled correctly, so I wonder if he had already relabeled it via fixfiles or restorecon prior to running that ls.
The prelink.log file does include some 'Could not get security context" errors (with errno ENODATA), which is interesting, but peculiar that there is no such error for the libpcre shared object, since that is the one that is triggering this denial. The lack of any context on those files is very odd unless he ran with SELinux disabled for a while (in which case the files would indeed end up with no context if they were updated while SELinux was disabled and he failed to relabel when he re-enabled SELinux).
Note: I added a comment to the bugzilla entry with this information and also asked the bug reporter several follow-up questions.
Thanks Stephen. If you'd rather I just CC you immediately the next time this is reported, or if you have some new questions I should be asking people, then just let me know.
joe
On Thu, 2004-12-09 at 11:14, Joe Orton wrote:
Thanks Stephen. If you'd rather I just CC you immediately the next time this is reported, or if you have some new questions I should be asking people, then just let me know.
We should ask people who encounter this behavior if they have ever run with SELinux disabled and then re-enabled SELinux without running fixfiles relabel, as the files may become unlabeled while running with SELinux disabled if they are updated or prelinked during that time.
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.
joe
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.
No they should be shlib_t.
You need to restorecon.
joe
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
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 wrote:
On Fri, 2004-12-03 at 03:03, Joe Orton wrote:
I've seen a few issues where file labels are getting lost:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140706 http://bugs.php.net/bug.php?id=30952
and another one reported to the httpd users' list. Is there a known cause of these problems? Is it prelink related, possibly?
I've seen prior reports suggesting that it is prelink-related, but no hard evidence. On the other hand, I just checked my FC3 systems (all strict policy) and they don't have any mislabeled shared objects. While they have been getting regular updates via yum and the prelink cron job is present, I see that prelink has been getting denials because of the /etc/ld.so.cache mislabeling problem (problem in rpm, not sure if a fixed rpm has found its way into FC3 or not). So possibly if prelink wasn't encountering those denials on ld.so.cache, it would gone on to complete its processing and would have left the shared objects with the wrong label. I'll restorecon /etc/ld.so.cache again and see if the problem manifests upon the next prelink run.
The new RPM is in FC3. We have also seen this problem, but have not been able to find the cause. We believe it is either prelink or rpm related.
Dan
selinux@lists.fedoraproject.org