[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:34 +0200, dragoran wrote:
> Paul Howarth wrote:
> > 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.
> >
> >
> >
> >   
> 
> root:object_r:user_home_dir_t    root should be /home and 
> system_u:object_r:home_root_t    home should be /root something weird is going on here...

I disagree. I think these are correct.

/root is the home directory for user "root" and should be
user_home_dir_t, just like any other user's home directory.

/home is the root of the "home" directory tree, where most user home
directories live, so home_root_t seems OK for that.

Perhaps it's just the names of the context types that are confusing?

Paul.



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