Re: postfix, procmail and SELinux - No Go

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.

--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux