On Sat, 2006-06-24 at 17:40 -0500, Marc Schwartz wrote:
On Sat, 2006-06-24 at 10:12 +0100, Paul Howarth wrote:
> On Thu, 2006-06-22 at 20:19 -0500, Marc Schwartz wrote:
(snip)
> > > > /.razor/*
> > >
> > > That looks rather dubious.
> >
> > I initially thought that these files in / were from the initial install.
> >
> > However, the dates on the log files in that path are current as of last
> > night, when the cron jobs run.
>
> What are the cron jobs doing? We need to find a way of stopping them
> writing here. There's no way I'm going to add policy to allow this.
Here are the key entries:
# Run ClamAV Update every hour
00 * * * * root freshclam --quiet
# Run DCC Update at 1 am
00 01 * * * root /var/dcc/libexec/updatedcc > /dev/null
This one seems OK as it's not trying to write anything in the root
directory.
# Run pyzor update at 1:10 am
10 01 * * * root /usr/bin/pyzor discover > /dev/null
# Run razor update at 1:20 am
20 01 * * * root /usr/bin/razor-admin -discover > /dev/null
updatedcc downloads and builds an updated DCC client each night.
'pyzor discover' updates the pyzor server list.
'razor-admin -discover' does the same for the razor servers.
Can these be made to write files somewhere other than /.razor etc?
Are the files written there just like the ones for regular users, e.g.
default preference settings?
> > type=AVC msg=audit(1151025306.136:693): avc: denied {
search } for pid=22051 comm="dccproc" name="dcc" dev=dm-1 ino=58510
scontex t=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_var_t:s0 tclass=dir
> > type=SYSCALL msg=audit(1151025306.136:693): arch=40000003 syscall=12
success=yes exit=0 a0=bfe79ac2 a1=0 a2=4891eff4 a3=37 items=1 p id=22051 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"
>
> Failed to transition to dcc type, which will be because dccproc isn't
> labelled correctly (it's in /usr/local/bin but policy expects it
> in /usr/bin). Please check in dcc.fc if there are any other programs not
> in the right place.
These files:
/usr/bin/cdcc
/usr/bin/dccproc
are in:
/usr/local/bin/cdcc
/usr/local/bin/dccproc
Got those yesterday :-)
The files that are listed in /usr/libexec/dcc are in
/var/dcc/libexec.
OK, added those file contexts.
# semodule -l
amavis 1.0.4
clamav 1.0.1
dcc 1.0.0
myclamav 0.1.1
mydcc 0.1.5
mypostfix 0.1.0
mypyzor 0.2.1
myspamassassin 0.1.1
procmail 0.5.4
pyzor 1.0.1
razor 1.0.0
New messages:
type=AVC msg=audit(1151188279.668:1444): avc: denied { read } for pid=6563
comm="dccproc" name=".spamassassin2378EoApLctmp" dev=dm-2 ino=24
scontext=system_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:spamd_tmp_t:s0
tclass=file
type=SYSCALL msg=audit(1151188279.668:1444): arch=40000003 syscall=11 success=yes exit=0
a0=a6eece8 a1=9c6f400 a2=a8f8b08 a3=bfec81ac items=2 pid=6563 auid=4294967295 uid=500
gid=0 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none)
comm="dccproc" exe="/usr/local/bin/dccproc"
subj=system_u:system_r:dcc_client_t:s0
type=AVC_PATH msg=audit(1151188279.668:1444):
path="/tmp/.spamassassin2378EoApLctmp"
type=CWD msg=audit(1151188279.668:1444): cwd="/"
type=PATH msg=audit(1151188279.668:1444): item=0 name="/usr/local/bin/dccproc"
inode=3122809 dev=16:07 mode=0104555 ouid=0 ogid=1 rdev=00:00
obj=system_u:object_r:dcc_client_exec_t:s0
type=PATH msg=audit(1151188279.668:1444): item=1 name=(null) inode=754491 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0
dccproc trying to read a temp file created by spamd.
type=AVC msg=audit(1151188279.672:1446): avc: denied { search } for
pid=6563 comm="dccproc" name="dcc" dev=dm-1 ino=58510
scontext=system_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:unlabeled_t:s0
tclass=dir
type=SYSCALL msg=audit(1151188279.672:1446): arch=40000003 syscall=12 success=yes exit=0
a0=bff9abe2 a1=0 a2=4891eff4 a3=37 items=1 pid=6563 auid=4294967295 uid=500 gid=0 euid=500
suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 tty=(none) comm="dccproc"
exe="/usr/local/bin/dccproc" subj=system_u:system_r:dcc_client_t:s0
type=CWD msg=audit(1151188279.672:1446): cwd="/"
type=PATH msg=audit(1151188279.672:1446): item=0 name="/var/dcc" inode=58510
dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:unlabeled_t:s0
/var/dcc appears to have lost its label. I wonder how that happened?
type=AVC msg=audit(1151188279.672:1450): avc: denied { node_bind }
for pid=6563 comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:object_r:inaddr_any_node_t:s0 tclass=udp_socket
type=SYSCALL msg=audit(1151188279.672:1450): arch=40000003 syscall=102 success=yes exit=0
a0=2 a1=bff9bab0 a2=4891eff4 a3=37 items=0 pid=6563 auid=4294967295 uid=500 gid=0 euid=500
suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 tty=(none) comm="dccproc"
exe="/usr/local/bin/dccproc" subj=system_u:system_r:dcc_client_t:s0
type=SOCKADDR msg=audit(1151188279.672:1450): saddr=02000000000000000000000000000000
type=SOCKETCALL msg=audit(1151188279.672:1450): nargs=3 a0=4 a1=bff9bb54 a2=10
I'm not sure what's that's doing. Will look at that again later.
I'm a bit surprised that nothing has turned up for clamassassin. Can''t
believe I got that right first time...
Here's the updated policy files:
::::::::::::::
mydcc.fc
::::::::::::::
/usr/local/bin/cdcc --
gen_context(system_u:object_r:cdcc_exec_t,s0)
/usr/local/bin/dccproc --
gen_context(system_u:object_r:dcc_client_exec_t,s0)
/var/dcc/libexec/dbclean --
gen_context(system_u:object_r:dcc_dbclean_exec_t,s0)
/var/dcc/libexec/dccd --
gen_context(system_u:object_r:dccd_exec_t,s0)
/var/dcc/libexec/dccifd --
gen_context(system_u:object_r:dccifd_exec_t,s0)
/var/dcc/libexec/dccm --
gen_context(system_u:object_r:dccm_exec_t,s0)
::::::::::::::
mydcc.te
::::::::::::::
policy_module(mydcc, 0.1.6)
# ==================================================
# Declarations
# ==================================================
require {
type dcc_client_t;
}
# ==================================================
# DCC client local policy
# ==================================================
spamassassin_read_spamd_tmp_files(dcc_client_t)
After loading the updated modules, you'll need to do:
# restorecon -rv /var/dcc
Paul.