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@xxxxxxxxxxxxxxxxxxxxxxx
>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>>
>>
>> --
>> selinux mailing list
>> selinux@xxxxxxxxxxxxxxxxxxxxxxx
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>>
>>
>> --
>> selinux mailing list
>> selinux@xxxxxxxxxxxxxxxxxxxxxxx
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
Attachment:
signature.asc
Description: OpenPGP digital signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
