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.