postfix, procmail and SELinux - No Go

Paul Howarth paul at city-fan.org
Thu Jun 1 12:00:01 UTC 2006


Marc Schwartz wrote:
> Nicolas Mailhot wrote:
>> Le mardi 30 mai 2006 à 15:58 -0500, Marc Schwartz (via MN) a écrit :
>>> <snip>
>>>
>>> Paul,
>>>
>>> Thanks for your assistance.
>>> Give me a bit of time, with everything else (ie. work) going on, to
>>> implement and test your recommendations (and to review some
>>> documentation).
>>>
>>> I'll post back as soon as I have something definitive.
>>>
>>> On your query on pyzor, much like razor and dcc, it is called as part of
>>> the spamassassin checks when present. These constitute the 'remote'
>>> checks that one can perform when using SA. This is why I find it curious
>>> that there were no avc messages for razor and dcc.
>>
>> are you sure razor and dcc are used ? Last I looked the FC version of SA
>> disabled the razor check because of licensing problems
>>
>> As for pyzor, I've reported it in the past, you need the policy to allow
>> reading its config file, then connecting to pyzor servers, etc
> 
> Nicolas,
> 
> Thanks kindly for making note of this.
> 
> In SA 3.1.x, which is new to FC5, these checks are indeed disabled. From 
> some Googling, this appears to not be unique to FC, but to SA itself.
> 
> In FC4, which used SA 3.0.x, these checks worked fine without 
> adjustments to config files. I was not aware of the change.
> 
> I have now edited:
> 
>   /etc/mail/spamassassin/v310pre
> 
> to enable the checks. I also did some fine tuning to 
> ~/.spamassassin/user.prefs to account for some setting changes as well.
> 
> Sure enough, avc messages are now being logged. I have cc'd Paul to 
> reference the additional info below:
> 
> 
> Now for grep "dcc":
> 
> type=SYSCALL msg=audit(1149104051.041:8648): arch=40000003 syscall=197 
> success=yes exit=0 a0=4 a1=bfaad188 a2=4891eff4 a3=3 items=0 pi d=25104 
> auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 
> comm="dccproc" exe="/usr/local/bin/dccproc"
> type=AVC_PATH msg=audit(1149104051.041:8648):  path="/var/dcc/map"
> type=AVC msg=audit(1149104051.041:8649): avc:  denied  { lock } for 
> pid=25104 comm="dccproc" name="map" dev=hdc5 ino=87811 scontext=s 
> ystem_u:system_r:spamd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file
> type=SYSCALL msg=audit(1149104051.041:8649): arch=40000003 syscall=221 
> success=yes exit=0 a0=4 a1=7 a2=bfaae304 a3=bfaae304 items=0 pi d=25104 
> auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 
> comm="dccproc" exe="/usr/local/bin/dccproc"
> type=AVC_PATH msg=audit(1149104051.041:8649):  path="/var/dcc/map"
> type=AVC msg=audit(1149104167.275:8694): avc:  denied  { read write } 
> for  pid=25544 comm="dccproc" name="map" dev=hdc5 ino=87811 scon 
> text=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:var_t:s0 
> tclass=file
> type=SYSCALL msg=audit(1149104167.275:8694): arch=40000003 syscall=5 
> success=yes exit=4 a0=80ba6e0 a1=2 a2=180 a3=11 items=1 pid=25544 
> auid=500 uid=500 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=500 fsgid=0 
> comm="dccproc" exe="/usr/local/bin/dccproc"
> type=CWD msg=audit(1149104167.275:8694):  cwd="/var/dcc"
> type=PATH msg=audit(1149104167.275:8694): item=0 name="/var/dcc/map" 
> flags=101  inode=87811 dev=16:05 mode=0100600 ouid=0 ogid=0 rdev= 00:00
> type=AVC msg=audit(1149104167.275:8695): avc:  denied  { getattr } for 
> pid=25544 comm="dccproc" name="map" dev=hdc5 ino=87811 scontex 
> t=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:var_t:s0 
> tclass=file
> type=SYSCALL msg=audit(1149104167.275:8695): arch=40000003 syscall=197 
> success=yes exit=0 a0=4 a1=bfbf5cc8 a2=4891eff4 a3=3 items=0 pi d=25544 
> auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 
> comm="dccproc" exe="/usr/local/bin/dccproc"
> type=AVC_PATH msg=audit(1149104167.275:8695):  path="/var/dcc/map"
> type=AVC msg=audit(1149104167.275:8696): avc:  denied  { lock } for 
> pid=25544 comm="dccproc" name="map" dev=hdc5 ino=87811 scontext=s 
> ystem_u:system_r:spamd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file
> type=SYSCALL msg=audit(1149104167.275:8696): arch=40000003 syscall=221 
> success=yes exit=0 a0=4 a1=7 a2=bfbf6e44 a3=bfbf6e44 items=0 pi d=25544 
> auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 
> comm="dccproc" exe="/usr/local/bin/dccproc"
> type=AVC_PATH msg=audit(1149104167.275:8696):  path="/var/dcc/map"

