selinux prelink avc's (broken paths in policy?)
Daniel J Walsh
dwalsh at redhat.com
Wed May 24 13:45:26 UTC 2006
dragoran wrote:
> 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.
>>
>>
>>
>>
>
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Yes /lib64/ld-2.4.so has the wrong context. These new sorting
algorithms are driving me nuts. I have fixed it in Rawhide, and
a new test package for fc5 is about to go out.
More information about the fedora-selinux-list
mailing list