selinux prelink avc's (broken paths in policy?)
Paul Howarth
paul at city-fan.org
Tue May 23 15:30:46 UTC 2006
On Tue, 2006-05-23 at 17:17 +0200, dragoran wrote:
> dragoran wrote:
> > dragoran wrote:
> >> Paul Howarth wrote:
> >>> On Tue, 2006-05-23 at 16:28 +0200, dragoran wrote:
> >>>
> >>>> dragoran wrote:
> >>>>
> >>>>> dragoran wrote:
> >>>>>
> >>>>>> audit(1147793154.831:353): avc: denied { execute_no_trans }
> >>>>>> for pid=5195 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163
> >>>>>> scontext=system_u:system_r:prelink_t:s0
> >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>> audit(1147793154.831:354): avc: denied { execute_no_trans }
> >>>>>> for pid=5196 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163
> >>>>>> scontext=system_u:system_r:prelink_t:s0
> >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>> audit(1147793155.019:355): avc: denied { execute_no_trans }
> >>>>>> for pid=5197 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163
> >>>>>> scontext=system_u:system_r:prelink_t:s0
> >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>> audit(1147793155.447:356): avc: denied { execute_no_trans }
> >>>>>> for pid=5198 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163
> >>>>>> scontext=system_u:system_r:prelink_t:s0
> >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>> audit(1147793156.255:357): avc: denied { execute_no_trans }
> >>>>>> for pid=5199 comm="prelink" name="ld-2.4.so" dev=md0 ino=8061163
> >>>>>> scontext=system_u:system_r:prelink_t:s0
> >>>>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>>>> I am using FC5 with selinux-policy-targeted-2.2.36-2.fc5
> >>>>>> whats gonig on? is a file misslabeled or is this a policy bug?
> >>>>>>
> >>>>>> --
> >>>>>> fedora-selinux-list mailing list
> >>>>>> fedora-selinux-list at redhat.com
> >>>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> hello?
> >>>>> any solution for this problem?
> >>>>>
> >>>>>
> >>>>>
> >>>> it happend again...
> >>>> am I the only one seeing this?
> >>>> audit(1148393411.538:2907): avc: denied { execute_no_trans } for
> >>>> pid=16856 comm="prelink" name="ld-2.4.so" dev=md0 ino=8060939
> >>>> scontext=system_u:system_r:prelink_t:s0
> >>>> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >>>> audit(1148393411.794:2908): avc: denied { execmod } for
> >>>> pid=16859 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" dev=md0
> >>>> ino=29797475 scontext=system_u:system_r:prelink_t:s0
> >>>> tcontext=root:object_r:lib_t:s0 tclass=file
> >>>> audit(1148393411.814:2909): avc: denied { execmod } for
> >>>> pid=16860 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.8762"
> >>>> dev=md0 ino=30869146 scontext=system_u:system_r:prelink_t:s0
> >>>> tcontext=root:object_r:lib_t:s0 tclass=file
> >>>> audit(1148393412.438:2910): avc: denied { unlink } for pid=13702
> >>>> comm="prelink" name="prelink.cache" dev=md0 ino=7012828
> >>>> scontext=system_u:system_r:prelink_t:s0
> >>>> tcontext=user_u:object_r:etc_t:s0 tclass=file
> >>>> prelink seems to be completly broken and nobody seems to notice it?
> >>>>
> >>>
> >>> I'm not seeing this anywhere.
> >>>
> >>> Perhaps it's because /lib/ld-2.4.so is lib_t rather than ld_so_t on
> >>> your
> >>> system?
> >>>
> >>> Paul.
> >>>
> >>>
> >>>
> >>>
> >> ls -Z /lib/ld-2.4.so
> >> -rwxr-xr-x root root system_u:object_r:ld_so_t
> >> /lib/ld-2.4.so
> >> ls -Z /lib64/ld-2.4.so
> >> -rwxr-xr-x root root system_u:object_r:lib_t
> >> seems that you are correct lets hope that this wont happen again.
> >>
> >> --
> >> fedora-selinux-list mailing list
> >> fedora-selinux-list at redhat.com
> >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>
> >>
> > this *is* a bug
> > restorecon /lib64/ld-2.4.so
> > does not change it to ld_so_t (had to do a chcon)
> >
> >
> >
>
> I did a complete relabel and the result is
> ls -Z /lib64/ld-2.4.so
> -rwxr-xr-x root root system_u:object_r:lib_t
> /lib64/ld-2.4.so
The context line that *should* match this appears to be:
/lib(64)?(/.*)?/ld-[^/]*\.so(\.[^/]*)* regular file
system_u:object_r:ld_so_t:s0
But this appears to be overruled by one of these:
/lib(/.*)? all files
system_u:object_r:lib_t:s0
/lib64(/.*)? all files
system_u:object_r:lib_t:s0
I'm not sure what it is that decides which is the best match. The top
one is longer and appears to me to be more specific, but it does have
more wildcards in it...
> I also noticed this:
> drwxr-xr-x root root system_u:object_r:bin_t bin
> drwxr-xr-x root root system_u:object_r:boot_t boot
> drwxr-xr-x root root system_u:object_r:device_t dev
> drwxr-xr-x root root system_u:object_r:etc_t etc
> drwxr-xr-x root root system_u:object_r:home_root_t home
> drwxr-xr-x root root system_u:object_r:lib_t lib
> drwxr-xr-x root root system_u:object_r:lib_t lib64
> drwx------ root root system_u:object_r:lost_found_t lost+found
> drwxr-xr-x root root system_u:object_r:mnt_t media
> drwxr-xr-x root root system_u:object_r:mnt_t misc
> drwxr-xr-x root root system_u:object_r:mnt_t mnt
> dr-xr-xr-x root root system_u:object_r:mnt_t net
> drwxr-xr-x root root system_u:object_r:usr_t opt
> dr-xr-xr-x root root system_u:object_r:proc_t proc
> drwxr-x--- root root root:object_r:user_home_dir_t root
> drwxr-xr-x root root system_u:object_r:sbin_t sbin
> drwxr-xr-x root root system_u:object_r:security_t selinux
> drwxr-xr-x root root system_u:object_r:var_t srv
> drwxr-xr-x root root system_u:object_r:sysfs_t sys
> drwxrwxrwt root root system_u:object_r:tmp_t tmp
> drwxr-xr-x root root system_u:object_r:usr_t usr
> drwxr-xr-x root root system_u:object_r:var_t var
> looks incorrect too whats going on here?
Looks like mine. What do you think is wrong with this? Nothing stands
out to me.
Paul.
More information about the fedora-selinux-list
mailing list