These all appear to be dccproc doing read/write/lock operations on 
/var/dcc/map. This is happening in the spamd_t domain, which seems wrong 
to me since spamd_t should transition to dcc_client_t. Check what the 
context of /usr/local/bin/dccproc is; I think it should be 
dcc_client_exec_t (and it would be if it was in /usr/bin).

Also, /var/dcc and everything under it apart from /var/dcc/map should be
dcc_var_t; /var/dcc/map should be dcc_client_map_t.

You might check out the file contexts from the dcc policy module (listed 
below) and check that everything else is labelled correctly in the 
places you have installed them:

/etc/dcc(/.*)? 
gen_context(system_u:object_r:dcc_var_t,s0)
/etc/dcc/dccifd                 -s 
gen_context(system_u:object_r:dccifd_var_run_t,s0)
/etc/dcc/map                    -- 
gen_context(system_u:object_r:dcc_client_map_t,s0)

/usr/bin/cdcc                   -- 
gen_context(system_u:object_r:cdcc_exec_t,s0)
/usr/bin/dccproc                -- 
gen_context(system_u:object_r:dcc_client_exec_t,s0)

/usr/libexec/dcc/dbclean        -- 
gen_context(system_u:object_r:dcc_dbclean_exec_t,s0)
/usr/libexec/dcc/dccd           -- 
gen_context(system_u:object_r:dccd_exec_t,s0)
/usr/libexec/dcc/dccifd         -- 
gen_context(system_u:object_r:dccifd_exec_t,s0)
/usr/libexec/dcc/dccm           -- 
gen_context(system_u:object_r:dccm_exec_t,s0)

/var/dcc(/.*)? 
gen_context(system_u:object_r:dcc_var_t,s0)
/var/dcc/map                    -- 
gen_context(system_u:object_r:dcc_client_map_t,s0)

/var/run/dcc(/.*)? 
gen_context(system_u:object_r:dcc_var_run_t,s0)
/var/run/dcc/map                -- 
gen_context(system_u:object_r:dcc_client_map_t,s0)
/var/run/dcc/dccifd             -s 
gen_context(system_u:object_r:dccifd_var_run_t,s0)

> For grep "razor":
> 
> type=AVC msg=audit(1149102177.498:8243): avc:  denied  { append } for 
> pid=20136 comm="spamd" name="razor-agent.log" dev=hdc7 ino=98923 
> scontext=system_u:system_r:spamd_t:s0 
> tcontext=system_u:object_r:default_t:s0 tclass=file

default_t file should have been relabelled by now.

Again, check out the default contexts for razor and make sure that the 
files in the locations you have installed it to have the right contexts:

ifdef(`strict_policy',`
HOME_DIR/\.razor(/.*)? 
gen_context(system_u:object_r:ROLE_razor_home_t,s0)
')

/etc/razor(/.*)? 
gen_context(system_u:object_r:razor_etc_t,s0)

/usr/bin/razor.*        -- 
gen_context(system_u:object_r:razor_exec_t,s0)

/var/lib/razor(/.*)? 
gen_context(system_u:object_r:razor_var_lib_t,s0)
/var/log/razor-agent.log -- 
gen_context(system_u:object_r:razor_log_t,s0)

Paul.




More information about the fedora-selinux-list mailing list