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

dragoran dragoran at feuerpokemon.de
Tue May 23 16:08:26 UTC 2006


Paul Howarth wrote:
> 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 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.
>>>
>>>
>>>
>>>   
>>>       
>> 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.
>
>   
thx got it
> Perhaps it's just the names of the context types that are confusing?
>   
yes
> Paul.
>
>
>
>   





More information about the fedora-selinux-list mailing list