I'm having problems with the prelink command on my system running the
latest FC3/strict/1.23.11-1 policy.
Running in enforcing mode, when I run 'prelink -a' after updating glibc,
I get a single "avc: denied { relabelto }" error message and prelink
bails out. Running tripwire immediately before and after the prelink
command show no changes to any files on the system.
Running the same scenario in permissive mode, I get a series of 100 or
more relabelto denied error messages. The tripwire runs show over 1000
modified files, which is par for the course after updating glibc.
Here's one of the error messages in full:
Apr 15 10:36:08 starfury kernel: audit(1113575768.487:0): avc:
denied { relabelto } for pid=22291 exe=/usr/sbin/prelink
name=refer.#prelink#.SULAFf dev=dm-0 ino=13717061
scontext=root:system_r:prelink_t tcontext=system_u:object_r:bin_t
tclass=file
As far as I can tell from looking at the policy sources, I shouldn't be
getting any of these errors. There is a (long) line in prelink.te that
explicitly allows relabelto. Wrapped for clarity, it is:
allow prelink_t {
ifdef(`amanda.te', `amanda_usr_lib_t')
admin_passwd_exec_t
ifdef(`apache.te', `httpd_modules_t')
ifdef(`xserver.te', `xkb_var_lib_t')
ld_so_t su_exec_t texrel_shlib_t
shlib_t sbin_t bin_t lib_t exec_type
}:file { create_file_perms execute relabelto relabelfrom };
This line explicitly allows prelink the relabelto permission for bin_t
files, which is what the avc message I copied is complaining about.
I've spot checked some of the other 100 error messages. The majority of
them have a target context of xxx_exec_t and the declaration of the
xxx_exec_t type includes the exec_type attribute, which means the
operation should be allowed based on the policy line above.
Any suggestions on where to go from here to track down this problem?
David
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-selinux-list
