On 08/23/2010 10:47 AM, Arthur Dent wrote:
On Mon, 2010-08-23 at 10:42 +0200, Dominick Grift wrote:
> On 08/23/2010 10:40 AM, Arthur Dent wrote:
>> On Mon, 2010-08-23 at 10:29 +0200, Dominick Grift wrote:
>>> On 08/23/2010 10:09 AM, Arthur Dent wrote:
>>>> On Sun, 2010-08-22 at 22:44 +0100, Arthur Dent wrote:
>>>>> On Sun, 2010-08-22 at 23:07 +0200, Dominick Grift wrote:
>>>>>> On 08/22/2010 08:24 PM, Arthur Dent wrote:
>>>>> ----
>>>> time->Mon Aug 23 08:57:07 2010
>>>> type=SYSCALL msg=audit(1282550227.058:42734): arch=40000003 syscall=102
success=no exit=-13 a0=3 a1=bf800420 a2=3 a3=1 items=0 ppid=23912 pid=23920
auid=4294967295 uid=0 gid=12 euid=0 suid=0 fsuid=0 egid=12 sgid=12 fsgid=12 tty=(none)
ses=4294967295 comm="clamdscan" exe="/usr/local/bin/clamdscan"
subj=system_u:system_r:procmail_t:s0 key=(null)
>>>> type=AVC msg=audit(1282550227.058:42734): avc: denied { search } for
pid=23920 comm="clamdscan" name="clamd" dev=sda6 ino=269280
scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamd_var_run_t:s0
tclass=dir
>>>
>>> This is still an issue:
>>>
>>> some process running in the procmail_t domain is running
>>> /usr/bin/clamdscan (ls -alZ /usr/bin/clamdscan to verify its context),
>>> but it is not domain transitioning to the clamscan_t domain.
>>
>> # which clamdscan
>> /usr/local/bin/clamdscan
>>
>> # ls -laZ /usr/local/bin/clamdscan
>> -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/local/bin/clamdscan
>>
>> Now, in actual fact, procmail does not call clamdscan directly (it can't
>> deal with emails), it calls a program called clamassassin which in turn
>> calls clamdscan.
>>
>> # ls -laZ /usr/local/bin/clamassassin
>> -r-xr-xr-x. root root system_u:object_r:bin_t:s0
/usr/local/bin/clamassassin
>>
>
> Why are these files located there and not /usr/bin where they are
> expected to be? The files are mislabelled.
In both cases I compiled from source and accepted the defaults
in ./configure.
I guess I could try to recompile them in /usr/bin if it is a problem -
but I'm no expert...
The problem there is; who knows what other locations owned by these apps
differ from the expected locations.
Why are you not using redhat supplied packages?
As for clamdscan; for now you could try the following to see if it would
work if this file is labelled correctly:
chcon -t clamscan_exec_t /usr/local/bin/clamdscan
See if that makes things work for you
>
>
>>>
>>> Policy defines that if a process running in the procmail_t domain runs a
>>> file labelled clamscan_exec_t, that procmail_t will domain transition to
>>> clamscan_t domain.
>>>
>>> This did not happen on your config.
>>>
>>> Either your clamdscan executable file is mislabelled or you are missing
>>> a domain transition rule.
>>>
>>> Where is your "clamdscan" executable file located, and what is it
labelled?
>>
>> see above.
>>
>>> What does the following return:
>>>
>>> sesearch -SC --allow -s procmail_t -t clamscan_t -c process
>>> sesearch -SC --allow -s procmail_t -t clamscan_exec_t -f file
>>
>> # sesearch -SC --allow -s procmail_t -t clamscan_t -c process
>> Found 1 semantic av rules:
>> allow procmail_t clamscan_t : process transition ;
>>
>> # sesearch -SC --allow -s procmail_t -t clamscan_exec_t -f file
>> sesearch: invalid option -- 'f'
>> Usage: sesearch [OPTIONS] RULE_TYPE [RULE_TYPE ...] [EXPESSION]
>> [POLICY ...]
>>
>> Try sesearch --help for more help.
>>
>>
>>
>>
>>
>>
>>
>> --
>> selinux mailing list
>> selinux(a)lists.fedoraproject.org
>>
https://admin.fedoraproject.org/mailman/listinfo/selinux
>
>
> --
> selinux mailing list
> selinux(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/selinux
>
>
> --
> selinux mailing list
> selinux(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/selinux