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(a)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(a)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.