postfix, procmail and SELinux - No Go
Paul Howarth
paul at city-fan.org
Thu Jun 22 13:10:00 UTC 2006
Marc Schwartz (via MN) wrote:
> On Wed, 2006-06-21 at 13:57 -0500, Marc Schwartz (via MN) wrote:
>> > Just to be clear, I should leave or remove the mydcc policy?
>
> Paul,
>
> I am getting errors when building the dcc and razor policies:
>
> dcc.if:23: duplicate definition of dcc_domtrans_cdcc(). Original definition on 23.
> dcc.if:54: duplicate definition of dcc_run_cdcc(). Original definition on 54.
> dcc.if:76: duplicate definition of dcc_domtrans_client(). Original definition on 76.
> dcc.if:107: duplicate definition of dcc_run_client(). Original definition on 107.
> dcc.if:129: duplicate definition of dcc_domtrans_dbclean(). Original definition on 129.
> dcc.if:160: duplicate definition of dcc_run_dbclean(). Original definition on 160.
> dcc.if:181: duplicate definition of dcc_stream_connect_dccifd(). Original definition on 181.
> razor.if:101: duplicate definition of razor_common_domain_template(). Original definition on 101.
> razor.if:197: duplicate definition of razor_per_userdomain_template(). Original definition on 197.
> razor.if:218: duplicate definition of razor_domtrans(). Original definition on 218.
>
> The modules do seem to build and install however.
>
> I do believe that I answered my own question above, in that the dcc
> policy will not load with the mydcc policy loaded.
>
> Current status:
>
> # semodule -l
> amavis 1.0.4
> clamav 1.0.1
> dcc 1.0.0
> myclamscan 0.2.0
> mypyzor 0.2.1
> procmail 0.5.3
> pyzor 1.0.1
> razor 1.0.0
I suspect that the current FC5 policy includes these interfaces but not
the policy modules or file contexts. Can anyone confirm this?
Renaming/removing the .if files makes these warnings go away anyway.
> On Wed, 2006-06-21 at 14:56 -0500, Marc Schwartz (via MN) wrote:
>> Just a quick note that so far, all seems to be well.
>>
>> No avclist msgs since the change in policies to the above.
>>
>> Want me back in Enforcing mode?
>
> Hold the presses. Now getting avc's:
>
> type=AVC msg=audit(1150920365.865:1776): avc: denied { execute } for pid=4583 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=AVC msg=audit(1150920365.865:1776): avc: denied { execute_no_trans } for pid=4583 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=AVC msg=audit(1150920365.865:1776): avc: denied { read } for pid=4583 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
This is spamassassin failing to transition to the pyzor_t domain. The
strange thing is is that this should already be allowed by policy.
spamassassin.te has:
optional_policy(`
pyzor_domtrans(spamd_t)
')
Anyone got any ideas why this isn't working?
> type=AVC msg=audit(1150920370.874:1778): avc: denied { create } for pid=4787 comm="dccproc" scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:system_r:spamd_t:s0 tclass=netlink_route_socket
> type=SYSCALL msg=audit(1150920370.874:1778): arch=40000003 syscall=102 success=yes exit=3 a0=1 a1=bfea63f8 a2=4891eff4 a3=8069fbf items=0 pid=4787 auid=4294967295 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc"
> type=SOCKETCALL msg=audit(1150920370.874:1778): nargs=3 a0=10 a1=3 a2=0
This is dcc running in the spamd_t domain. We need to add a transition
to dcc_client_t.
> type=AVC msg=audit(1150920370.874:1779): avc: denied { bind } for pid=4787 comm="dccproc" scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:system_r:spamd_t:s0 tclass=netlink_route_socket
> type=SYSCALL msg=audit(1150920370.874:1779): arch=40000003 syscall=102 success=yes exit=0 a0=2 a1=bfea63f8 a2=4891eff4 a3=3 items=0 pid=4787 auid=4294967295 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc"
> type=SOCKADDR msg=audit(1150920370.874:1779): saddr=100000000000000000000000
> type=SOCKETCALL msg=audit(1150920370.874:1779): nargs=3 a0=3 a1=bfea6404 a2=c
> type=AVC msg=audit(1150920370.874:1780): avc: denied { getattr } for pid=4787 comm="dccproc" scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:system_r:spamd_t:s0 tclass=netlink_route_socket
> type=SYSCALL msg=audit(1150920370.874:1780): arch=40000003 syscall=102 success=yes exit=0 a0=6 a1=bfea63f8 a2=4891eff4 a3=3 items=0 pid=4787 auid=4294967295 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc"
> type=SOCKETCALL msg=audit(1150920370.874:1780): nargs=3 a0=3 a1=bfea6404 a2=bfea6410
> type=AVC msg=audit(1150920370.874:1781): avc: denied { write } for pid=4787 comm="dccproc" scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:system_r:spamd_t:s0 tclass=netlink_route_socket
> type=AVC msg=audit(1150920370.874:1781): avc: denied { nlmsg_read } for pid=4787 comm="dccproc" scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:system_r:spamd_t:s0 tclass=netlink_route_socket
> type=SYSCALL msg=audit(1150920370.874:1781): arch=40000003 syscall=102 success=yes exit=20 a0=b a1=bfea5344 a2=4891eff4 a3=ffffffcc items=0 pid=4787 auid=4294967295 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc"
> type=SOCKADDR msg=audit(1150920370.874:1781): saddr=100000000000000000000000
> type=SOCKETCALL msg=audit(1150920370.874:1781): nargs=6 a0=3 a1=bfea63bc a2=14 a3=0 a4=bfea63d0 a5=c
> type=AVC msg=audit(1150920370.874:1782): avc: denied { read } for pid=4787 comm="dccproc" scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:system_r:spamd_t:s0 tclass=netlink_route_socket
> type=SYSCALL msg=audit(1150920370.874:1782): arch=40000003 syscall=102 success=yes exit=128 a0=11 a1=bfea5344 a2=4891eff4 a3=ffffffcc items=0 pid=4787 auid=4294967295 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc"
> type=SOCKETCALL msg=audit(1150920370.874:1782): nargs=3 a0=3 a1=bfea63a0 a2=0
> type=AVC msg=audit(1150920370.874:1783): avc: denied { search } for pid=4787 comm="dccproc" name="dcc" dev=dm-1 ino=58510 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_var_t:s0 tclass=dir
> type=SYSCALL msg=audit(1150920370.874:1783): arch=40000003 syscall=12 success=yes exit=0 a0=bfea5562 a1=0 a2=4891eff4 a3=8069fbf items=1 pid=4787 auid=4294967295 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc"
> type=CWD msg=audit(1150920370.874:1783): cwd="/"
> type=PATH msg=audit(1150920370.874:1783): item=0 name="/var/dcc" flags=3 inode=58510 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00
> type=AVC msg=audit(1150920370.878:1784): avc: denied { read write } for pid=4787 comm="dccproc" name="map" dev=dm-1 ino=59007 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_map_t:s0 tclass=file
> type=SYSCALL msg=audit(1150920370.878:1784): arch=40000003 syscall=5 success=yes exit=3 a0=80ba6e0 a1=2 a2=180 a3=8069fbf items=1 pid=4787 auid=4294967295 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(1150920370.878:1784): cwd="/var/dcc"
> type=PATH msg=audit(1150920370.878:1784): item=0 name="/var/dcc/map" flags=101 inode=59007 dev=fd:01 mode=0100600 ouid=0 ogid=0 rdev=00:00
> type=AVC msg=audit(1150920370.878:1785): avc: denied { getattr } for pid=4787 comm="dccproc" name="map" dev=dm-1 ino=59007 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_map_t:s0 tclass=file
> type=SYSCALL msg=audit(1150920370.878:1785): arch=40000003 syscall=197 success=yes exit=0 a0=3 a1=bfea5378 a2=4891eff4 a3=3 items=0 pid=4787 auid=4294967295 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(1150920370.878:1785): path="/var/dcc/map"
> type=AVC msg=audit(1150920370.878:1786): avc: denied { lock } for pid=4787 comm="dccproc" name="map" dev=dm-1 ino=59007 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_map_t:s0 tclass=file
> type=SYSCALL msg=audit(1150920370.878:1786): arch=40000003 syscall=221 success=yes exit=0 a0=3 a1=7 a2=bfea64f4 a3=bfea64f4 items=0 pid=4787 auid=4294967295 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(1150920370.878:1786): path="/var/dcc/map"
All of these are the dcc client running in the wrong domain.
> It would seem that I just noted what may be a valuable piece of
> information here.
>
> When testing the remote checks by using the test spam e-mail:
>
> cat /usr/share/doc/spamassassin-3.1.3/sample-spam.txt | spamassassin -D
>
> there are no avc's generated.
This is probably because the processes were running unconfined (you
invoked them in "user space").
> However, the above avc's were generated after an e-mail came through the
> normal fetchmail process, where postfix/procmail are being used to fire
> up spamassassin.
>
> I just replicated both processes and indeed, no avc's were generated
> with the test e-mail, but as soon as a new inbound e-mail came through,
> avc's.
In this case, the processes are running in "system space", and are confined.
> On Wed, 2006-06-21 at 21:07 +0100, Paul Howarth wrote:
>> > Can you remind me where the files are actually installed on your system
>> > (presumably upstream default locations?)?
>> >
>> > Some may need adding to the .fc files.
>
> /var/dcc/* and sub-dirs
That looks to be covered by the dcc policy.
> /usr/bin/razor*
That looks to be covered by the razor policy.
> /root/.razor/*
This has special contexts in strict policy, but not in targeted. So for
targeted we may need to allow it to read home directories.
> /.razor/*
That looks rather dubious.
> dcc was installed from the upstream tarball at Rhyolite. It is not in
> FE. Built with default options.
I think there are probably licensing issues that preclude it from being
in Extras; not sure though.
> razor is installed via FE with perl-Razor-Agent-2.77-3.fc5.
OK, I'll look there if needs be.
> pyzor is also from FE with pyzor-0.4.0-9.fc4. Presumably the RPM naming
> should be updated to fc5?
It just needs a rebuild. But since FC4 and FC5 are both based on python
2.4, it doesn't really matter.
> On Wed, 2006-06-21 at 21:18 +0100, Paul Howarth wrote:
> In addition to my prior e-mail with the dcc and razor files, here are
> the pyzor files:
>
> /.pyzor/*
That looks dubious.
> /root/.pyzor/*
This has special contexts in strict policy, but not in targeted. So for
targeted we may need to allow it to read home directories.
> /usr/bin/pyzor*
Already in policy.
> /usr/lib/python2.4/site-packages/pyzor/*
Nothing special should be needed for those.
> BTW, one more piece of information on the testing.
>
> It dawned on me that there might be a difference in running SA using the
> above syntax versus using SA via the spamd daemon. Thus, I tried:
>
> cat /usr/share/doc/spamassassin-3.1.3/sample-spam.txt | spamc -l
>
> and this does now reproducibly generate the avc's, while still
> generating an adequate trace of the tests.
I think spamc talks to spamd, which is running in "system space" and
thus is confined.
Try this myspamassassin.te to get the domain transitions for dcc and
razor working:
policy_module(myspamassassin, 0.1.0)
require {
type spamd_t;
}
# This will be included in FC5 policy when dcc module is included
dcc_domtrans_client(spamd_t)
# This will be included in FC5 policy when razor module is included
razor_domtrans(spamd_t)
Paul.
More information about the selinux
mailing list