[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: selinux prelink avc's (broken paths in policy?)



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 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 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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]