postfix, procmail and SELinux - No Go

[Paul Howarth]

Marc Schwartz (via MN) wrote:
> On Tue, 2006-06-20 at 16:12 +0100, Paul Howarth wrote:
>> Marc Schwartz (via MN) wrote:
>>> On Tue, 2006-06-20 at 09:37 -0400, Stephen Smalley wrote:
>>>> On Tue, 2006-06-20 at 08:26 -0500, Marc Schwartz wrote:
>>>>> Also, note that now I am getting an error when trying to install the
>>>>> myclam.pp module:
>>>>>
>>>>> # semodule -i myclam.pp
>>>>> libsepol.scope_copy_callback: myclam: Duplicate declaration in module:
>>>>> type/attribute clamscan_tmp_t
>>>>> libsemanage.semanage_link_sandbox: Link packages failed
>>>>> semodule:  Failed!
>>>>>
>>>>>
>>>>> So I presume that there is an update in the version 1.0.1 of the new
>>>>> clamav module that conflicts with the declarations in our new module?
>>>> Yes, clamscan_tmp_t is defined in the clamav module now, so your
>>>> definition can go away.  Unlike allow rules, which are just unioned
>>>> together (thus, no harm in duplicates), duplicate type declarations are
>>>> treated as an error.
>>>>
>>>>> The current myclam.te is:
>>>>>
>>>>> # cat myclam.te
>>>>> ####### myclam.te #######
>>>>> policy_module(myclam, 0.1.2)
>>>>>
>>>>> require {
>>>>>          type clamscan_t;
>>>>>          type procmail_tmp_t;
>>>>>          type postfix_local_t;
>>>>> };
>>>>>
>>>>> # temp files
>>>>> type clamscan_tmp_t;
>>>>> files_tmp_file(clamscan_tmp_t)
>>>>>
>>>>> # Allow clamscan to create and use temp files and dirs
>>>>> allow clamscan_t clamscan_tmp_t:dir create_dir_perms;
>>>>> allow clamscan_t clamscan_tmp_t:file create_file_perms;
>>>>> files_type(clamscan_tmp_t)
>>>>> files_tmp_filetrans(clamscan_t, clamscan_tmp_t, { file dir })
>>>>>
>>>>> # Allow clamscan to read and write  temp files created by procmail
>>>>> # (needed for clamassassin)
>>>>> allow clamscan_t procmail_tmp_t:file rw_file_perms;
>>>>>
>>>>> # Allow clamscan output to be piped back into the
>>>>> # postfix local delivery process
>>>>> allow clamscan_t postfix_local_t:fd use;
>>>>> allow clamscan_t postfix_local_t:fifo_file write;
>>> Thanks Stephen.
>>>
>>> So is it sufficient to simply remove the:
>>>
>>>   type clamscan_tmp_t;
>>>
>>> line and retain the rest of the content or are the other changes that
>>> should be made in light of the new clamav module?
>>>
>>> Paul, I presume that you will also want to increment the version number?
>> Try this one:
>>
>> policy_module(myclamscan, 0.2.0)
>>
>> require {
>>          type clamscan_t;
>>          type postfix_local_t;
>>          type procmail_tmp_t;
>> };
>>
>> # temp files
>> # Included in selinux-policy-2.2.43-4
>> #type clamscan_tmp_t;
>> #files_tmp_file(clamscan_tmp_t)
>>
>> # Allow clamscan to create and use temp files and dirs
>> # Included in selinux-policy-2.2.43-4
>> #allow clamscan_t clamscan_tmp_t:dir create_dir_perms;
>> #allow clamscan_t clamscan_tmp_t:file create_file_perms;
>> #files_type(clamscan_tmp_t)
>> #files_tmp_filetrans(clamscan_t, clamscan_tmp_t, { file dir })
>>
>> # Allow clamscan to read and write temp files created by procmail
>> # (needed for clamassassin)
>> allow clamscan_t procmail_tmp_t:file rw_file_perms;
>>
>> # Allow clamscan output to be piped back into the
>> # postfix local delivery process
>> allow clamscan_t postfix_local_t:fd use;
>> allow clamscan_t postfix_local_t:fifo_file write;
> 
> OK.  Done.
> 
> Also, just to confirm that you are explicitly changing the policy name
> from myclam to myclamscan?

Yes; I was helping someone else out on fedora-list and I renamed some 
things to avoid confusing myself.

>>> Also, as an FYI, this is the second time that I have experienced an RPM
>>> related error with the policies. Paul, you may recall a few weeks ago,
>>> there was a partial install of an update RPM, which was not actually
>>> loaded, but rpm reported both versions being installed. Not sure if this
>>> is unique to my system or if others may be having any issues. I have not
>>> checked Bugzilla for any reports on these.
>> This is not something I've been seeing here. Might be worth peeking 
>> through your logs for the time the update was applied to see if there 
>> was anything strange happening.
> 
> Nothing in the logs to indicate a problem. The new rpms were installed
> on June 13, with no errors noted.
> 
> 
> BTW, I am now getting the following messages with avclist, since the
> loading of the updated policies today:
> 
> type=AVC msg=audit(1150817767.142:753): avc:  denied  { getattr } for  pid=2268 comm="spamd" name="pyzor" dev=hdc7 ino=3140757 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:pyzor_exec_t:s0 tclass=file
> type=SYSCALL msg=audit(1150817767.142:753): arch=40000003 syscall=195 success=no exit=-13 a0=a22fb98 a1=92360c8 a2=4891eff4 a3=a22fb98 items=1 pid=2268 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl"type=AVC_PATH msg=audit(1150817767.142:753):  path="/usr/bin/pyzor"
> type=CWD msg=audit(1150817767.142:753):  cwd="/"
> type=PATH msg=audit(1150817767.142:753): item=0 name="/usr/bin/pyzor" flags=1  inode=3140757 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
> type=AVC msg=audit(1150817767.142:754): avc:  denied  { getattr } for  pid=2268 comm="spamd" name="pyzor" dev=hdc7 ino=3140757 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:pyzor_exec_t:s0 tclass=file
> type=SYSCALL msg=audit(1150817767.142:754): arch=40000003 syscall=195 success=no exit=-13 a0=a22fb98 a1=92360c8 a2=4891eff4 a3=a22fb98 items=1 pid=2268 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl"type=AVC_PATH msg=audit(1150817767.142:754):  path="/usr/bin/pyzor"
> type=CWD msg=audit(1150817767.142:754):  cwd="/"
> type=PATH msg=audit(1150817767.142:754): item=0 name="/usr/bin/pyzor" flags=1  inode=3140757 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00

Is pyzor working though?

Maybe these can be dontaudit-ed if that's the case.

Paul.