2:04 a.m.
On Tue, 2006-06-06 at 21:34 -0500, Marc Schwartz wrote:
Paul,
OK...seemingly back up and running. Here are the present avc messages
since re-loading everything and confirming that the file contexts are
back to the changes that we made.
I note that the /proc/meminfo messages are back, but now for
clamassassin. I am sure that I have reloaded the new modules that we
created, so not sure what is up here, unless there was some conflict
when the two versions of the policies we seemingly loaded earlier today.
Let me know on these and if perhaps I missed something:
You forgot that we reverted the clamassassin context change yesterday.
# restorecon -v /usr/local/bin/clamassassin
type=AVC msg=audit(1149646922.456:801): avc: denied { read } for
pid=23273 comm="clamassassin" name="meminfo" dev=proc ino=-268435454
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
type=SYSCALL msg=audit(1149646922.456:801): arch=40000003 syscall=5 success=yes exit=3
a0=489093ef a1=0 a2=1b6 a3=a021240 items=1 pid=23273 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="clamassassin"
exe="/bin/bash"
type=CWD msg=audit(1149646922.456:801): cwd="/home/marcs"
type=PATH msg=audit(1149646922.456:801): item=0 name="/proc/meminfo" flags=101
inode=4026531842 dev=00:03 mode=0100444 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1149646922.456:802): avc: denied { getattr } for pid=23273
comm="clamassassin" name="meminfo" dev=proc ino=-268435454
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
type=SYSCALL msg=audit(1149646922.456:802): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bf8d7f28 a2=4891eff4 a3=3 items=0 pid=23273 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="clamassassin"
exe="/bin/bash"type=AVC_PATH msg=audit(1149646922.456:802):
path="/proc/meminfo"
type=AVC msg=audit(1149646922.456:803): avc: denied { search } for pid=23273
comm="clamassassin" name="bin" dev=hdc7 ino=3112982
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=dir
type=SYSCALL msg=audit(1149646922.456:803): arch=40000003 syscall=5 success=yes exit=3
a0=a023018 a1=8000 a2=0 a3=8000 items=1 pid=23273 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="clamassassin"
exe="/bin/bash"
type=CWD msg=audit(1149646922.456:803): cwd="/home/marcs"
type=PATH msg=audit(1149646922.456:803): item=0
name="/usr/local/bin/clamassassin" flags=101 inode=3115337 dev=16:07
mode=0100555 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1149646922.460:804): avc: denied { execute } for pid=23274
comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=AVC msg=audit(1149646922.460:804): avc: denied { execute_no_trans } for pid=23274
comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=AVC msg=audit(1149646922.460:804): avc: denied { read } for pid=23274
comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=SYSCALL msg=audit(1149646922.460:804): arch=40000003 syscall=11 success=yes exit=0
a0=a0232c0 a1=a023500 a2=a026dd0 a3=a023228 items=2 pid=23274 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="mktemp"
exe="/bin/mktemp"
type=AVC_PATH msg=audit(1149646922.460:804): path="/bin/mktemp"
type=AVC_PATH msg=audit(1149646922.460:804): path="/bin/mktemp"
type=CWD msg=audit(1149646922.460:804): cwd="/home/marcs"
type=PATH msg=audit(1149646922.460:804): item=0 name="/bin/mktemp" flags=101
inode=1966111 dev=16:07 mode=0100555 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1149646922.460:804): item=1 flags=101 inode=754491 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1149646922.460:805): avc: denied { read } for pid=23274
comm="mktemp" name="urandom" dev=tmpfs ino=1719
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:urandom_device_t:s0
tclass=chr_file
type=SYSCALL msg=audit(1149646922.460:805): arch=40000003 syscall=5 success=yes exit=3
a0=80494d8 a1=0 a2=48920120 a3=8f5f008 items=1 pid=23274 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="mktemp"
exe="/bin/mktemp"
type=CWD msg=audit(1149646922.460:805): cwd="/home/marcs"
type=PATH msg=audit(1149646922.460:805): item=0 name="/dev/urandom" flags=101
inode=1719 dev=00:0f mode=020444 ouid=0 ogid=0 rdev=01:09
type=AVC msg=audit(1149646922.468:806): avc: denied { execute_no_trans } for pid=23277
comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0
tclass=file
type=SYSCALL msg=audit(1149646922.468:806): arch=40000003 syscall=11 success=yes exit=0
a0=a026c00 a1=a026210 a2=a026dd0 a3=a026d90 items=2 pid=23277 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="clamscan"
exe="/usr/bin/clamscan"
type=AVC_PATH msg=audit(1149646922.468:806): path="/usr/bin/clamscan"
type=CWD msg=audit(1149646922.468:806): cwd="/home/marcs"
type=PATH msg=audit(1149646922.468:806): item=0 name="/usr/bin/clamscan"
flags=101 inode=3123838 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1149646922.468:806): item=1 flags=101 inode=754491 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00
The context change should fix all of the above.
type=AVC msg=audit(1149646926.516:807): avc: denied { recv_msg }
for saddr=66.250.40.33 src=24441 daddr=192.168.1.2 dest=32875 netif=eth0
scontext=user_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:pyzor_port_t:s0
tclass=udp_socket
Hmm, pyzor needs to receive messages as well as send them...
type=AVC msg=audit(1149646926.528:808): avc: denied { create } for
pid=23325 comm="dccproc" scontext=user_u:system_r:spamd_t:s0
tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1149646926.528:808): arch=40000003 syscall=102 success=yes exit=3
a0=1 a1=bfb89868 a2=4891eff4 a3=8069fbf items=0 pid=23325 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=SOCKETCALL msg=audit(1149646926.528:808): nargs=3 a0=10 a1=3 a2=0
type=AVC msg=audit(1149646926.528:809): avc: denied { bind } for pid=23325
comm="dccproc" scontext=user_u:system_r:spamd_t:s0
tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1149646926.528:809): arch=40000003 syscall=102 success=yes exit=0
a0=2 a1=bfb89868 a2=4891eff4 a3=3 items=0 pid=23325 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=SOCKADDR msg=audit(1149646926.528:809): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1149646926.528:809): nargs=3 a0=3 a1=bfb89874 a2=c
type=AVC msg=audit(1149646926.528:810): avc: denied { getattr } for pid=23325
comm="dccproc" scontext=user_u:system_r:spamd_t:s0
tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1149646926.528:810): arch=40000003 syscall=102 success=yes exit=0
a0=6 a1=bfb89868 a2=4891eff4 a3=3 items=0 pid=23325 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=SOCKETCALL msg=audit(1149646926.528:810): nargs=3 a0=3 a1=bfb89874 a2=bfb89880
type=AVC msg=audit(1149646926.528:811): avc: denied { write } for pid=23325
comm="dccproc" scontext=user_u:system_r:spamd_t:s0
tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket
type=AVC msg=audit(1149646926.528:811): avc: denied { nlmsg_read } for pid=23325
comm="dccproc" scontext=user_u:system_r:spamd_t:s0
tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1149646926.528:811): arch=40000003 syscall=102 success=yes exit=20
a0=b a1=bfb887b4 a2=4891eff4 a3=ffffffcc items=0 pid=23325 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=SOCKADDR msg=audit(1149646926.528:811): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1149646926.528:811): nargs=6 a0=3 a1=bfb8982c a2=14 a3=0
a4=bfb89840 a5=c
type=AVC msg=audit(1149646926.528:812): avc: denied { read } for pid=23325
comm="dccproc" scontext=user_u:system_r:spamd_t:s0
tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1149646926.528:812): arch=40000003 syscall=102 success=yes
exit=128 a0=11 a1=bfb887b4 a2=4891eff4 a3=ffffffcc items=0 pid=23325 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=SOCKETCALL msg=audit(1149646926.528:812): nargs=3 a0=3 a1=bfb89810 a2=0
I've seen a lot of these recently. I think dcc is trying to read the
routing table. We'll allow that.
(snip)
The rest seem to be duplicates.
Updated policy modules:
####### mydcc.te #######
policy_module(mydcc, 0.1.3)
require {
type spamd_t;
}
type dcc_var_t;
files_type(dcc_var_t)
type dcc_client_map_t;
files_type(dcc_client_map_t)
# Allow spamd to behave as a dcc client
allow spamd_t dcc_client_map_t:file rw_file_perms;
allow spamd_t dcc_var_t:dir search;
# Allow spamd to read the routing table (needed by dcc)
allow spamd_t self:netlink_route_socket { r_netlink_socket_perms };
####### mypyzor.te #######
policy_module(mypyzor, 0.1.3)
require {
type pyzor_t;
type pyzor_port_t;
type spamd_t;
};
# temp files
type pyzor_tmp_t;
files_tmp_file(pyzor_tmp_t)
# Allow pyzor to create and use temp files and dirs
allow pyzor_t pyzor_tmp_t:dir create_dir_perms;
allow pyzor_t pyzor_tmp_t:file create_file_perms;
files_type(pyzor_tmp_t)
files_tmp_filetrans(pyzor_t, pyzor_tmp_t, { file dir })
# Allow pyzor to read config (and any other file...)
# from user home directories
userdom_read_unpriv_users_home_content_files(pyzor_t)
# Allow pyzor to read /dev/urandom
dev_read_urand(pyzor_t)
# Allow pyzor to send and receive pyzor messages!
allow pyzor_t pyzor_port_t:udp_socket send_msg;
allow pyzor_t pyzor_port_t:udp_socket recv_msg;
# Allow spamd to signal pyzor (kill/hup ?)
allow spamd_t pyzor_t:process signal;
# Allow pyzor to ...?
corecmd_search_bin(pyzor_t)
kernel_read_kernel_sysctls(pyzor_t)
# It does a getattr on /usr/bin/time for reasons unknown...
allow pyzor_t bin_t:dir getattr;
allow pyzor_t bin_t:file getattr;
# Pyzor/python probably doesn't need to be able to read /proc/meminfo
kernel_dontaudit_list_proc(pyzor_t)
kernel_dontaudit_read_system_state(pyzor_t)
Paul.
7:41 a.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-07 at 08:04 +0100, Paul Howarth wrote:
On Tue, 2006-06-06 at 21:34 -0500, Marc Schwartz wrote:
> Paul,
>
> OK...seemingly back up and running. Here are the present avc messages
> since re-loading everything and confirming that the file contexts are
> back to the changes that we made.
>
> I note that the /proc/meminfo messages are back, but now for
> clamassassin. I am sure that I have reloaded the new modules that we
> created, so not sure what is up here, unless there was some conflict
> when the two versions of the policies we seemingly loaded earlier today.
>
> Let me know on these and if perhaps I missed something:
You forgot that we reverted the clamassassin context change yesterday.
# restorecon -v /usr/local/bin/clamassassin
<banging head against the wall...>
OK. The additional policy updates have been installed and at this point
there are no new messages from avclist.
Thanks,
Marc
8:30 a.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-07 at 07:41 -0500, Marc Schwartz wrote:
On Wed, 2006-06-07 at 08:04 +0100, Paul Howarth wrote:
> On Tue, 2006-06-06 at 21:34 -0500, Marc Schwartz wrote:
> > Paul,
> >
> > OK...seemingly back up and running. Here are the present avc messages
> > since re-loading everything and confirming that the file contexts are
> > back to the changes that we made.
> >
> > I note that the /proc/meminfo messages are back, but now for
> > clamassassin. I am sure that I have reloaded the new modules that we
> > created, so not sure what is up here, unless there was some conflict
> > when the two versions of the policies we seemingly loaded earlier today.
> >
> > Let me know on these and if perhaps I missed something:
>
> You forgot that we reverted the clamassassin context change yesterday.
>
> # restorecon -v /usr/local/bin/clamassassin
<banging head against the wall...>
OK. The additional policy updates have been installed and at this point
there are no new messages from avclist.
Moment of truth time then!
Try turning on enforcing mode and see if it all still works.
# setenforce 1
Check that mail works in and out, and that pyzor/dcc/spamd etc. are all
working.
If not, we'll need to try changing some of those "dontaudit"s to
"allow"s.
Paul.
11:20 a.m.
New subject: postfix, procmail and SELinux - No Go
I will be turning on dcc and razor policy in next rawhide update. This
should cover some of the problems you are having. Please send
me all of your policy so that I can get it in the upstream pool.
Dan
11:56 a.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-07 at 12:20 -0400, Daniel J Walsh wrote:
I will be turning on dcc and razor policy in next rawhide update.
This
should cover some of the problems you are having. Please send
me all of your policy so that I can get it in the upstream pool.
We may need to do some rework then, since what we have, particularly for
dcc, is getting the dcc client to work in spamd when running in the
spamd domain. By turning on the dcc policy, this will all change.
Similarly, Mark seems to be running razor from pyzor, so the policy
tweaks have been for getting razor working as pyzor_t.
I can send you what we've got so far, but it'll be of limited
usefulness. Perhaps more useful would be if Mark could let you know
where the various files/programs are installed to in the upstream
default configuration (and his config, if different), so that the file
contexts in policy can be right first time.
Here's the clamav policy additions we ended up with for running
clamassassin from procmail with postfix:
policy_module(myclam, 0.1.2)
require {
type clamscan_t;
type postfix_local_t;
type procmail_tmp_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;
This policy requires that procmail can create temp files as well, which
I don't think is in policy at the moment. It also needs a domain
transition from procmail_t to clamscan_t:
policy_module(procmail, 0.5.1)
require {
type procmail_t;
};
# temp files
type procmail_tmp_t;
files_tmp_file(procmail_tmp_t)
# log files
type procmail_var_log_t;
logging_log_file(procmail_var_log_t)
# Write log to /var/log/procmail.log
allow procmail_t procmail_var_log_t:file create_file_perms;
allow procmail_t procmail_var_log_t:dir { rw_dir_perms setattr };
logging_log_filetrans(procmail_t,procmail_var_log_t, { file dir })
# Allow programs called from procmail to read/write temp files and dirs
allow procmail_t procmail_tmp_t:dir create_dir_perms;
allow procmail_t procmail_tmp_t:file create_file_perms;
files_type(procmail_tmp_t)
files_tmp_filetrans(procmail_t, procmail_tmp_t, { file dir })
# ==============================================
# Procmail needs to call sendmail for forwarding
# ==============================================
# Read alternatives link (still not in policy)
corecmd_read_sbin_symlinks(procmail_t)
# Allow transition to sendmail
# This is in selinux-policy-2.2.34-2 onwards
# (may need similar code for other MTAs that can replace sendmail)
# sendmail_domtrans(procmail_t)
# ==============================================
# Procmail needs to be able to call clamassassin
# ==============================================
clamscan_domtrans(procmail_t)
FWIW, here's the pyzor policy tweaks we used. Most will probably be
irrelevant after enabling razor, but some (e.g. the sending and
receiving messages) looks valid:
policy_module(mypyzor, 0.1.3)
require {
type pyzor_t;
type pyzor_port_t;
type spamd_t;
};
# temp files
type pyzor_tmp_t;
files_tmp_file(pyzor_tmp_t)
# Allow pyzor to create and use temp files and dirs
allow pyzor_t pyzor_tmp_t:dir create_dir_perms;
allow pyzor_t pyzor_tmp_t:file create_file_perms;
files_type(pyzor_tmp_t)
files_tmp_filetrans(pyzor_t, pyzor_tmp_t, { file dir })
# Allow pyzor to read config (and any other file...)
# from user home directories
userdom_read_unpriv_users_home_content_files(pyzor_t)
# Allow pyzor to read /dev/urandom
dev_read_urand(pyzor_t)
# Allow pyzor to send and receive pyzor messages!
allow pyzor_t pyzor_port_t:udp_socket send_msg;
allow pyzor_t pyzor_port_t:udp_socket recv_msg;
# Allow spamd to signal pyzor (kill/hup ?)
allow spamd_t pyzor_t:process signal;
# Allow pyzor to ...?
corecmd_search_bin(pyzor_t)
kernel_read_kernel_sysctls(pyzor_t)
# It does a getattr on /usr/bin/time for reasons unknown...
allow pyzor_t bin_t:dir getattr;
allow pyzor_t bin_t:file getattr;
# Pyzor/python probably doesn't need to be able to read /proc/meminfo
kernel_dontaudit_list_proc(pyzor_t)
kernel_dontaudit_read_system_state(pyzor_t)
Paul.
1:12 p.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-07 at 17:56 +0100, Paul Howarth wrote:
On Wed, 2006-06-07 at 12:20 -0400, Daniel J Walsh wrote:
> I will be turning on dcc and razor policy in next rawhide update. This
> should cover some of the problems you are having. Please send
> me all of your policy so that I can get it in the upstream pool.
We may need to do some rework then, since what we have, particularly for
dcc, is getting the dcc client to work in spamd when running in the
spamd domain. By turning on the dcc policy, this will all change.
Similarly, Mark seems to be running razor from pyzor, so the policy
tweaks have been for getting razor working as pyzor_t.
I can send you what we've got so far, but it'll be of limited
usefulness. Perhaps more useful would be if Mark could let you know
where the various files/programs are installed to in the upstream
default configuration (and his config, if different), so that the file
contexts in policy can be right first time.
<snip of policies>
Paul and Dan,
As of this moment, now running in Enforcing Mode, the following are
known to work with Paul's policies and context changes:
Incoming multiple POP3 account mail via fetchmail is working.
fetchmail, BTW, runs every 2 mins. from my own crontab file, not the
system crontab, using ~/.fetchmailrc.
Outgoing mail via company SMTP server is working
Mail forwarding off my laptop via procmail/postfix is working
Clamassassin is working
Spamassassin is working
I have not yet had any Viagra-like e-mails to be able to test the other
remote servers (ie. pyzor, razor and DCC) to check for function.
Hopefully some with come through today (why can't you get them when you
want them.... ;-).
The context changes that we made are:
chcon system_u:object_r:initrc_exec_t /var/dcc/libexec/start-*
chcon system_u:object_r:initrc_exec_t /var/dcc/libexec/start-*
restorecon -v /usr/local/bin/clamassassin
restorecon -v /var/run/utmp
Running 'fixfiles check' shows no errors.
As of this moment, there are no new avc messages since going to
Enforcing Mode.
In terms of installs:
1. SA is the default Core install
2. Pyzor is pyzor.noarch from Extras
3. ClamAV is (from Extras):
clamav-devel-0.88.2-1.fc5
clamav-server-0.88.2-1.fc5
clamav-lib-0.88.2-1.fc5
clamav-update-0.88.2-1.fc5
clamav-milter-0.88.2-1.fc5
clamav-exim-0.86.2-5.fc5
clamav-data-0.88.2-1.fc5
clamav-0.88.2-1.fc5
4. Razor is perl-Razor-Agent.i386 from Extras
5. DCC is installed from the tarball at:
http://www.rhyolite.com/anti-spam/dcc/
6. Clamassassin is installed from the tarball at:
http://jameslick.com/clamassassin/
There are three cron jobs that run at night as well to update the remote
tests:
# Run DCC Update at 1 am
00 01 * * * root /var/dcc/libexec/updatedcc > /dev/null
# 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
And there is an hourly cron ClamAV update:
# Run ClamAV Update every hour
00 * * * * root freshclam --quiet
I have root's e-mail (via postfix) coming to my local account using an
alias in /etc/aliases and the 'mailbox-command' in /etc/postfix/main.cf
is set to /usr/bin/procmail.
The contents of /etc/mail/spamassassin/v310.pre were modified to enable
razor and DCC. This involved uncommenting:
loadplugin Mail::SpamAssassin::Plugin::Razor2
and
loadplugin Mail::SpamAssassin::Plugin::DCC
SA personal settings in ~/.spamassassin/user_prefs:
rewrite_header Subject [***** SPAM (_SCORE_) *****]
# Enable RBL Checks
skip_rbl_checks 0
# Enable Bayesian filtering and learning
use_bayes 1
use_bayes_rules 1
bayes_auto_learn 1
# Pyzor Settings
use_pyzor 1
# Razor Scores to override system settings
# Need to modify /etc/mail/spamassassin/v310pre
use_razor2 1
score RAZOR2_CHECK 0.5
score RAZOR2_CF_RANGE_51_100 0.5
score RAZOR2_CF_RANGE_E4_51_100 1.5
score RAZOR2_CF_RANGE_E8_51_100 1.5
# DCC checks to override system settings
# Need to modify /etc/mail/spamassassin/v310pre
use_dcc 1
score DCC_CHECK 2.17
Finally, my ~/.procmailrc (without the test forwarding) is:
# Scan for viruses using ClamAV
# This sets: "X-Virus-Status: Yes"
:0 fw
| /usr/local/bin/clamassassin
# Scan with SpamAssassin
:0 fw
# Use spamc with spamd daemon to save CPU
# This sets: "X-Spam-Status: Yes"
# Size setting only scans e-mails < 256k bytes
| /usr/bin/spamc -s 256000
If there is anything else you need to know, let me know. As soon as I
can confirm the use and hits on DCC, razor and pyzor I will follow up.
Thanks!
Marc Schwartz
< A slow spam day? I can't believe that I am anxiously awaiting a
solicitation for an ED drug... :-) >
3:37 p.m.
New subject: postfix, procmail and SELinux - No Go
Le mercredi 07 juin 2006 à 13:12 -0500, Marc Schwartz (via MN) a écrit :
aul and Dan,
As of this moment, now running in Enforcing Mode, the following are
known to work with Paul's policies and context changes:
Incoming multiple POP3 account mail via fetchmail is working.
fetchmail, BTW, runs every 2 mins. from my own crontab file, not the
system crontab, using ~/.fetchmailrc.
Outgoing mail via company SMTP server is working
Mail forwarding off my laptop via procmail/postfix is working
Clamassassin is working
Spamassassin is working
I have not yet had any Viagra-like e-mails to be able to test the other
remote servers (ie. pyzor, razor and DCC) to check for function.
Hopefully some with come through today (why can't you get them when you
want them.... ;-).
BTW (did I already wrote this?) it seems strange that on a postfix
+procmail+clamav+sa setup you wouldn't be using amavis, especailly since
it's available in FE
--
Nicolas Mailhot
7:38 p.m.
New subject: postfix, procmail and SELinux - No Go
Nicolas Mailhot wrote:
Le mercredi 07 juin 2006 Ã 13:12 -0500, Marc Schwartz (via MN) a
écrit :
> aul and Dan,
>
> As of this moment, now running in Enforcing Mode, the following are
> known to work with Paul's policies and context changes:
>
> Incoming multiple POP3 account mail via fetchmail is working.
> fetchmail, BTW, runs every 2 mins. from my own crontab file, not the
> system crontab, using ~/.fetchmailrc.
>
> Outgoing mail via company SMTP server is working
>
> Mail forwarding off my laptop via procmail/postfix is working
>
> Clamassassin is working
>
> Spamassassin is working
>
>
> I have not yet had any Viagra-like e-mails to be able to test the other
> remote servers (ie. pyzor, razor and DCC) to check for function.
> Hopefully some with come through today (why can't you get them when you
> want them.... ;-).
BTW (did I already wrote this?) it seems strange that on a postfix
+procmail+clamav+sa setup you wouldn't be using amavis, especailly since
it's available in FE
Nicolas,
No, you had not queried me on that previously.
When I set this approach up two or three years ago, I was looking for
something relatively easy to maintain, that was targeted to a relatively
low volume, single user system. I became aware of ClamAssassin via the
ClamAV third party apps web page and subsequent Google searches.
My readings of amavisd-new suggested that it was targeted more for
multi-user mail server configurations, given the more complex processing
options and reporting. Kind of along the lines of some of the other
mail::scanner classes of applications.
This was quick and easy to configure using procmail, including enabling
subject and header re-writes for SA and ClamAV. The remote spam tests
via SA were quick and easy to install and (prior to SA 3.1 as you first
noted) no other configuration modifications were required.
Most importantly, it has been effective at dramatically reducing my
manual handling of spam.
The occasional 'infected' e-mail that I still get is picked up quickly
and deleted using a filter in Evo based upon the X-Virus-Status tag. I
could set up the procmail recipe to send them to /dev/null, but I like
to keep track of them to have a sense of frequency. Between my company's
server filters and my personal ISP's filters, they are a rarity now.
I appreciate your asking and hope that this clarifies my logic.
Regards,
Marc Schwartz
4:54 p.m.
New subject: postfix, procmail and SELinux - No Go
Le mercredi 07 juin 2006 à 19:38 -0500, Marc Schwartz a écrit :
Nicolas Mailhot wrote:
>> I have not yet had any Viagra-like e-mails to be able to
test the other
>> remote servers (ie. pyzor, razor and DCC) to check for function.
>> Hopefully some with come through today (why can't you get them when you
>> want them.... ;-).
>
>
> BTW (did I already wrote this?) it seems strange that on a postfix
> +procmail+clamav+sa setup you wouldn't be using amavis, especailly since
> it's available in FE
Nicolas,
No, you had not queried me on that previously.
When I set this approach up two or three years ago, I was looking for
something relatively easy to maintain, that was targeted to a relatively
low volume, single user system. I became aware of ClamAssassin via the
ClamAV third party apps web page and subsequent Google searches.
My readings of amavisd-new suggested that it was targeted more for
multi-user mail server configurations, given the more complex processing
options and reporting. Kind of along the lines of some of the other
mail::scanner classes of applications.
Ok. Since you never actually tried amavisd, and since you've proved
willing so far to invest some time in your spam config, I think you may
find it worth your time to try amavis. IMHO you'll find it's no more
difficult to setup than what you already did with procmail+clamassassin,
and is a quite a bit more powerful.
At least I did manage to install easily amavis way before it become
available in fedora, but failed miserably when investigating dcc
(granted the licensing was not too motivating in this last case)
Regards,
--
Nicolas Mailhot
6:12 p.m.
New subject: postfix, procmail and SELinux - No Go
Nicolas Mailhot wrote:
Le mercredi 07 juin 2006 à 19:38 -0500, Marc Schwartz a écrit :
> Nicolas Mailhot wrote:
>> BTW (did I already wrote this?) it seems strange that on a postfix
>> +procmail+clamav+sa setup you wouldn't be using amavis, especailly since
>> it's available in FE
> Nicolas,
>
> No, you had not queried me on that previously.
>
> When I set this approach up two or three years ago, I was looking for
> something relatively easy to maintain, that was targeted to a relatively
> low volume, single user system. I became aware of ClamAssassin via the
> ClamAV third party apps web page and subsequent Google searches.
>
> My readings of amavisd-new suggested that it was targeted more for
> multi-user mail server configurations, given the more complex processing
> options and reporting. Kind of along the lines of some of the other
> mail::scanner classes of applications.
Ok. Since you never actually tried amavisd, and since you've proved
willing so far to invest some time in your spam config, I think you may
find it worth your time to try amavis. IMHO you'll find it's no more
difficult to setup than what you already did with procmail+clamassassin,
and is a quite a bit more powerful.
At least I did manage to install easily amavis way before it become
available in fedora, but failed miserably when investigating dcc
(granted the licensing was not too motivating in this last case)
Nicolas,
Fair enough. I'll take a more involved peek at it.
Thanks,
Marc
3:38 a.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz (via MN) wrote:
Paul and Dan,
As of this moment, now running in Enforcing Mode, the following are
known to work with Paul's policies and context changes:
[snip of lots of useful data]
Marc Schwartz
Marc, may I suggest adding / describing your setup in the form of a "
not-really-quick-but-very-useful howto " on FC5's wiki ?
lonely "I prefer things which run out-of-the-box" wolf
8:20 a.m.
New subject: postfix, procmail and SELinux - No Go
lonely wolf wrote:
Marc Schwartz (via MN) wrote:
> Paul and Dan,
>
> As of this moment, now running in Enforcing Mode, the following are
> known to work with Paul's policies and context changes:
>
> [snip of lots of useful data]
>
>
Marc, may I suggest adding / describing your setup in the form of a "
not-really-quick-but-very-useful howto " on FC5's wiki ?
Sure. I am in the midst of a work related project at the moment that I
am trying to get done before I head to Europe on Monday for a R
(http://www.r-project.org/) user conference in Vienna next week.
"Conveniently" I will have some time on planes and in airports both ways
and can perhaps begin drafting something offline and then post it when
ready.
I am saving your post as a reminder.
Thanks,
Marc Schwartz
7:45 a.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-07 at 13:12 -0500, Marc Schwartz (via MN) wrote:
On Wed, 2006-06-07 at 17:56 +0100, Paul Howarth wrote:
> On Wed, 2006-06-07 at 12:20 -0400, Daniel J Walsh wrote:
> > I will be turning on dcc and razor policy in next rawhide update. This
> > should cover some of the problems you are having. Please send
> > me all of your policy so that I can get it in the upstream pool.
>
> We may need to do some rework then, since what we have, particularly for
> dcc, is getting the dcc client to work in spamd when running in the
> spamd domain. By turning on the dcc policy, this will all change.
>
> Similarly, Mark seems to be running razor from pyzor, so the policy
> tweaks have been for getting razor working as pyzor_t.
>
> I can send you what we've got so far, but it'll be of limited
> usefulness. Perhaps more useful would be if Mark could let you know
> where the various files/programs are installed to in the upstream
> default configuration (and his config, if different), so that the file
> contexts in policy can be right first time.
<snip of policies>
Paul and Dan,
As of this moment, now running in Enforcing Mode, the following are
known to work with Paul's policies and context changes:
Incoming multiple POP3 account mail via fetchmail is working.
fetchmail, BTW, runs every 2 mins. from my own crontab file, not the
system crontab, using ~/.fetchmailrc.
Outgoing mail via company SMTP server is working
Mail forwarding off my laptop via procmail/postfix is working
Clamassassin is working
Spamassassin is working
I have not yet had any Viagra-like e-mails to be able to test the other
remote servers (ie. pyzor, razor and DCC) to check for function.
Hopefully some with come through today (why can't you get them when you
want them.... ;-).
Just a quick update here that so far, I can add:
DCC is working
Pyzor is working
to the list.
So far, no confirmed hits on Razor2 or RBL's (ie. SpamCop).
I have temporarily modified some of the SA generated e-mail headers via
add_header in user_prefs so that I can keep better track of these things
specifically.
I'll post more when I can confirm the remaining tests.
Regards,
Marc
6:03 p.m.
New subject: postfix, procmail and SELinux - No Go
On Thu, 2006-06-08 at 07:45 -0500, Marc Schwartz wrote:
On Wed, 2006-06-07 at 13:12 -0500, Marc Schwartz (via MN) wrote:
> Paul and Dan,
>
> As of this moment, now running in Enforcing Mode, the following are
> known to work with Paul's policies and context changes:
>
> Incoming multiple POP3 account mail via fetchmail is working.
> fetchmail, BTW, runs every 2 mins. from my own crontab file, not the
> system crontab, using ~/.fetchmailrc.
>
> Outgoing mail via company SMTP server is working
>
> Mail forwarding off my laptop via procmail/postfix is working
>
> Clamassassin is working
>
> Spamassassin is working
>
Just a quick update here that so far, I can add:
DCC is working
Pyzor is working
to the list.
Another update:
razor2 is working.
Finally got a hit. That just leaves the RBL's.
Regards,
Marc
11:40 a.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz wrote:
On Wed, 2006-06-07 at 13:12 -0500, Marc Schwartz (via MN) wrote:
> On Wed, 2006-06-07 at 17:56 +0100, Paul Howarth wrote:
>> On Wed, 2006-06-07 at 12:20 -0400, Daniel J Walsh wrote:
>>> I will be turning on dcc and razor policy in next rawhide update. This
>>> should cover some of the problems you are having. Please send
>>> me all of your policy so that I can get it in the upstream pool.
>> We may need to do some rework then, since what we have, particularly for
>> dcc, is getting the dcc client to work in spamd when running in the
>> spamd domain. By turning on the dcc policy, this will all change.
>>
>> Similarly, Mark seems to be running razor from pyzor, so the policy
>> tweaks have been for getting razor working as pyzor_t.
>>
>> I can send you what we've got so far, but it'll be of limited
>> usefulness. Perhaps more useful would be if Mark could let you know
>> where the various files/programs are installed to in the upstream
>> default configuration (and his config, if different), so that the file
>> contexts in policy can be right first time.
> <snip of policies>
>
> Paul and Dan,
>
> As of this moment, now running in Enforcing Mode, the following are
> known to work with Paul's policies and context changes:
>
> Incoming multiple POP3 account mail via fetchmail is working.
> fetchmail, BTW, runs every 2 mins. from my own crontab file, not the
> system crontab, using ~/.fetchmailrc.
>
> Outgoing mail via company SMTP server is working
>
> Mail forwarding off my laptop via procmail/postfix is working
>
> Clamassassin is working
>
> Spamassassin is working
>
>
> I have not yet had any Viagra-like e-mails to be able to test the other
> remote servers (ie. pyzor, razor and DCC) to check for function.
> Hopefully some with come through today (why can't you get them when you
> want them.... ;-).
Just a quick update here that so far, I can add:
DCC is working
Pyzor is working
to the list.
So far, no confirmed hits on Razor2 or RBL's (ie. SpamCop).
I have temporarily modified some of the SA generated e-mail headers via
add_header in user_prefs so that I can keep better track of these things
specifically.
I'll post more when I can confirm the remaining tests.
At this point it might be worth trying to remove some of the "strange"
policy items, such as:
allow postfix_master_t man_t:file getattr;
and see what, if anything fails. By doing this we might get some insight
into what is actually happening, or if nothing breaks, we could
dontaudit it instead of allowing it.
Paul.
3:07 p.m.
New subject: postfix, procmail and SELinux - No Go
On Mon, 2006-06-12 at 17:40 +0100, Paul Howarth wrote:
At this point it might be worth trying to remove some of the
"strange"
policy items, such as:
allow postfix_master_t man_t:file getattr;
and see what, if anything fails. By doing this we might get some insight
into what is actually happening, or if nothing breaks, we could
dontaudit it instead of allowing it.
Paul.
Paul,
Apologies for the delay in my reply, as I was traveling (Vienna,
Austria) all of last week and got back late yesterday. My schedule there
ended up being busier than I expected and did not have a chance to get
to this.
I tried to make the above modification to mypostfix.te, however when
going back to build all of the policy modules, I now get an error:
Compiling targeted procmail module
/usr/bin/checkmodule: loading policy configuration from
tmp/procmail.tmp
procmail.te:41:ERROR 'syntax error' at token 'clamscan_domtrans' on line
57484:
clamscan_domtrans(procmail_t)
# ==============================================
/usr/bin/checkmodule: error(s) encountered while parsing configuration
make: *** [tmp/procmail.mod] Error 1
Line 41 in procmail.te (as noted above) is:
clamscan_domtrans(procmail_t)
This error occurs even without the modification to mypostfix.te, so I am
unclear as to what happened since the last time I was able to build them
all.
I plead jet lag here and suspect that you might rapidly recognize what
is happening and have an easy fix. If you need me to check some files,
let me know.
Regards and thanks,
Marc
3:13 p.m.
New subject: postfix, procmail and SELinux - No Go
On Mon, 2006-06-19 at 15:07 -0500, Marc Schwartz (via MN) wrote:
On Mon, 2006-06-12 at 17:40 +0100, Paul Howarth wrote:
> At this point it might be worth trying to remove some of the "strange"
> policy items, such as:
>
> allow postfix_master_t man_t:file getattr;
>
> and see what, if anything fails. By doing this we might get some insight
> into what is actually happening, or if nothing breaks, we could
> dontaudit it instead of allowing it.
>
> Paul.
Paul,
Apologies for the delay in my reply, as I was traveling (Vienna,
Austria) all of last week and got back late yesterday. My schedule there
ended up being busier than I expected and did not have a chance to get
to this.
I tried to make the above modification to mypostfix.te, however when
going back to build all of the policy modules, I now get an error:
Compiling targeted procmail module
/usr/bin/checkmodule: loading policy configuration from
tmp/procmail.tmp
procmail.te:41:ERROR 'syntax error' at token 'clamscan_domtrans' on line
57484:
clamscan_domtrans(procmail_t)
# ==============================================
/usr/bin/checkmodule: error(s) encountered while parsing configuration
make: *** [tmp/procmail.mod] Error 1
Line 41 in procmail.te (as noted above) is:
clamscan_domtrans(procmail_t)
This error occurs even without the modification to mypostfix.te, so I am
unclear as to what happened since the last time I was able to build them
all.
I plead jet lag here and suspect that you might rapidly recognize what
is happening and have an easy fix. If you need me to check some files,
let me know.
The interface name has changed in a recent selinux-policy update. New
procmail.te:
policy_module(procmail, 0.5.3)
require {
type procmail_t;
type sendmail_t;
};
# temp files
type procmail_tmp_t;
files_tmp_file(procmail_tmp_t)
# log files
type procmail_var_log_t;
logging_log_file(procmail_var_log_t)
# Write log to /var/log/procmail.log
allow procmail_t procmail_var_log_t:file create_file_perms;
allow procmail_t procmail_var_log_t:dir { rw_dir_perms setattr };
logging_log_filetrans(procmail_t,procmail_var_log_t, { file dir })
# Allow programs called from procmail to read/write temp files and dirs
allow procmail_t procmail_tmp_t:dir create_dir_perms;
allow procmail_t procmail_tmp_t:file create_file_perms;
files_type(procmail_tmp_t)
files_tmp_filetrans(procmail_t, procmail_tmp_t, { file dir })
# Hide uninteresting things when debugging using enableaudit.pp
mta_dontaudit_rw_queue(procmail_t)
# ==============================================
# Procmail needs to call sendmail for forwarding
# ==============================================
# Read alternatives link (still not in policy)
corecmd_read_sbin_symlinks(procmail_t)
# Procmail occasionally signals sendmail, e.g. when it times out during
forwarding
allow procmail_t sendmail_t:process signal;
# Allow transition to sendmail
# This is in selinux-policy-2.2.34-2 onwards
# (may need similar code for other MTAs that can replace sendmail)
# sendmail_domtrans(procmail_t)
# ==============================================
# Procmail needs to be able to call clamassassin
# ==============================================
clamav_domtrans_clamscan(procmail_t)
Paul.
3:34 p.m.
New subject: postfix, procmail and SELinux - No Go
On Mon, 2006-06-19 at 21:13 +0100, Paul Howarth wrote:
On Mon, 2006-06-19 at 15:07 -0500, Marc Schwartz (via MN) wrote:
> On Mon, 2006-06-12 at 17:40 +0100, Paul Howarth wrote:
> > At this point it might be worth trying to remove some of the
"strange"
> > policy items, such as:
> >
> > allow postfix_master_t man_t:file getattr;
> >
> > and see what, if anything fails. By doing this we might get some insight
> > into what is actually happening, or if nothing breaks, we could
> > dontaudit it instead of allowing it.
> >
> > Paul.
>
>
> Paul,
>
> Apologies for the delay in my reply, as I was traveling (Vienna,
> Austria) all of last week and got back late yesterday. My schedule there
> ended up being busier than I expected and did not have a chance to get
> to this.
>
> I tried to make the above modification to mypostfix.te, however when
> going back to build all of the policy modules, I now get an error:
>
> Compiling targeted procmail module
> /usr/bin/checkmodule: loading policy configuration from
> tmp/procmail.tmp
> procmail.te:41:ERROR 'syntax error' at token 'clamscan_domtrans' on
line
> 57484:
> clamscan_domtrans(procmail_t)
> # ==============================================
> /usr/bin/checkmodule: error(s) encountered while parsing configuration
> make: *** [tmp/procmail.mod] Error 1
>
>
> Line 41 in procmail.te (as noted above) is:
>
> clamscan_domtrans(procmail_t)
>
>
> This error occurs even without the modification to mypostfix.te, so I am
> unclear as to what happened since the last time I was able to build them
> all.
>
> I plead jet lag here and suspect that you might rapidly recognize what
> is happening and have an easy fix. If you need me to check some files,
> let me know.
The interface name has changed in a recent selinux-policy update. New
procmail.te:
policy_module(procmail, 0.5.3)
require {
type procmail_t;
type sendmail_t;
};
# temp files
type procmail_tmp_t;
files_tmp_file(procmail_tmp_t)
# log files
type procmail_var_log_t;
logging_log_file(procmail_var_log_t)
# Write log to /var/log/procmail.log
allow procmail_t procmail_var_log_t:file create_file_perms;
allow procmail_t procmail_var_log_t:dir { rw_dir_perms setattr };
logging_log_filetrans(procmail_t,procmail_var_log_t, { file dir })
# Allow programs called from procmail to read/write temp files and dirs
allow procmail_t procmail_tmp_t:dir create_dir_perms;
allow procmail_t procmail_tmp_t:file create_file_perms;
files_type(procmail_tmp_t)
files_tmp_filetrans(procmail_t, procmail_tmp_t, { file dir })
# Hide uninteresting things when debugging using enableaudit.pp
mta_dontaudit_rw_queue(procmail_t)
# ==============================================
# Procmail needs to call sendmail for forwarding
# ==============================================
# Read alternatives link (still not in policy)
corecmd_read_sbin_symlinks(procmail_t)
# Procmail occasionally signals sendmail, e.g. when it times out during
forwarding
allow procmail_t sendmail_t:process signal;
# Allow transition to sendmail
# This is in selinux-policy-2.2.34-2 onwards
# (may need similar code for other MTAs that can replace sendmail)
# sendmail_domtrans(procmail_t)
# ==============================================
# Procmail needs to be able to call clamassassin
# ==============================================
clamav_domtrans_clamscan(procmail_t)
Thanks Paul!
OK, so the building goes OK, but now when I try to install the modules,
I get the following error:
# /usr/sbin/semodule -i procmail.pp
libsepol.class_copy_callback: procmail: Modules may not yet declare new classes.
libsemanage.semanage_link_sandbox: Link packages failed
/usr/sbin/semodule: Failed!
This occurs with each of the 5 modules.
Due to the recent change as well or is there something else that I need
to do before installing the new module(s)?
Thanks,
Marc
2:08 a.m.
New subject: postfix, procmail and SELinux - No Go
On Mon, 2006-06-19 at 15:34 -0500, Marc Schwartz (via MN) wrote:
On Mon, 2006-06-19 at 21:13 +0100, Paul Howarth wrote:
> On Mon, 2006-06-19 at 15:07 -0500, Marc Schwartz (via MN) wrote:
> > On Mon, 2006-06-12 at 17:40 +0100, Paul Howarth wrote:
> > > At this point it might be worth trying to remove some of the
"strange"
> > > policy items, such as:
> > >
> > > allow postfix_master_t man_t:file getattr;
> > >
> > > and see what, if anything fails. By doing this we might get some insight
> > > into what is actually happening, or if nothing breaks, we could
> > > dontaudit it instead of allowing it.
> > >
> > > Paul.
> >
> >
> > Paul,
> >
> > Apologies for the delay in my reply, as I was traveling (Vienna,
> > Austria) all of last week and got back late yesterday. My schedule there
> > ended up being busier than I expected and did not have a chance to get
> > to this.
> >
> > I tried to make the above modification to mypostfix.te, however when
> > going back to build all of the policy modules, I now get an error:
> >
> > Compiling targeted procmail module
> > /usr/bin/checkmodule: loading policy configuration from
> > tmp/procmail.tmp
> > procmail.te:41:ERROR 'syntax error' at token
'clamscan_domtrans' on line
> > 57484:
> > clamscan_domtrans(procmail_t)
> > # ==============================================
> > /usr/bin/checkmodule: error(s) encountered while parsing configuration
> > make: *** [tmp/procmail.mod] Error 1
> >
> >
> > Line 41 in procmail.te (as noted above) is:
> >
> > clamscan_domtrans(procmail_t)
> >
> >
> > This error occurs even without the modification to mypostfix.te, so I am
> > unclear as to what happened since the last time I was able to build them
> > all.
> >
> > I plead jet lag here and suspect that you might rapidly recognize what
> > is happening and have an easy fix. If you need me to check some files,
> > let me know.
>
> The interface name has changed in a recent selinux-policy update. New
> procmail.te:
>
> policy_module(procmail, 0.5.3)
>
> require {
> type procmail_t;
> type sendmail_t;
> };
>
> # temp files
> type procmail_tmp_t;
> files_tmp_file(procmail_tmp_t)
>
> # log files
> type procmail_var_log_t;
> logging_log_file(procmail_var_log_t)
>
> # Write log to /var/log/procmail.log
> allow procmail_t procmail_var_log_t:file create_file_perms;
> allow procmail_t procmail_var_log_t:dir { rw_dir_perms setattr };
> logging_log_filetrans(procmail_t,procmail_var_log_t, { file dir })
>
> # Allow programs called from procmail to read/write temp files and dirs
> allow procmail_t procmail_tmp_t:dir create_dir_perms;
> allow procmail_t procmail_tmp_t:file create_file_perms;
> files_type(procmail_tmp_t)
> files_tmp_filetrans(procmail_t, procmail_tmp_t, { file dir })
>
> # Hide uninteresting things when debugging using enableaudit.pp
> mta_dontaudit_rw_queue(procmail_t)
>
> # ==============================================
> # Procmail needs to call sendmail for forwarding
> # ==============================================
>
> # Read alternatives link (still not in policy)
> corecmd_read_sbin_symlinks(procmail_t)
>
> # Procmail occasionally signals sendmail, e.g. when it times out during
> forwarding
> allow procmail_t sendmail_t:process signal;
>
> # Allow transition to sendmail
> # This is in selinux-policy-2.2.34-2 onwards
> # (may need similar code for other MTAs that can replace sendmail)
> # sendmail_domtrans(procmail_t)
>
> # ==============================================
> # Procmail needs to be able to call clamassassin
> # ==============================================
> clamav_domtrans_clamscan(procmail_t)
Thanks Paul!
OK, so the building goes OK, but now when I try to install the modules,
I get the following error:
# /usr/sbin/semodule -i procmail.pp
libsepol.class_copy_callback: procmail: Modules may not yet declare new classes.
libsemanage.semanage_link_sandbox: Link packages failed
/usr/sbin/semodule: Failed!
This occurs with each of the 5 modules.
Due to the recent change as well or is there something else that I need
to do before installing the new module(s)?
Not sure what that is. Can you try rebuilding all of the modules?
# rm *.pp
# make
Paul.
7:04 a.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-06-20 at 08:08 +0100, Paul Howarth wrote:
On Mon, 2006-06-19 at 15:34 -0500, Marc Schwartz (via MN) wrote:
> Thanks Paul!
>
> OK, so the building goes OK, but now when I try to install the modules,
> I get the following error:
>
> # /usr/sbin/semodule -i procmail.pp
> libsepol.class_copy_callback: procmail: Modules may not yet declare new classes.
> libsemanage.semanage_link_sandbox: Link packages failed
> /usr/sbin/semodule: Failed!
>
>
> This occurs with each of the 5 modules.
>
> Due to the recent change as well or is there something else that I need
> to do before installing the new module(s)?
Not sure what that is. Can you try rebuilding all of the modules?
# rm *.pp
# make
Paul.
Also make sure that your selinux-policy package is fully up-to-date.
The error message suggests that your modules are bringing in newer class
definitions (via policy_module) that aren't defined in your base.pp,
which means your base.pp is out of date.
--
Stephen Smalley
National Security Agency
7:26 a.m.
New subject: postfix, procmail and SELinux - No Go
Stephen Smalley wrote:
On Tue, 2006-06-20 at 08:08 +0100, Paul Howarth wrote:
> On Mon, 2006-06-19 at 15:34 -0500, Marc Schwartz (via MN) wrote:
>> Thanks Paul!
>>
>> OK, so the building goes OK, but now when I try to install the modules,
>> I get the following error:
>>
>> # /usr/sbin/semodule -i procmail.pp
>> libsepol.class_copy_callback: procmail: Modules may not yet declare new classes.
>> libsemanage.semanage_link_sandbox: Link packages failed
>> /usr/sbin/semodule: Failed!
>>
>>
>> This occurs with each of the 5 modules.
>>
>> Due to the recent change as well or is there something else that I need
>> to do before installing the new module(s)?
> Not sure what that is. Can you try rebuilding all of the modules?
>
> # rm *.pp
> # make
>
> Paul.
Also make sure that your selinux-policy package is fully up-to-date.
The error message suggests that your modules are bringing in newer class
definitions (via policy_module) that aren't defined in your base.pp,
which means your base.pp is out of date.
How could this happen if the modules are being built on the same system
as they are being used on?
Paul.
7:54 a.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-06-20 at 13:26 +0100, Paul Howarth wrote:
Stephen Smalley wrote:
> On Tue, 2006-06-20 at 08:08 +0100, Paul Howarth wrote:
>> On Mon, 2006-06-19 at 15:34 -0500, Marc Schwartz (via MN) wrote:
>>> Thanks Paul!
>>>
>>> OK, so the building goes OK, but now when I try to install the modules,
>>> I get the following error:
>>>
>>> # /usr/sbin/semodule -i procmail.pp
>>> libsepol.class_copy_callback: procmail: Modules may not yet declare new
classes.
>>> libsemanage.semanage_link_sandbox: Link packages failed
>>> /usr/sbin/semodule: Failed!
>>>
>>>
>>> This occurs with each of the 5 modules.
>>>
>>> Due to the recent change as well or is there something else that I need
>>> to do before installing the new module(s)?
>> Not sure what that is. Can you try rebuilding all of the modules?
>>
>> # rm *.pp
>> # make
>>
>> Paul.
>
> Also make sure that your selinux-policy package is fully up-to-date.
> The error message suggests that your modules are bringing in newer class
> definitions (via policy_module) that aren't defined in your base.pp,
> which means your base.pp is out of date.
How could this happen if the modules are being built on the same system
as they are being used on?
Paul.
Good morning guys,
Thanks for the assistance.
Before building, I had done a 'make clean', so the *.pp files were
deleted.
This continues to be a problem this morning. The current versions of
the RPMS that I have are:
# rpm -qa | grep selinux
libselinux-1.30-1.fc5
libselinux-devel-1.30-1.fc5
libselinux-python-1.30-1.fc5
selinux-policy-targeted-2.2.43-4.fc5
selinux-policy-2.2.43-4.fc5
I ran a yum update this morning and no new updates were identified.
What is interesting, is if I try to remove any of the existing modules,
I get this:
# semodule -r myclam.pp
libsemanage.semanage_direct_remove: Module myclam.pp was not found.
semodule: Failed on myclam.pp!
Yet, the modules are listed:
# semodule -l
clamav 1.0.0
myclam 0.1.2
mydcc 0.1.3
mypostfix 0.1.0
mypyzor 0.1.3
procmail 0.5.0
And, if I try to upgrade the module:
# semodule -u myclam.pp
libsemanage.semanage_direct_upgrade: Previous module myclam is same or
newer.
semodule: Failed on myclam.pp!
It would suggest that the myclam.pp module is found, despite the error
in the remove attempt above.
Seems like something is hosed, but I don't have any intuition here.
If you would like me to attach the *.pp files in an offlist e-mail so
that you can review them, let me know.
Thanks,
Marc
8:05 a.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz wrote:
On Tue, 2006-06-20 at 13:26 +0100, Paul Howarth wrote:
> Stephen Smalley wrote:
>> On Tue, 2006-06-20 at 08:08 +0100, Paul Howarth wrote:
>>> On Mon, 2006-06-19 at 15:34 -0500, Marc Schwartz (via MN) wrote:
>>>> Thanks Paul!
>>>>
>>>> OK, so the building goes OK, but now when I try to install the modules,
>>>> I get the following error:
>>>>
>>>> # /usr/sbin/semodule -i procmail.pp
>>>> libsepol.class_copy_callback: procmail: Modules may not yet declare new
classes.
>>>> libsemanage.semanage_link_sandbox: Link packages failed
>>>> /usr/sbin/semodule: Failed!
>>>>
>>>>
>>>> This occurs with each of the 5 modules.
>>>>
>>>> Due to the recent change as well or is there something else that I need
>>>> to do before installing the new module(s)?
>>> Not sure what that is. Can you try rebuilding all of the modules?
>>>
>>> # rm *.pp
>>> # make
>>>
>>> Paul.
>> Also make sure that your selinux-policy package is fully up-to-date.
>> The error message suggests that your modules are bringing in newer class
>> definitions (via policy_module) that aren't defined in your base.pp,
>> which means your base.pp is out of date.
> How could this happen if the modules are being built on the same system
> as they are being used on?
>
> Paul.
Good morning guys,
Thanks for the assistance.
Before building, I had done a 'make clean', so the *.pp files were
deleted.
This continues to be a problem this morning. The current versions of
the RPMS that I have are:
# rpm -qa | grep selinux
libselinux-1.30-1.fc5
libselinux-devel-1.30-1.fc5
libselinux-python-1.30-1.fc5
selinux-policy-targeted-2.2.43-4.fc5
selinux-policy-2.2.43-4.fc5
I ran a yum update this morning and no new updates were identified.
What is interesting, is if I try to remove any of the existing modules,
I get this:
# semodule -r myclam.pp
libsemanage.semanage_direct_remove: Module myclam.pp was not found.
semodule: Failed on myclam.pp!
Yet, the modules are listed:
# semodule -l
clamav 1.0.0
myclam 0.1.2
mydcc 0.1.3
mypostfix 0.1.0
mypyzor 0.1.3
procmail 0.5.0
And, if I try to upgrade the module:
# semodule -u myclam.pp
libsemanage.semanage_direct_upgrade: Previous module myclam is same or
newer.
semodule: Failed on myclam.pp!
It would suggest that the myclam.pp module is found, despite the error
in the remove attempt above.
Seems like something is hosed, but I don't have any intuition here.
If you would like me to attach the *.pp files in an offlist e-mail so
that you can review them, let me know.
There's something very curious going on here. With
selinux-policy-2.2.43-4.fc5 you should have clamav module version 1.0.1.
Try this:
# yum install yum-utils
# yumdownloader selinux-policy selinux-policy-targeted
# rpm -Uvh --replacefiles --replacepkgs \
selinux-policy-2.2.43-4.fc5.noarch.rpm \
selinux-policy-targeted-2.2.43-4.fc5.noarch.rpm
# semodule -l
Paul.
8:26 a.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-06-20 at 14:05 +0100, Paul Howarth wrote:
Marc Schwartz wrote:
<snip>
There's something very curious going on here. With
selinux-policy-2.2.43-4.fc5 you should have clamav module version 1.0.1.
Try this:
# yum install yum-utils
# yumdownloader selinux-policy selinux-policy-targeted
# rpm -Uvh --replacefiles --replacepkgs \
selinux-policy-2.2.43-4.fc5.noarch.rpm \
selinux-policy-targeted-2.2.43-4.fc5.noarch.rpm
# semodule -l
Paul.
OK. We seem to have solved the module install problem (save one) with
the above process.
# semodule -l
amavis 1.0.4
clamav 1.0.1
mydcc 0.1.3
mypostfix 0.1.0
mypyzor 0.1.3
procmail 0.5.3
pyzor 1.0.1
Note that now the amavis module is indicated (I installed amavis after
the discussion with Nicolas, but have not configured it yet, pending
this whole process).
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?
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;
Marc
8:37 a.m.
New subject: postfix, procmail and SELinux - No Go
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;
Marc
--
Stephen Smalley
National Security Agency
9:47 a.m.
New subject: postfix, procmail and SELinux - No Go
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?
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.
Marc
10:12 a.m.
New subject: postfix, procmail and SELinux - No Go
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;
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.
Paul.
10:39 a.m.
New subject: postfix, procmail and SELinux - No Go
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?
> 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
Thanks,
Marc
10:59 a.m.
New subject: postfix, procmail and SELinux - No Go
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.
11:27 a.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-06-20 at 16:59 +0100, Paul Howarth wrote:
Marc Schwartz (via MN) wrote:
> On Tue, 2006-06-20 at 16:12 +0100, Paul Howarth wrote:
<snip>
>> 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.
No problem. Just wanted to be sure.
<snip>
> 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.
As Murphy's Law would dictate, no spam with pyzor hits since updating
the policies. The two or three that I have had so far, have no hits on
any of the remote tests.
As soon as I can confirm, I will post back.
Thanks,
Marc
12:12 p.m.
New subject: postfix, procmail and SELinux - No Go
Le mardi 20 juin 2006 à 11:27 -0500, Marc Schwartz (via MN) a écrit :
As Murphy's Law would dictate, no spam with pyzor hits since
updating
the policies. The two or three that I have had so far, have no hits on
any of the remote tests.
You may try to feed the system one of the test spam patterns/messages
bundled with SA. I think they were in razor and pyzor db (because you
can't rely on spam hitting you at the right moment;)
Regards,
--
Nicolas Mailhot
1:20 p.m.
New subject: postfix, procmail and SELinux - No Go
Nicolas Mailhot wrote:
Le mardi 20 juin 2006 à 11:27 -0500, Marc Schwartz (via MN) a écrit
:
> As Murphy's Law would dictate, no spam with pyzor hits since updating
> the policies. The two or three that I have had so far, have no hits on
> any of the remote tests.
You may try to feed the system one of the test spam patterns/messages
bundled with SA. I think they were in razor and pyzor db (because you
can't rely on spam hitting you at the right moment;)
Nicolas,
Yes, there is a spam test msg (gtube) that is bundled.
One can use:
cat /usr/share/doc/spamassassin-3.1.3/sample-spam.txt | spamassassin -D
Thanks for the pointer. This does check, pyzor, razor2 and DCC.
Regards,
Marc
1:10 p.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-06-20 at 11:27 -0500, Marc Schwartz (via MN) wrote:
On Tue, 2006-06-20 at 16:59 +0100, Paul Howarth wrote:
> > 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.
As Murphy's Law would dictate, no spam with pyzor hits since updating
the policies. The two or three that I have had so far, have no hits on
any of the remote tests.
As soon as I can confirm, I will post back.
Thanks,
Marc
Just to confirm that Pyzor, Razor2 and DCC are indeed working.
So perhaps these msgs can be dontaudit-ed.
Marc
2:20 a.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-06-20 at 13:10 -0500, Marc Schwartz (via MN) wrote:
On Tue, 2006-06-20 at 11:27 -0500, Marc Schwartz (via MN) wrote:
> On Tue, 2006-06-20 at 16:59 +0100, Paul Howarth wrote:
> > > 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.
>
> As Murphy's Law would dictate, no spam with pyzor hits since updating
> the policies. The two or three that I have had so far, have no hits on
> any of the remote tests.
>
> As soon as I can confirm, I will post back.
>
> Thanks,
>
> Marc
Just to confirm that Pyzor, Razor2 and DCC are indeed working.
So perhaps these msgs can be dontaudit-ed.
OK, here's an updated version of mypyzor.te:
policy_module(mypyzor, 0.1.3)
require {
type pyzor_t;
type pyzor_exec_t;
type pyzor_port_t;
type spamd_t;
};
# temp files
type pyzor_tmp_t;
files_tmp_file(pyzor_tmp_t)
# Allow pyzor to create and use temp files and dirs
allow pyzor_t pyzor_tmp_t:dir create_dir_perms;
allow pyzor_t pyzor_tmp_t:file create_file_perms;
files_type(pyzor_tmp_t)
files_tmp_filetrans(pyzor_t, pyzor_tmp_t, { file dir })
# Allow pyzor to read config (and any other file...)
# from user home directories
userdom_read_unpriv_users_home_content_files(pyzor_t)
# Allow pyzor to read /dev/urandom
dev_read_urand(pyzor_t)
# Allow pyzor to send and receive pyzor messages!
allow pyzor_t pyzor_port_t:udp_socket send_msg;
allow pyzor_t pyzor_port_t:udp_socket recv_msg;
# Allow spamd to signal pyzor (kill/hup ?)
allow spamd_t pyzor_t:process signal;
# This doesn't seem to break anything
dontaudit spamd_t pyzor_exec_t:file getattr;
# Allow pyzor to ...?
corecmd_search_bin(pyzor_t)
kernel_read_kernel_sysctls(pyzor_t)
# It does a getattr on /usr/bin/time for reasons unknown...
# Would be nice to know if changing these from
# allow to dontaudit causes any breakage
allow pyzor_t bin_t:dir getattr;
allow pyzor_t bin_t:file getattr;
# Pyzor/python probably doesn't need to be able to read /proc/meminfo
kernel_dontaudit_list_proc(pyzor_t)
kernel_dontaudit_read_system_state(pyzor_t)
Paul.
9:29 a.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-21 at 08:20 +0100, Paul Howarth wrote:
OK, here's an updated version of mypyzor.te:
policy_module(mypyzor, 0.1.3)
require {
type pyzor_t;
type pyzor_exec_t;
type pyzor_port_t;
type spamd_t;
};
# temp files
type pyzor_tmp_t;
files_tmp_file(pyzor_tmp_t)
# Allow pyzor to create and use temp files and dirs
allow pyzor_t pyzor_tmp_t:dir create_dir_perms;
allow pyzor_t pyzor_tmp_t:file create_file_perms;
files_type(pyzor_tmp_t)
files_tmp_filetrans(pyzor_t, pyzor_tmp_t, { file dir })
# Allow pyzor to read config (and any other file...)
# from user home directories
userdom_read_unpriv_users_home_content_files(pyzor_t)
# Allow pyzor to read /dev/urandom
dev_read_urand(pyzor_t)
# Allow pyzor to send and receive pyzor messages!
allow pyzor_t pyzor_port_t:udp_socket send_msg;
allow pyzor_t pyzor_port_t:udp_socket recv_msg;
# Allow spamd to signal pyzor (kill/hup ?)
allow spamd_t pyzor_t:process signal;
# This doesn't seem to break anything
dontaudit spamd_t pyzor_exec_t:file getattr;
# Allow pyzor to ...?
corecmd_search_bin(pyzor_t)
kernel_read_kernel_sysctls(pyzor_t)
# It does a getattr on /usr/bin/time for reasons unknown...
# Would be nice to know if changing these from
# allow to dontaudit causes any breakage
allow pyzor_t bin_t:dir getattr;
allow pyzor_t bin_t:file getattr;
# Pyzor/python probably doesn't need to be able to read /proc/meminfo
kernel_dontaudit_list_proc(pyzor_t)
kernel_dontaudit_read_system_state(pyzor_t)
Paul,
I have made the change and all seems well so far.
Note that the version you have above is the same as the prior version.
So I bumped it 0.2.0 arbitrarily, unless you have an alternative
versioning schema that you want to stay with.
Thanks,
Marc
9:43 a.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz (via MN) wrote:
On Wed, 2006-06-21 at 08:20 +0100, Paul Howarth wrote:
> OK, here's an updated version of mypyzor.te:
>
> policy_module(mypyzor, 0.1.3)
>
> require {
> type pyzor_t;
> type pyzor_exec_t;
> type pyzor_port_t;
> type spamd_t;
> };
>
> # temp files
> type pyzor_tmp_t;
> files_tmp_file(pyzor_tmp_t)
>
> # Allow pyzor to create and use temp files and dirs
> allow pyzor_t pyzor_tmp_t:dir create_dir_perms;
> allow pyzor_t pyzor_tmp_t:file create_file_perms;
> files_type(pyzor_tmp_t)
> files_tmp_filetrans(pyzor_t, pyzor_tmp_t, { file dir })
>
> # Allow pyzor to read config (and any other file...)
> # from user home directories
> userdom_read_unpriv_users_home_content_files(pyzor_t)
>
> # Allow pyzor to read /dev/urandom
> dev_read_urand(pyzor_t)
>
> # Allow pyzor to send and receive pyzor messages!
> allow pyzor_t pyzor_port_t:udp_socket send_msg;
> allow pyzor_t pyzor_port_t:udp_socket recv_msg;
>
> # Allow spamd to signal pyzor (kill/hup ?)
> allow spamd_t pyzor_t:process signal;
>
> # This doesn't seem to break anything
> dontaudit spamd_t pyzor_exec_t:file getattr;
>
> # Allow pyzor to ...?
> corecmd_search_bin(pyzor_t)
> kernel_read_kernel_sysctls(pyzor_t)
> # It does a getattr on /usr/bin/time for reasons unknown...
> # Would be nice to know if changing these from
> # allow to dontaudit causes any breakage
> allow pyzor_t bin_t:dir getattr;
> allow pyzor_t bin_t:file getattr;
>
> # Pyzor/python probably doesn't need to be able to read /proc/meminfo
> kernel_dontaudit_list_proc(pyzor_t)
> kernel_dontaudit_read_system_state(pyzor_t)
Paul,
I have made the change and all seems well so far.
Note that the version you have above is the same as the prior version.
So I bumped it 0.2.0 arbitrarily, unless you have an alternative
versioning schema that you want to stay with.
Whoops. I've updated my copy now so we should stay in sync. Could you
try bumping the version again and removing these lines:
allow pyzor_t bin_t:dir getattr;
allow pyzor_t bin_t:file getattr;
I'd like to see if things still work. If so, we can dontaudit these
instead of allowing them.
Similarly, can you try removing the mypostfix module (semodule -r
mypostfix) and see if things still work? The strange AVC of
postfix_master_t reading the manpage should reappear and it would be
interesting to see if it broke in some way in enforcing mode.
Paul.
10:27 a.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-21 at 15:43 +0100, Paul Howarth wrote:
Marc Schwartz (via MN) wrote:
> On Wed, 2006-06-21 at 08:20 +0100, Paul Howarth wrote:
>> OK, here's an updated version of mypyzor.te:
>>
>> policy_module(mypyzor, 0.1.3)
>>
>> require {
>> type pyzor_t;
>> type pyzor_exec_t;
>> type pyzor_port_t;
>> type spamd_t;
>> };
>>
>> # temp files
>> type pyzor_tmp_t;
>> files_tmp_file(pyzor_tmp_t)
>>
>> # Allow pyzor to create and use temp files and dirs
>> allow pyzor_t pyzor_tmp_t:dir create_dir_perms;
>> allow pyzor_t pyzor_tmp_t:file create_file_perms;
>> files_type(pyzor_tmp_t)
>> files_tmp_filetrans(pyzor_t, pyzor_tmp_t, { file dir })
>>
>> # Allow pyzor to read config (and any other file...)
>> # from user home directories
>> userdom_read_unpriv_users_home_content_files(pyzor_t)
>>
>> # Allow pyzor to read /dev/urandom
>> dev_read_urand(pyzor_t)
>>
>> # Allow pyzor to send and receive pyzor messages!
>> allow pyzor_t pyzor_port_t:udp_socket send_msg;
>> allow pyzor_t pyzor_port_t:udp_socket recv_msg;
>>
>> # Allow spamd to signal pyzor (kill/hup ?)
>> allow spamd_t pyzor_t:process signal;
>>
>> # This doesn't seem to break anything
>> dontaudit spamd_t pyzor_exec_t:file getattr;
>>
>> # Allow pyzor to ...?
>> corecmd_search_bin(pyzor_t)
>> kernel_read_kernel_sysctls(pyzor_t)
>> # It does a getattr on /usr/bin/time for reasons unknown...
>> # Would be nice to know if changing these from
>> # allow to dontaudit causes any breakage
>> allow pyzor_t bin_t:dir getattr;
>> allow pyzor_t bin_t:file getattr;
>>
>> # Pyzor/python probably doesn't need to be able to read /proc/meminfo
>> kernel_dontaudit_list_proc(pyzor_t)
>> kernel_dontaudit_read_system_state(pyzor_t)
>
> Paul,
>
> I have made the change and all seems well so far.
>
> Note that the version you have above is the same as the prior version.
> So I bumped it 0.2.0 arbitrarily, unless you have an alternative
> versioning schema that you want to stay with.
Whoops. I've updated my copy now so we should stay in sync. Could you
try bumping the version again and removing these lines:
allow pyzor_t bin_t:dir getattr;
allow pyzor_t bin_t:file getattr;
I'd like to see if things still work. If so, we can dontaudit these
instead of allowing them.
Similarly, can you try removing the mypostfix module (semodule -r
mypostfix) and see if things still work? The strange AVC of
postfix_master_t reading the manpage should reappear and it would be
interesting to see if it broke in some way in enforcing mode.
OK. Commented out the above lines in mypyzor.te (v 0.2.1) and removed
mypostfix.
The current modules then are:
# semodule -l
amavis 1.0.4
clamav 1.0.1
myclamscan 0.2.0
mydcc 0.1.3
mypyzor 0.2.1
procmail 0.5.3
pyzor 1.0.1
No msgs are being reported by avclist subsequent to the above changes.
Specifically nothing wrt the postfix manpage weirdness.
All else appears to be OK so far.
Marc
10:53 a.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz (via MN) wrote:
On Wed, 2006-06-21 at 15:43 +0100, Paul Howarth wrote:
> Marc Schwartz (via MN) wrote:
>> On Wed, 2006-06-21 at 08:20 +0100, Paul Howarth wrote:
>>> OK, here's an updated version of mypyzor.te:
>>>
>>> policy_module(mypyzor, 0.1.3)
>>>
>>> require {
>>> type pyzor_t;
>>> type pyzor_exec_t;
>>> type pyzor_port_t;
>>> type spamd_t;
>>> };
>>>
>>> # temp files
>>> type pyzor_tmp_t;
>>> files_tmp_file(pyzor_tmp_t)
>>>
>>> # Allow pyzor to create and use temp files and dirs
>>> allow pyzor_t pyzor_tmp_t:dir create_dir_perms;
>>> allow pyzor_t pyzor_tmp_t:file create_file_perms;
>>> files_type(pyzor_tmp_t)
>>> files_tmp_filetrans(pyzor_t, pyzor_tmp_t, { file dir })
>>>
>>> # Allow pyzor to read config (and any other file...)
>>> # from user home directories
>>> userdom_read_unpriv_users_home_content_files(pyzor_t)
>>>
>>> # Allow pyzor to read /dev/urandom
>>> dev_read_urand(pyzor_t)
>>>
>>> # Allow pyzor to send and receive pyzor messages!
>>> allow pyzor_t pyzor_port_t:udp_socket send_msg;
>>> allow pyzor_t pyzor_port_t:udp_socket recv_msg;
>>>
>>> # Allow spamd to signal pyzor (kill/hup ?)
>>> allow spamd_t pyzor_t:process signal;
>>>
>>> # This doesn't seem to break anything
>>> dontaudit spamd_t pyzor_exec_t:file getattr;
>>>
>>> # Allow pyzor to ...?
>>> corecmd_search_bin(pyzor_t)
>>> kernel_read_kernel_sysctls(pyzor_t)
>>> # It does a getattr on /usr/bin/time for reasons unknown...
>>> # Would be nice to know if changing these from
>>> # allow to dontaudit causes any breakage
>>> allow pyzor_t bin_t:dir getattr;
>>> allow pyzor_t bin_t:file getattr;
>>>
>>> # Pyzor/python probably doesn't need to be able to read /proc/meminfo
>>> kernel_dontaudit_list_proc(pyzor_t)
>>> kernel_dontaudit_read_system_state(pyzor_t)
>> Paul,
>>
>> I have made the change and all seems well so far.
>>
>> Note that the version you have above is the same as the prior version.
>> So I bumped it 0.2.0 arbitrarily, unless you have an alternative
>> versioning schema that you want to stay with.
> Whoops. I've updated my copy now so we should stay in sync. Could you
> try bumping the version again and removing these lines:
>
> allow pyzor_t bin_t:dir getattr;
> allow pyzor_t bin_t:file getattr;
>
> I'd like to see if things still work. If so, we can dontaudit these
> instead of allowing them.
>
> Similarly, can you try removing the mypostfix module (semodule -r
> mypostfix) and see if things still work? The strange AVC of
> postfix_master_t reading the manpage should reappear and it would be
> interesting to see if it broke in some way in enforcing mode.
OK. Commented out the above lines in mypyzor.te (v 0.2.1) and removed
mypostfix.
The current modules then are:
# semodule -l
amavis 1.0.4
clamav 1.0.1
myclamscan 0.2.0
mydcc 0.1.3
mypyzor 0.2.1
procmail 0.5.3
pyzor 1.0.1
No msgs are being reported by avclist subsequent to the above changes.
Specifically nothing wrt the postfix manpage weirdness.
All else appears to be OK so far.
Can you try restarting postfix? I think the manpage thing happened at
that point.
Once that's done I'd like to try out the dcc and razor modules that are
now in rawhide. That will involve going back to permissive mode for a
while though.
Paul.
Paul.
11:33 a.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-21 at 16:53 +0100, Paul Howarth wrote:
Marc Schwartz (via MN) wrote:
>
<snip>
>
> The current modules then are:
>
> # semodule -l
> amavis 1.0.4
> clamav 1.0.1
> myclamscan 0.2.0
> mydcc 0.1.3
> mypyzor 0.2.1
> procmail 0.5.3
> pyzor 1.0.1
>
>
> No msgs are being reported by avclist subsequent to the above changes.
> Specifically nothing wrt the postfix manpage weirdness.
>
> All else appears to be OK so far.
Can you try restarting postfix? I think the manpage thing happened at
that point.
Interesting. Recalling that, I had re-booted before my reply above and
had no msgs. However doing a service restart post-boot using
system-config-services, I get:
type=AVC msg=audit(1150906621.693:641): avc: denied { read } for pid=12784
comm="postfix" name=".fonts.cache-2" dev=hdc7 ino=427877
scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:object_r:user_home_t:s0
tclass=file
type=SYSCALL msg=audit(1150906621.693:641): arch=40000003 syscall=11 success=yes exit=0
a0=9e14f80 a1=9dfb478 a2=9e14f98 a3=9e14e68 items=2 pid=12784 auid=500 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="postfix"
exe="/usr/sbin/postfix"
type=AVC_PATH msg=audit(1150906621.693:641):
path="/root/.rh-fontconfig/.fonts.cache-2"
type=CWD msg=audit(1150906621.693:641): cwd="/"
type=PATH msg=audit(1150906621.693:641): item=0 name="/usr/sbin/postfix"
flags=101 inode=3132499 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1150906621.693:641): item=1 flags=101 inode=754491 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1150906621.829:642): avc: denied { read } for pid=12796
comm="postfix" name=".fonts.cache-2" dev=hdc7 ino=427877
scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:object_r:user_home_t:s0
tclass=file
type=SYSCALL msg=audit(1150906621.829:642): arch=40000003 syscall=11 success=yes exit=0
a0=9e15318 a1=9e00e50 a2=9e14f98 a3=9e14d00 items=2 pid=12796 auid=500 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="postfix"
exe="/usr/sbin/postfix"
type=AVC_PATH msg=audit(1150906621.829:642):
path="/root/.rh-fontconfig/.fonts.cache-2"
type=CWD msg=audit(1150906621.829:642): cwd="/"
type=PATH msg=audit(1150906621.829:642): item=0 name="/usr/sbin/postfix"
flags=101 inode=3132499 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1150906621.829:642): item=1 flags=101 inode=754491 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00
Which seems to not involve the man pages, but font caches for some
reason.
If I just use '/usr/sbin/postfix stop' follow by '... start', I get no
msgs at all, which is consistent with a fresh boot.
Once that's done I'd like to try out the dcc and razor
modules that are
now in rawhide. That will involve going back to permissive mode for a
while though.
No problem.
Marc
12:33 p.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz (via MN) wrote:
On Wed, 2006-06-21 at 16:53 +0100, Paul Howarth wrote:
> Marc Schwartz (via MN) wrote:
<snip>
>> The current modules then are:
>>
>> # semodule -l
>> amavis 1.0.4
>> clamav 1.0.1
>> myclamscan 0.2.0
>> mydcc 0.1.3
>> mypyzor 0.2.1
>> procmail 0.5.3
>> pyzor 1.0.1
>>
>>
>> No msgs are being reported by avclist subsequent to the above changes.
>> Specifically nothing wrt the postfix manpage weirdness.
>>
>> All else appears to be OK so far.
> Can you try restarting postfix? I think the manpage thing happened at
> that point.
Interesting. Recalling that, I had re-booted before my reply above and
had no msgs. However doing a service restart post-boot using
system-config-services, I get:
type=AVC msg=audit(1150906621.693:641): avc: denied { read } for pid=12784
comm="postfix" name=".fonts.cache-2" dev=hdc7 ino=427877
scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:object_r:user_home_t:s0
tclass=file
type=SYSCALL msg=audit(1150906621.693:641): arch=40000003 syscall=11 success=yes exit=0
a0=9e14f80 a1=9dfb478 a2=9e14f98 a3=9e14e68 items=2 pid=12784 auid=500 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="postfix"
exe="/usr/sbin/postfix"
type=AVC_PATH msg=audit(1150906621.693:641):
path="/root/.rh-fontconfig/.fonts.cache-2"
type=CWD msg=audit(1150906621.693:641): cwd="/"
type=PATH msg=audit(1150906621.693:641): item=0 name="/usr/sbin/postfix"
flags=101 inode=3132499 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1150906621.693:641): item=1 flags=101 inode=754491 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1150906621.829:642): avc: denied { read } for pid=12796
comm="postfix" name=".fonts.cache-2" dev=hdc7 ino=427877
scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:object_r:user_home_t:s0
tclass=file
type=SYSCALL msg=audit(1150906621.829:642): arch=40000003 syscall=11 success=yes exit=0
a0=9e15318 a1=9e00e50 a2=9e14f98 a3=9e14d00 items=2 pid=12796 auid=500 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="postfix"
exe="/usr/sbin/postfix"
type=AVC_PATH msg=audit(1150906621.829:642):
path="/root/.rh-fontconfig/.fonts.cache-2"
type=CWD msg=audit(1150906621.829:642): cwd="/"
type=PATH msg=audit(1150906621.829:642): item=0 name="/usr/sbin/postfix"
flags=101 inode=3132499 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1150906621.829:642): item=1 flags=101 inode=754491 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00
Which seems to not involve the man pages, but font caches for some
reason.
That's just completely weird. I wonder if it's a filehandle left open
from somewhere. I wonder how to diagnose this further? Since the types
aren't consistent, they can't even be dontaudit-ed. I trust nothing has
broken anyway?
> Once that's done I'd like to try out the dcc and razor
modules that are
> now in rawhide. That will involve going back to permissive mode for a
> while though.
OK, I've attached the dcc and razor policy files from the current FC5
selinux-policy package. Try installing those, put selinux in permissive
mode, do a restorecon on all of your dcc and razor files/directories and
see what happens.
Paul.
/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)
## <summary>Distributed checksum clearinghouse spam filtering</summary>
########################################
## <summary>
## Execute cdcc in the cdcc domain.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed access.
## </summary>
## </param>
#
interface(`dcc_domtrans_cdcc',`
gen_require(`
type cdcc_t, cdcc_exec_t;
')
corecmd_search_sbin($1)
domain_auto_trans($1,cdcc_exec_t,cdcc_t)
allow cdcc_t $1:fd use;
allow cdcc_t $1:fifo_file rw_file_perms;
allow cdcc_t $1:process sigchld;
')
########################################
## <summary>
## Execute cdcc in the cdcc domain, and
## allow the specified role the cdcc domain.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed access.
## </summary>
## </param>
## <param name="role">
## <summary>
## The role to be allowed the cdcc domain.
## </summary>
## </param>
## <param name="terminal">
## <summary>
## The type of the terminal allow the cdcc domain to use.
## </summary>
## </param>
#
interface(`dcc_run_cdcc',`
gen_require(`
type cdcc_t;
')
dcc_domtrans_cdcc($1)
role $2 types cdcc_t;
allow cdcc_t $3:chr_file rw_term_perms;
')
########################################
## <summary>
## Execute dcc_client in the dcc_client domain.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed access.
## </summary>
## </param>
#
interface(`dcc_domtrans_client',`
gen_require(`
type dcc_client_t, dcc_client_exec_t;
')
corecmd_search_sbin($1)
domain_auto_trans($1,dcc_client_exec_t,dcc_client_t)
allow dcc_client_t $1:fd use;
allow dcc_client_t $1:fifo_file rw_file_perms;
allow dcc_client_t $1:process sigchld;
')
########################################
## <summary>
## Execute dcc_client in the dcc_client domain, and
## allow the specified role the dcc_client domain.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed access.
## </summary>
## </param>
## <param name="role">
## <summary>
## The role to be allowed the dcc_client domain.
## </summary>
## </param>
## <param name="terminal">
## <summary>
## The type of the terminal allow the dcc_client domain to use.
## </summary>
## </param>
#
interface(`dcc_run_client',`
gen_require(`
type dcc_client_t;
')
dcc_domtrans_client($1)
role $2 types dcc_client_t;
allow dcc_client_t $3:chr_file rw_term_perms;
')
########################################
## <summary>
## Execute dbclean in the dcc_dbclean domain.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed access.
## </summary>
## </param>
#
interface(`dcc_domtrans_dbclean',`
gen_require(`
type dcc_dbclean_t, dcc_dbclean_exec_t;
')
corecmd_search_sbin($1)
domain_auto_trans($1,dcc_dbclean_exec_t,dcc_dbclean_t)
allow dcc_dbclean_t $1:fd use;
allow dcc_dbclean_t $1:fifo_file rw_file_perms;
allow dcc_dbclean_t $1:process sigchld;
')
########################################
## <summary>
## Execute dbclean in the dcc_dbclean domain, and
## allow the specified role the dcc_dbclean domain.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed access.
## </summary>
## </param>
## <param name="role">
## <summary>
## The role to be allowed the dcc_dbclean domain.
## </summary>
## </param>
## <param name="terminal">
## <summary>
## The type of the terminal allow the dcc_dbclean domain to use.
## </summary>
## </param>
#
interface(`dcc_run_dbclean',`
gen_require(`
type dcc_dbclean_t;
')
dcc_domtrans_dbclean($1)
role $2 types dcc_dbclean_t;
allow dcc_dbclean_t $3:chr_file rw_term_perms;
')
########################################
## <summary>
## Connect to dccifd over a unix domain stream socket.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed access.
## </summary>
## </param>
#
interface(`dcc_stream_connect_dccifd',`
gen_require(`
type dcc_var_t, dccifd_var_run_t, dccifd_t;
')
files_search_var($1)
allow $1 dcc_var_t:dir search;
allow $1 dccifd_var_run_t:sock_file { getattr write };
allow $1 dccifd_t:unix_stream_socket connectto;
')
policy_module(dcc,1.0.0)
########################################
#
# Declarations
#
type cdcc_t;
type cdcc_exec_t;
domain_type(cdcc_t)
domain_entry_file(cdcc_t,cdcc_exec_t)
role system_r types cdcc_t;
type cdcc_tmp_t;
files_tmp_file(cdcc_tmp_t)
type dcc_client_t;
type dcc_client_exec_t;
domain_type(dcc_client_t)
domain_entry_file(dcc_client_t,dcc_client_exec_t)
role system_r types dcc_client_t;
type dcc_client_map_t;
files_type(dcc_client_map_t)
type dcc_client_tmp_t;
files_tmp_file(dcc_client_tmp_t)
type dcc_dbclean_t;
type dcc_dbclean_exec_t;
domain_type(dcc_dbclean_t)
domain_entry_file(dcc_dbclean_t,dcc_dbclean_exec_t)
role system_r types dcc_dbclean_t;
type dcc_dbclean_tmp_t;
files_tmp_file(dcc_dbclean_tmp_t)
type dcc_var_t;
files_type(dcc_var_t)
type dcc_var_run_t;
files_type(dcc_var_run_t)
type dccd_t;
type dccd_exec_t;
init_daemon_domain(dccd_t,dccd_exec_t)
type dccd_tmp_t;
files_tmp_file(dccd_tmp_t)
type dccd_var_run_t;
files_pid_file(dccd_var_run_t)
type dccifd_t;
type dccifd_exec_t;
init_daemon_domain(dccifd_t,dccifd_exec_t)
type dccifd_tmp_t;
files_tmp_file(dccifd_tmp_t)
type dccifd_var_run_t;
files_pid_file(dccifd_var_run_t)
type dccm_t;
type dccm_exec_t;
init_daemon_domain(dccm_t,dccm_exec_t)
type dccm_tmp_t;
files_tmp_file(dccm_tmp_t)
type dccm_var_run_t;
files_pid_file(dccm_var_run_t)
# NOTE: DCC has writeable files in /etc/dcc that should probably be in
# /var/lib/dcc. For now this policy supports both directories being
# writable.
# cjp: dccifd and dccm should be merged, as
# they have the same rules.
########################################
#
# dcc daemon controller local policy
#
allow cdcc_t self:capability setuid;
allow cdcc_t self:unix_dgram_socket create_socket_perms;
allow cdcc_t self:udp_socket create_socket_perms;
allow cdcc_t cdcc_tmp_t:dir manage_dir_perms;
allow cdcc_t cdcc_tmp_t:file create_file_perms;
files_tmp_filetrans(cdcc_t, cdcc_tmp_t, { file dir })
allow cdcc_t dcc_client_map_t:file rw_file_perms;
# Access files in /var/dcc. The map file can be updated
allow cdcc_t dcc_var_t:dir r_dir_perms;
allow cdcc_t dcc_var_t:file r_file_perms;
allow cdcc_t dcc_var_t:lnk_file { getattr read };
corenet_non_ipsec_sendrecv(cdcc_t)
corenet_udp_sendrecv_generic_if(cdcc_t)
corenet_udp_sendrecv_all_nodes(cdcc_t)
corenet_udp_sendrecv_all_ports(cdcc_t)
files_read_etc_files(cdcc_t)
files_read_etc_runtime_files(cdcc_t)
libs_use_ld_so(cdcc_t)
libs_use_shared_libs(cdcc_t)
logging_send_syslog_msg(cdcc_t)
miscfiles_read_localization(cdcc_t)
sysnet_read_config(cdcc_t)
sysnet_dns_name_resolve(cdcc_t)
optional_policy(`
nscd_socket_use(cdcc_t)
')
########################################
#
# dcc procmail interface local policy
#
allow dcc_client_t self:capability setuid;
allow dcc_client_t self:unix_dgram_socket create_socket_perms;
allow dcc_client_t self:udp_socket create_socket_perms;
allow dcc_client_t dcc_client_map_t:file rw_file_perms;
allow dcc_client_t dcc_client_tmp_t:dir manage_dir_perms;
allow dcc_client_t dcc_client_tmp_t:file create_file_perms;
files_tmp_filetrans(dcc_client_t, dcc_client_tmp_t, { file dir })
# Access files in /var/dcc. The map file can be updated
allow dcc_client_t dcc_var_t:dir r_dir_perms;
allow dcc_client_t dcc_var_t:file r_file_perms;
allow dcc_client_t dcc_var_t:lnk_file { getattr read };
corenet_non_ipsec_sendrecv(dcc_client_t)
corenet_udp_sendrecv_generic_if(dcc_client_t)
corenet_udp_sendrecv_all_nodes(dcc_client_t)
corenet_udp_sendrecv_all_ports(dcc_client_t)
files_read_etc_files(dcc_client_t)
files_read_etc_runtime_files(dcc_client_t)
libs_use_ld_so(dcc_client_t)
libs_use_shared_libs(dcc_client_t)
logging_send_syslog_msg(dcc_client_t)
miscfiles_read_localization(dcc_client_t)
sysnet_read_config(dcc_client_t)
sysnet_dns_name_resolve(dcc_client_t)
optional_policy(`
nscd_socket_use(dcc_client_t)
')
########################################
#
# Database cleanup tool local policy
#
allow dcc_dbclean_t self:unix_dgram_socket create_socket_perms;
allow dcc_dbclean_t self:udp_socket create_socket_perms;
allow dcc_dbclean_t dcc_client_map_t:file rw_file_perms;
allow dcc_dbclean_t dcc_dbclean_tmp_t:dir manage_dir_perms;
allow dcc_dbclean_t dcc_dbclean_tmp_t:file create_file_perms;
files_tmp_filetrans(dcc_dbclean_t, dcc_dbclean_tmp_t, { file dir })
allow dcc_dbclean_t dcc_var_t:dir manage_dir_perms;
allow dcc_dbclean_t dcc_var_t:file manage_file_perms;
allow dcc_dbclean_t dcc_var_t:lnk_file create_lnk_perms;
kernel_read_system_state(dcc_dbclean_t)
corenet_non_ipsec_sendrecv(dcc_dbclean_t)
corenet_udp_sendrecv_generic_if(dcc_dbclean_t)
corenet_udp_sendrecv_all_nodes(dcc_dbclean_t)
corenet_udp_sendrecv_all_ports(dcc_dbclean_t)
files_read_etc_files(dcc_dbclean_t)
files_read_etc_runtime_files(dcc_dbclean_t)
libs_use_ld_so(dcc_dbclean_t)
libs_use_shared_libs(dcc_dbclean_t)
logging_send_syslog_msg(dcc_dbclean_t)
miscfiles_read_localization(dcc_dbclean_t)
sysnet_read_config(dcc_dbclean_t)
sysnet_dns_name_resolve(dcc_dbclean_t)
optional_policy(`
nscd_socket_use(dcc_dbclean_t)
')
########################################
#
# Server daemon local policy
#
allow dccd_t self:capability net_admin;
dontaudit dccd_t self:capability sys_tty_config;
allow dccd_t self:process signal_perms;
allow dccd_t self:unix_stream_socket create_socket_perms;
allow dccd_t self:netlink_route_socket { bind create getattr nlmsg_read read write };
allow dccd_t self:udp_socket create_socket_perms;
allow dccd_t dcc_client_map_t:file rw_file_perms;
# Access files in /var/dcc. The map file can be updated
allow dccd_t dcc_var_t:dir r_dir_perms;
allow dccd_t dcc_var_t:file r_file_perms;
allow dccd_t dcc_var_t:lnk_file { getattr read };
# Runs the dbclean program
domain_auto_trans(dccd_t, dcc_dbclean_exec_t, dcc_dbclean_t)
corecmd_search_bin(dccd_t)
allow dcc_dbclean_t dccd_t:fd use;
allow dcc_dbclean_t dccd_t:fifo_file rw_file_perms;
allow dcc_dbclean_t dccd_t:process sigchld;
# Updating dcc_db, flod, ...
allow dccd_t dcc_var_t:dir manage_dir_perms;
allow dccd_t dcc_var_t:file manage_file_perms;
allow dccd_t dcc_var_t:lnk_file create_lnk_perms;
allow dccd_t dccd_tmp_t:dir manage_dir_perms;
allow dccd_t dccd_tmp_t:file create_file_perms;
files_tmp_filetrans(dccd_t, dccd_tmp_t, { file dir })
allow dccd_t dccd_var_run_t:file create_file_perms;
allow dccd_t dccd_var_run_t:dir rw_dir_perms;
files_pid_filetrans(dccd_t,dccd_var_run_t,file)
kernel_read_system_state(dccd_t)
kernel_read_kernel_sysctls(dccd_t)
corenet_non_ipsec_sendrecv(dccd_t)
corenet_udp_sendrecv_generic_if(dccd_t)
corenet_udp_sendrecv_all_nodes(dccd_t)
corenet_udp_sendrecv_all_ports(dccd_t)
corenet_udp_bind_all_nodes(dccd_t)
corenet_udp_bind_dcc_port(dccd_t)
dev_read_sysfs(dccd_t)
domain_use_interactive_fds(dccd_t)
files_read_etc_files(dccd_t)
files_read_etc_runtime_files(dccd_t)
fs_getattr_all_fs(dccd_t)
fs_search_auto_mountpoints(dccd_t)
term_dontaudit_use_console(dccd_t)
init_use_fds(dccd_t)
init_use_script_ptys(dccd_t)
libs_use_ld_so(dccd_t)
libs_use_shared_libs(dccd_t)
logging_send_syslog_msg(dccd_t)
miscfiles_read_localization(dccd_t)
sysnet_read_config(dccd_t)
sysnet_dns_name_resolve(dccd_t)
userdom_dontaudit_use_unpriv_user_fds(dccd_t)
userdom_dontaudit_search_sysadm_home_dirs(dccd_t)
ifdef(`targeted_policy',`
term_dontaudit_use_unallocated_ttys(dccd_t)
term_dontaudit_use_generic_ptys(dccd_t)
files_dontaudit_read_root_files(dccd_t)
')
optional_policy(`
nscd_socket_use(dccd_t)
')
optional_policy(`
seutil_sigchld_newrole(dccd_t)
')
optional_policy(`
udev_read_db(dccd_t)
')
########################################
#
# Spamassassin and general MTA persistent client local policy
#
dontaudit dccifd_t self:capability sys_tty_config;
allow dccifd_t self:process signal_perms;
allow dccifd_t self:unix_stream_socket create_stream_socket_perms;
allow dccifd_t self:unix_dgram_socket create_socket_perms;
allow dccifd_t self:udp_socket create_socket_perms;
allow dccifd_t dcc_client_map_t:file rw_file_perms;
# Updating dcc_db, flod, ...
allow dccifd_t dcc_var_t:dir manage_dir_perms;
allow dccifd_t dcc_var_t:{ file sock_file fifo_file } manage_file_perms;
allow dccifd_t dcc_var_t:lnk_file create_lnk_perms;
allow dccifd_t dccifd_tmp_t:dir manage_dir_perms;
allow dccifd_t dccifd_tmp_t:file manage_file_perms;
files_tmp_filetrans(dccifd_t, dccifd_tmp_t, { file dir })
allow dccifd_t dccifd_var_run_t:file manage_file_perms;
allow dccifd_t dccifd_var_run_t:sock_file manage_file_perms;
allow dccifd_t dcc_var_t:dir rw_dir_perms;
type_transition dccifd_t dcc_var_t:{ file sock_file } dccifd_var_run_t;
allow dccifd_t dccifd_var_run_t:file manage_file_perms;
allow dccifd_t dccifd_var_run_t:dir rw_dir_perms;
files_pid_filetrans(dccifd_t,dccifd_var_run_t,file)
kernel_read_system_state(dccifd_t)
kernel_read_kernel_sysctls(dccifd_t)
corenet_non_ipsec_sendrecv(dccifd_t)
corenet_udp_sendrecv_generic_if(dccifd_t)
corenet_udp_sendrecv_all_nodes(dccifd_t)
corenet_udp_sendrecv_all_ports(dccifd_t)
corenet_udp_bind_all_nodes(dccifd_t)
dev_read_sysfs(dccifd_t)
domain_use_interactive_fds(dccifd_t)
files_read_etc_files(dccifd_t)
files_read_etc_runtime_files(dccifd_t)
fs_getattr_all_fs(dccifd_t)
fs_search_auto_mountpoints(dccifd_t)
term_dontaudit_use_console(dccifd_t)
init_use_fds(dccifd_t)
init_use_script_ptys(dccifd_t)
libs_use_ld_so(dccifd_t)
libs_use_shared_libs(dccifd_t)
logging_send_syslog_msg(dccifd_t)
miscfiles_read_localization(dccifd_t)
sysnet_read_config(dccifd_t)
sysnet_dns_name_resolve(dccifd_t)
userdom_dontaudit_use_unpriv_user_fds(dccifd_t)
userdom_dontaudit_search_sysadm_home_dirs(dccifd_t)
ifdef(`targeted_policy',`
term_dontaudit_use_unallocated_ttys(dccifd_t)
term_dontaudit_use_generic_ptys(dccifd_t)
files_dontaudit_read_root_files(dccifd_t)
')
optional_policy(`
nscd_socket_use(dccifd_t)
')
optional_policy(`
seutil_sigchld_newrole(dccifd_t)
')
optional_policy(`
udev_read_db(dccifd_t)
')
########################################
#
# sendmail milter client local policy
#
dontaudit dccm_t self:capability sys_tty_config;
allow dccm_t self:process signal_perms;
allow dccm_t self:unix_stream_socket create_stream_socket_perms;
allow dccm_t self:unix_dgram_socket create_socket_perms;
allow dccm_t self:udp_socket create_socket_perms;
allow dccm_t dcc_client_map_t:file rw_file_perms;
allow dccm_t dcc_var_t:dir manage_dir_perms;
allow dccm_t dcc_var_t:{ file sock_file fifo_file } create_file_perms;
allow dccm_t dcc_var_t:lnk_file create_lnk_perms;
allow dccm_t dccm_tmp_t:dir manage_dir_perms;
allow dccm_t dccm_tmp_t:file manage_file_perms;
files_tmp_filetrans(dccm_t, dccm_tmp_t, { file dir })
allow dccm_t dccm_var_run_t:file manage_file_perms;
allow dccm_t dccm_var_run_t:sock_file manage_file_perms;
allow dccm_t dcc_var_run_t:dir rw_dir_perms;
type_transition dccm_t dcc_var_run_t:{ file sock_file } dccm_var_run_t;
allow dccm_t dccm_var_run_t:file manage_file_perms;
allow dccm_t dccm_var_run_t:dir rw_dir_perms;
files_pid_filetrans(dccm_t,dccm_var_run_t,file)
kernel_read_system_state(dccm_t)
kernel_read_kernel_sysctls(dccm_t)
corenet_non_ipsec_sendrecv(dccm_t)
corenet_udp_sendrecv_generic_if(dccm_t)
corenet_udp_sendrecv_all_nodes(dccm_t)
corenet_udp_sendrecv_all_ports(dccm_t)
dev_read_sysfs(dccm_t)
domain_use_interactive_fds(dccm_t)
files_read_etc_files(dccm_t)
files_read_etc_runtime_files(dccm_t)
fs_getattr_all_fs(dccm_t)
fs_search_auto_mountpoints(dccm_t)
term_dontaudit_use_console(dccm_t)
init_use_fds(dccm_t)
init_use_script_ptys(dccm_t)
libs_use_ld_so(dccm_t)
libs_use_shared_libs(dccm_t)
logging_send_syslog_msg(dccm_t)
miscfiles_read_localization(dccm_t)
sysnet_read_config(dccm_t)
sysnet_dns_name_resolve(dccm_t)
userdom_dontaudit_use_unpriv_user_fds(dccm_t)
userdom_dontaudit_search_sysadm_home_dirs(dccm_t)
ifdef(`targeted_policy',`
term_dontaudit_use_unallocated_ttys(dccm_t)
term_dontaudit_use_generic_ptys(dccm_t)
files_dontaudit_read_root_files(dccm_t)
')
optional_policy(`
nscd_socket_use(dccm_t)
')
optional_policy(`
seutil_sigchld_newrole(dccm_t)
')
optional_policy(`
udev_read_db(dccm_t)
')
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)
## <summary>A distributed, collaborative, spam detection and filtering
network.</summary>
## <desc>
## <p>
## A distributed, collaborative, spam detection and filtering network.
## </p>
## <p>
## This policy will work with either the ATrpms provided config
## file in /etc/razor, or with the default of dumping everything into
## $HOME/.razor.
## </p>
## </desc>
#######################################
## <summary>
## Template to create types and rules common to
## all razor domains.
## </summary>
## <param name="prefix">
## <summary>
## The prefix of the domain (e.g., user
## is the prefix for user_t).
## </summary>
## </param>
#
template(`razor_common_domain_template',`
allow $1_t self:process ~{ ptrace setcurrent setexec setfscreate setrlimit execmem
execstack execheap };
allow $1_t self:fd use;
allow $1_t self:fifo_file rw_file_perms;
allow $1_t self:unix_dgram_socket create_socket_perms;
allow $1_t self:unix_stream_socket create_stream_socket_perms;
allow $1_t self:unix_dgram_socket sendto;
allow $1_t self:unix_stream_socket connectto;
allow $1_t self:shm create_shm_perms;
allow $1_t self:sem create_sem_perms;
allow $1_t self:msgq create_msgq_perms;
allow $1_t self:msg { send receive };
allow $1_t self:tcp_socket create_socket_perms;
# Read system config file
allow $1_t razor_etc_t:dir list_dir_perms;
allow $1_t razor_etc_t:file read_file_perms;
allow $1_t razor_etc_t:lnk_file { getattr read };
allow $1_t razor_log_t:dir manage_dir_perms;
allow $1_t razor_log_t:file manage_file_perms;
allow $1_t razor_log_t:lnk_file create_lnk_perms;
logging_log_filetrans($1_t,razor_log_t,file)
allow $1_t razor_var_lib_t:dir manage_dir_perms;
allow $1_t razor_var_lib_t:file manage_file_perms;
allow $1_t razor_var_lib_t:lnk_file create_lnk_perms;
files_search_var_lib($1_t)
# Razor is one executable and several symlinks
allow $1_t razor_exec_t:{ file lnk_file } { getattr read };
kernel_read_system_state($1_t)
kernel_read_network_state($1_t)
kernel_read_software_raid_state($1_t)
kernel_getattr_core_if($1_t)
kernel_getattr_message_if($1_t)
kernel_read_kernel_sysctls($1_t)
corecmd_exec_bin($1_t)
corenet_tcp_sendrecv_generic_if($1_t)
corenet_raw_sendrecv_generic_if($1_t)
corenet_tcp_sendrecv_all_nodes($1_t)
corenet_raw_sendrecv_all_nodes($1_t)
corenet_tcp_sendrecv_razor_port($1_t)
corenet_non_ipsec_sendrecv($1_t)
corenet_tcp_bind_all_nodes($1_t)
# mktemp and other randoms
dev_read_rand($1_t)
dev_read_urand($1_t)
files_search_pids($1_t)
# Allow access to various files in the /etc/directory including mtab
# and nsswitch
files_read_etc_files($1_t)
files_read_etc_runtime_files($1_t)
fs_search_auto_mountpoints($1_t)
libs_use_ld_so($1_t)
libs_use_shared_libs($1_t)
libs_read_lib_files($1_t)
miscfiles_read_localization($1_t)
sysnet_read_config($1_t)
sysnet_dns_name_resolve($1_t)
userdom_use_unpriv_users_fds($1_t)
optional_policy(`
nis_use_ypbind($1_t)
')
')
#######################################
## <summary>
## The per user domain template for the razor module.
## </summary>
## <desc>
## <p>
## The per user domain template for the razor module.
## </p>
## <p>
## This template is invoked automatically for each user, and
## generally does not need to be invoked directly
## by policy writers.
## </p>
## </desc>
## <param name="userdomain_prefix">
## <summary>
## The prefix of the user domain (e.g., user
## is the prefix for user_t).
## </summary>
## </param>
## <param name="user_domain">
## <summary>
## The type of the user domain.
## </summary>
## </param>
## <param name="user_role">
## <summary>
## The role associated with the user domain.
## </summary>
## </param>
#
template(`razor_per_userdomain_template',`
type $1_razor_t;
domain_type($1_razor_t)
domain_entry_file($1_razor_t,razor_exec_t)
razor_common_domain_template($1_razor)
role $3 types $1_razor_t;
type $1_razor_home_t alias $1_razor_rw_t;
files_poly_member($1_razor_home_t)
userdom_user_home_content($1,$1_razor_home_t)
type $1_razor_tmp_t;
files_tmp_file($1_razor_tmp_t)
##############################
#
# Local policy
#
allow $1_razor_t self:unix_stream_socket create_stream_socket_perms;
allow $1_razor_t $1_razor_home_t:dir manage_dir_perms;
allow $1_razor_t $1_razor_home_t:file manage_file_perms;
allow $1_razor_t $1_razor_home_t:lnk_file create_lnk_perms;
userdom_user_home_dir_filetrans($1,$1_razor_t,$1_razor_home_t,dir)
allow $1_razor_t $1_razor_tmp_t:dir create_dir_perms;
allow $1_razor_t $1_razor_tmp_t:file create_file_perms;
files_tmp_filetrans($1_razor_t, $1_razor_tmp_t, { file dir })
domain_auto_trans($2, razor_exec_t, $1_razor_t)
allow $1_razor_t $2:fd use;
allow $1_razor_t $2:fifo_file rw_file_perms;
allow $1_razor_t $2:process sigchld;
allow $2 $1_razor_home_t:dir manage_dir_perms;
allow $2 $1_razor_home_t:file manage_file_perms;
allow $2 $1_razor_home_t:lnk_file create_lnk_perms;
allow $2 $1_razor_home_t:{ dir file lnk_file } { relabelfrom relabelto };
logging_send_syslog_msg($1_razor_t)
userdom_search_user_home_dirs($1,$1_razor_t)
# Allow razor to be run by hand. Needed by any action other than
# invocation from a spam filter.
userdom_use_user_terminals($1,$1_razor_t)
tunable_policy(`use_nfs_home_dirs',`
fs_manage_nfs_dirs($1_razor_t)
fs_manage_nfs_files($1_razor_t)
fs_manage_nfs_symlinks($1_razor_t)
')
tunable_policy(`use_samba_home_dirs',`
fs_manage_cifs_dirs($1_razor_t)
fs_manage_cifs_files($1_razor_t)
fs_manage_cifs_symlinks($1_razor_t)
')
optional_policy(`
nscd_socket_use($1_razor_t)
')
')
########################################
## <summary>
## Execute razor in the system razor domain.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed access.
## </summary>
## </param>
#
interface(`razor_domtrans',`
gen_require(`
type razor_t, razor_exec_t;
')
domain_auto_trans($1, razor_exec_t, razor_t)
allow razor_t $1:fd use;
allow razor_t $1:fifo_file rw_file_perms;
allow razor_t $1:process sigchld;
')
policy_module(razor,1.0.0)
########################################
#
# Declarations
#
type razor_t;
type razor_exec_t;
domain_type(razor_t)
domain_entry_file(razor_t,razor_exec_t)
razor_common_domain_template(razor)
role system_r types razor_t;
type razor_etc_t;
files_config_file(razor_etc_t)
type razor_log_t;
logging_log_file(razor_log_t)
type razor_var_lib_t;
files_type(razor_var_lib_t)
########################################
#
# Local policy
#
allow razor_t self:tcp_socket create_socket_perms;
allow razor_t razor_etc_t:dir create_dir_perms;
allow razor_t razor_etc_t:file create_file_perms;
allow razor_t razor_etc_t:lnk_file create_lnk_perms;
files_search_etc(razor_t)
allow razor_t razor_log_t:file create_file_perms;
logging_log_filetrans(razor_t,razor_log_t,file)
allow razor_t razor_var_lib_t:file create_file_perms;
allow razor_t razor_var_lib_t:dir rw_dir_perms;
files_var_lib_filetrans(razor_t,razor_var_lib_t,file)
corenet_non_ipsec_sendrecv(razor_t)
corenet_tcp_sendrecv_generic_if(razor_t)
corenet_raw_sendrecv_generic_if(razor_t)
corenet_tcp_sendrecv_all_nodes(razor_t)
corenet_raw_sendrecv_all_nodes(razor_t)
corenet_tcp_sendrecv_razor_port(razor_t)
corenet_tcp_bind_all_nodes(razor_t)
corenet_tcp_connect_razor_port(razor_t)
sysnet_read_config(razor_t)
optional_policy(`
logging_send_syslog_msg(razor_t)
')
optional_policy(`
nscd_socket_use(razor_t)
')
1:57 p.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-21 at 18:33 +0100, Paul Howarth wrote:
Marc Schwartz (via MN) wrote:
>> Can you try restarting postfix? I think the manpage thing happened at
>> that point.
>
> Interesting. Recalling that, I had re-booted before my reply above and
> had no msgs. However doing a service restart post-boot using
> system-config-services, I get:
>
> type=AVC msg=audit(1150906621.693:641): avc: denied { read } for pid=12784
comm="postfix" name=".fonts.cache-2" dev=hdc7 ino=427877
scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:object_r:user_home_t:s0
tclass=file
> type=SYSCALL msg=audit(1150906621.693:641): arch=40000003 syscall=11 success=yes
exit=0 a0=9e14f80 a1=9dfb478 a2=9e14f98 a3=9e14e68 items=2 pid=12784 auid=500 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="postfix"
exe="/usr/sbin/postfix"
> type=AVC_PATH msg=audit(1150906621.693:641):
path="/root/.rh-fontconfig/.fonts.cache-2"
> type=CWD msg=audit(1150906621.693:641): cwd="/"
> type=PATH msg=audit(1150906621.693:641): item=0 name="/usr/sbin/postfix"
flags=101 inode=3132499 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
> type=PATH msg=audit(1150906621.693:641): item=1 flags=101 inode=754491 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00
> type=AVC msg=audit(1150906621.829:642): avc: denied { read } for pid=12796
comm="postfix" name=".fonts.cache-2" dev=hdc7 ino=427877
scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:object_r:user_home_t:s0
tclass=file
> type=SYSCALL msg=audit(1150906621.829:642): arch=40000003 syscall=11 success=yes
exit=0 a0=9e15318 a1=9e00e50 a2=9e14f98 a3=9e14d00 items=2 pid=12796 auid=500 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="postfix"
exe="/usr/sbin/postfix"
> type=AVC_PATH msg=audit(1150906621.829:642):
path="/root/.rh-fontconfig/.fonts.cache-2"
> type=CWD msg=audit(1150906621.829:642): cwd="/"
> type=PATH msg=audit(1150906621.829:642): item=0 name="/usr/sbin/postfix"
flags=101 inode=3132499 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
> type=PATH msg=audit(1150906621.829:642): item=1 flags=101 inode=754491 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00
>
> Which seems to not involve the man pages, but font caches for some
> reason.
That's just completely weird. I wonder if it's a filehandle left open
from somewhere. I wonder how to diagnose this further? Since the types
aren't consistent, they can't even be dontaudit-ed. I trust nothing has
broken anyway?
I don't see any evidence of other problems at this point. The above
seems to be specifically related to the use of system-config-services,
so perhaps there is some gtk interaction going on. At the CLI, there do
not appear to be problems.
I have no clue otherwise.
>> Once that's done I'd like to try out the dcc and
razor modules that are
>> now in rawhide. That will involve going back to permissive mode for a
>> while though.
OK, I've attached the dcc and razor policy files from the current FC5
selinux-policy package. Try installing those, put selinux in permissive
mode, do a restorecon on all of your dcc and razor files/directories and
see what happens.
Paul.
Just to be clear, I should leave or remove the mydcc policy?
Marc
2:25 p.m.
New subject: postfix, procmail and SELinux - No Go
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
Marc
2:55 p.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-21 at 14:25 -0500, 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
Did you do the restorecon of all your dcc and razor files/directories
too (the .fc files should indicate where you'd expect to find things)?
Paul.
3:01 p.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-21 at 20:55 +0100, Paul Howarth wrote:
On Wed, 2006-06-21 at 14:25 -0500, 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
Did you do the restorecon of all your dcc and razor files/directories
too (the .fc files should indicate where you'd expect to find things)?
Yep. I actually use 'locate razor' and 'locate dcc', since several of
the paths listed in the .fc files are not present.
I also then ran a 'fixfiles check' which came back with no errors,
though as we have seen previously, that seems to be no guarantee of
anything...
"The absence of evidence is not evidence of absence"
Marc
3:07 p.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-21 at 15:01 -0500, Marc Schwartz (via MN) wrote:
On Wed, 2006-06-21 at 20:55 +0100, Paul Howarth wrote:
> On Wed, 2006-06-21 at 14:25 -0500, 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
>
> Did you do the restorecon of all your dcc and razor files/directories
> too (the .fc files should indicate where you'd expect to find things)?
Yep. I actually use 'locate razor' and 'locate dcc', since several of
the paths listed in the .fc files are not present.
I also then ran a 'fixfiles check' which came back with no errors,
though as we have seen previously, that seems to be no guarantee of
anything...
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.
Paul.
3:23 p.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-21 at 21:07 +0100, Paul Howarth wrote:
On Wed, 2006-06-21 at 15:01 -0500, Marc Schwartz (via MN) wrote:
> On Wed, 2006-06-21 at 20:55 +0100, Paul Howarth wrote:
> > On Wed, 2006-06-21 at 14:25 -0500, 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
> >
> > Did you do the restorecon of all your dcc and razor files/directories
> > too (the .fc files should indicate where you'd expect to find things)?
>
> Yep. I actually use 'locate razor' and 'locate dcc', since several
of
> the paths listed in the .fc files are not present.
>
> I also then ran a 'fixfiles check' which came back with no errors,
> though as we have seen previously, that seems to be no guarantee of
> anything...
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
/usr/bin/razor*
/root/.razor/*
/.razor/*
dcc was installed from the upstream tarball at Rhyolite. It is not in
FE. Built with default options.
razor is installed via FE with perl-Razor-Agent-2.77-3.fc5.
pyzor is also from FE with pyzor-0.4.0-9.fc4. Presumably the RPM naming
should be updated to fc5?
Marc
2:56 p.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-21 at 14:25 -0500, 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:
I suppose that these are more correctly "warnings" since they do
build...
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
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?
Marc
3:12 p.m.
New subject: postfix, procmail and SELinux - No Go
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
type=SYSCALL msg=audit(1150920365.865:1776): arch=40000003 syscall=11 success=yes exit=0
a0=a890768 a1=a83ff88 a2=a864c60 a3=bfa440ac items=3 pid=4583 auid=4294967295 uid=500
gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="pyzor"
exe="/usr/bin/python"
type=AVC_PATH msg=audit(1150920365.865:1776): path="/usr/bin/pyzor"
type=AVC_PATH msg=audit(1150920365.865:1776): path="/usr/bin/pyzor"
type=CWD msg=audit(1150920365.865:1776): cwd="/"
type=PATH msg=audit(1150920365.865:1776): item=0 name="/usr/bin/pyzor" flags=101
inode=3140757 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1150920365.865:1776): item=1 flags=101 inode=3140290 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1150920365.865:1776): item=2 flags=101 inode=754491 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1150920365.877:1777): avc: denied { ioctl } for pid=4583
comm="pyzor" 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(1150920365.877:1777): arch=40000003 syscall=54 success=no exit=-25
a0=3 a1=5401 a2=bfd14638 a3=bfd14678 items=0 pid=4583 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="pyzor"
exe="/usr/bin/python"
type=AVC_PATH msg=audit(1150920365.877:1777): path="/usr/bin/pyzor"
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
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"
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.
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.
Curious.
Marc
8:10 a.m.
New subject: postfix, procmail and SELinux - No Go
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.
8:19 p.m.
New subject: postfix, procmail and SELinux - No Go
On Thu, 2006-06-22 at 14:10 +0100, Paul Howarth wrote:
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.
Yep. I removed the .if files and all seems well.
> 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").
Yep.
> 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.
Yep again. :-)
> 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.
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.
The files in /root/.razor appear to be tagged as during the day today,
perhaps when cron jobs result in e-mails to root, which are then mapped
to my userID by postfix.
> 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.
I think that this is the same situation as with razor above.
> /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.
Yep yet again.
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)
Done.
OK. Here are the latest avc's subsequent to the above change and now
using the spamc/d approach:
type=AVC msg=audit(1151025305.852:691): avc: denied { execute } for pid=22050
comm="spamd" name="pyzor" dev=hdc7 ino=3140757 scon
text=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:pyzor_exec_t:s0 tclass=file
type=AVC msg=audit(1151025305.852:691): avc: denied { execute_no_trans } for pid=22050
comm="spamd" name="pyzor" dev=hdc7 ino=314 0757
scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:pyzor_exec_t:s0
tclass=file
type=AVC msg=audit(1151025305.852:691): avc: denied { read } for pid=22050
comm="spamd" name="pyzor" dev=hdc7 ino=3140757 scontex
t=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:pyzor_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1151025305.852:691): arch=40000003 syscall=11 success=yes exit=0
a0=b535ee0 a1=ba6e0d0 a2=baa2150 a3=bf81af1c items=3 pid=22050 auid=4294967295 uid=500
gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="pyzor"
exe="/usr/bin/ python"
type=AVC_PATH msg=audit(1151025305.852:691): path="/usr/bin/pyzor"
type=AVC_PATH msg=audit(1151025305.852:691): path="/usr/bin/pyzor"
type=CWD msg=audit(1151025305.852:691): cwd="/"
type=PATH msg=audit(1151025305.852:691): item=0 name="/usr/bin/pyzor" flags=101
inode=3140757 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1151025305.852:691): item=1 flags=101 inode=3140290 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1151025305.852:691): item=2 flags=101 inode=754491 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1151025305.884:692): avc: denied { ioctl } for pid=22050
comm="pyzor" name="pyzor" dev=hdc7 ino=3140757 sconte
xt=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:pyzor_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1151025305.884:692): arch=40000003 syscall=54 success=no exit=-25
a0=3 a1=5401 a2=bf8a4998 a3=bf8a49d8 items= 0 pid=22050 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="pyzor"
exe="/usr/bin/python"
type=AVC_PATH msg=audit(1151025305.884:692): path="/usr/bin/pyzor"
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"
type=CWD msg=audit(1151025306.136:693): cwd="/"
type=PATH msg=audit(1151025306.136:693): 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(1151025306.136:694): avc: denied { read write } for pid=22051
comm="dccproc" name="map" dev=dm-1 ino=59007 sco
ntext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_map_t:s0
tclass=file
type=SYSCALL msg=audit(1151025306.136:694): arch=40000003 syscall=5 success=yes exit=3
a0=80ba6e0 a1=2 a2=180 a3=37 items=1 pid=2205 1 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(1151025306.136:694): cwd="/var/dcc"
type=PATH msg=audit(1151025306.136:694): 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(1151025306.136:695): avc: denied { getattr } for pid=22051
comm="dccproc" name="map" dev=dm-1 ino=59007 sconte
xt=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_map_t:s0
tclass=file
type=SYSCALL msg=audit(1151025306.136:695): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bfe798d8 a2=4891eff4 a3=3 items=0 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"
type=AVC_PATH msg=audit(1151025306.136:695): path="/var/dcc/map"
type=AVC msg=audit(1151025306.136:696): avc: denied { lock } for pid=22051
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(1151025306.136:696): arch=40000003 syscall=221 success=yes exit=0
a0=3 a1=7 a2=bfe7aa54 a3=bfe7aa54 items=0 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"
type=AVC_PATH msg=audit(1151025306.136:696): path="/var/dcc/map"
Thanks Paul,
Marc
4:12 a.m.
New subject: postfix, procmail and SELinux - No Go
On Thu, 2006-06-22 at 20:19 -0500, Marc Schwartz wrote:
On Thu, 2006-06-22 at 14:10 +0100, Paul Howarth wrote:
> 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.
Yep. I removed the .if files and all seems well.
I'm going to rename the myclamscan module to myclamav, and merge
together the myclamscan policy with some clamav tweaks I did for someone
on fedora-list. This will make it easier to eventually merge it into the
main policy.
> > 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?
Given that this is causing problems, I'll add it locally for now.
(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.
The files in /root/.razor appear to be tagged as during the day
today,
perhaps when cron jobs result in e-mails to root, which are then mapped
to my userID by postfix.
It's unfortunate that the mapping takes place later than the razor
invocation.
(snip)
> > 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.
I think that this is the same situation as with razor above.
Probably so.
(snip)
OK. Here are the latest avc's subsequent to the above change and
now
using the spamc/d approach:
type=AVC msg=audit(1151025305.852:691): avc: denied { execute } for pid=22050
comm="spamd" name="pyzor" dev=hdc7 ino=3140757 scon
text=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:pyzor_exec_t:s0 tclass=file
type=AVC msg=audit(1151025305.852:691): avc: denied { execute_no_trans } for pid=22050
comm="spamd" name="pyzor" dev=hdc7 ino=314 0757
scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:pyzor_exec_t:s0
tclass=file
spamd failing to transition to pyzor again.
(snip)
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.
Here are the new policy modules. You can get rid of myclamscan now.
::::::::::::::
myclamav.if
::::::::::::::
## <summary>Clamassassin Virus Scanner Wrapper.</summary>
########################################
## <summary>
## Execute the clamassassin program in the clamassassin domain.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed access.
## </summary>
## </param>
#
interface(`clamav_domtrans_clamassassin',`
gen_require(`
type clamassassin_t, clamassassin_exec_t;
')
corecmd_search_bin($1)
domain_auto_trans($1, clamassassin_exec_t, clamassassin_t)
allow $1 clamassassin_t:fd use;
allow clamassassin_t $1:fd use;
allow clamassassin_t $1:fifo_file rw_file_perms;
allow clamassassin_t $1:process sigchld;
')
::::::::::::::
myclamav.fc
::::::::::::::
/usr/bin/clamassassin --
gen_context(system_u:object_r:clamassassin_exec_t,s0)
/usr/local/bin/clamassassin --
gen_context(system_u:object_r:clamassassin_exec_t,s0)
/var/log/clamav/clamd.* --
gen_context(system_u:object_r:clamd_var_log_t,s0)
::::::::::::::
myclamav.te
::::::::::::::
policy_module(myclamav, 0.1.1)
require {
type clamd_t;
type clamscan_t;
type clamscan_tmp_t;
type freshclam_t;
type postfix_local_t;
type procmail_t;
};
type clamassassin_t;
domain_type(clamassassin_t)
type clamassassin_exec_t;
domain_entry_file(clamassassin_t,clamassassin_exec_t)
# ========================================
# clamassassin local policy
# ========================================
# Transition from unconfined for command-line usage
ifdef(`targeted_policy',`
clamav_domtrans_clamassassin(unconfined_t)
')
# When clamassassin writes temp files, they're for clamscan to process
# so make them clamscan_tmp_t
allow clamassassin_t clamscan_tmp_t:dir create_dir_perms;
allow clamassassin_t clamscan_tmp_t:file create_file_perms;
files_tmp_filetrans(clamassassin_t, clamscan_tmp_t, { file dir })
# clamassassin needs to be able to call clamscan
clamav_domtrans_clamscan(clamassassin_t)
# ========================================
# clamd local policy
# ========================================
kernel_read_kernel_sysctls(clamd_t)
# ========================================
# clamscan local policy
# ========================================
# Allow clamscan output to be piped back into the
# postfix local delivery process
# (this might now be clamassassin_t)
#allow clamscan_t postfix_local_t:fd use;
#allow clamscan_t postfix_local_t:fifo_file write;
# ========================================
# freshclam local policy
# ========================================
# Allow freshclam to send syslog messages
logging_send_syslog_msg(freshclam_t)
# Allow freshclam to read generic kernel sysctls
kernel_read_kernel_sysctls(freshclam_t)
::::::::::::::
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)
::::::::::::::
mydcc.te
::::::::::::::
policy_module(mydcc, 0.1.5)
require {
type spamd_t;
}
::::::::::::::
myspamassassin.te
::::::::::::::
policy_module(myspamassassin, 0.1.1)
require {
type spamd_t;
}
# This will be included in FC5 policy when dcc module is included
dcc_domtrans_client(spamd_t)
# This is already supposed to be included but doesn't seem to be working
pyzor_domtrans(spamd_t)
# This will be included in FC5 policy when razor module is included
razor_domtrans(spamd_t)
::::::::::::::
procmail.fc
::::::::::::::
/var/log/procmail\.log --
gen_context(system_u:object_r:procmail_var_log_t,s0)
::::::::::::::
procmail.te
::::::::::::::
policy_module(procmail, 0.5.4)
require {
type procmail_t;
type sendmail_t;
};
# temp files
type procmail_tmp_t;
files_tmp_file(procmail_tmp_t)
# log files
type procmail_var_log_t;
logging_log_file(procmail_var_log_t)
# Write log to /var/log/procmail.log
allow procmail_t procmail_var_log_t:file create_file_perms;
allow procmail_t procmail_var_log_t:dir { rw_dir_perms setattr };
logging_log_filetrans(procmail_t,procmail_var_log_t, { file dir })
# Allow programs called from procmail to read/write temp files and dirs
allow procmail_t procmail_tmp_t:dir create_dir_perms;
allow procmail_t procmail_tmp_t:file create_file_perms;
files_type(procmail_tmp_t)
files_tmp_filetrans(procmail_t, procmail_tmp_t, { file dir })
# ==============================================
# Procmail needs to call sendmail for forwarding
# ==============================================
# Read alternatives link (still not in policy)
corecmd_read_sbin_symlinks(procmail_t)
# Procmail occasionally signals sendmail, e.g. when it times out during
forwarding
allow procmail_t sendmail_t:process signal;
# Allow transition to sendmail
# This is in selinux-policy-2.2.34-2 onwards
# (may need similar code for other MTAs that can replace sendmail)
# sendmail_domtrans(procmail_t)
# ==============================================
# Procmail needs to be able to call clamassassin
# ==============================================
clamav_domtrans_clamassassin(procmail_t)
After localing these modules, please do:
# restorecon -rv /usr/local/bin
Moving clamassassin into its own domain may cause lots of new AVCs. This
is expected...
Paul.
5:40 p.m.
New subject: postfix, procmail and SELinux - No Go
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>
> > 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.
>
> Yep. I removed the .if files and all seems well.
I'm going to rename the myclamscan module to myclamav, and merge
together the myclamscan policy with some clamav tweaks I did for someone
on fedora-list. This will make it easier to eventually merge it into the
main policy.
OK. Makes sense
> > > /.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
# 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.
> The files in /root/.razor appear to be tagged as during the day
today,
> perhaps when cron jobs result in e-mails to root, which are then mapped
> to my userID by postfix.
It's unfortunate that the mapping takes place later than the razor
invocation.
(snip)
<snip>
> 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
There is no /etc/dcc tree
The files that are listed in /usr/libexec/dcc are in /var/dcc/libexec.
There is no /var/run/dcc tree.
<snip of new policy files>
After localing these modules, please do:
# restorecon -rv /usr/local/bin
Done.
Moving clamassassin into its own domain may cause lots of new AVCs.
This
is expected...
OK.
# 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
type=AVC msg=audit(1151188279.672:1445): avc: denied { getattr } 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.672:1445): arch=40000003 syscall=197 success=yes exit=0
a0=0 a1=bff9ba98 a2=4891eff4 a3=3 items=0 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.672:1445):
path="/tmp/.spamassassin2378EoApLctmp"
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
type=AVC msg=audit(1151188279.672:1447): avc: denied { read write } for pid=6563
comm="dccproc" name="map" dev=dm-1 ino=59007
scontext=system_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:unlabeled_t:s0
tclass=file
type=SYSCALL msg=audit(1151188279.672:1447): arch=40000003 syscall=5 success=yes exit=3
a0=80ba6e0 a1=2 a2=180 a3=37 items=1 pid=6563 auid=4294967295 uid=500 gid=0 euid=0 suid=0
fsuid=0 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:1447): cwd="/var/dcc"
type=PATH msg=audit(1151188279.672:1447): item=0 name="/var/dcc/map" inode=59007
dev=fd:01 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:unlabeled_t:s0
type=AVC msg=audit(1151188279.672:1448): avc: denied { getattr } for pid=6563
comm="dccproc" name="map" dev=dm-1 ino=59007
scontext=system_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:unlabeled_t:s0
tclass=file
type=SYSCALL msg=audit(1151188279.672:1448): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bff9a9f8 a2=4891eff4 a3=3 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=AVC_PATH msg=audit(1151188279.672:1448): path="/var/dcc/map"
type=AVC msg=audit(1151188279.672:1449): avc: denied { lock } for pid=6563
comm="dccproc" name="map" dev=dm-1 ino=59007
scontext=system_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:unlabeled_t:s0
tclass=file
type=SYSCALL msg=audit(1151188279.672:1449): arch=40000003 syscall=221 success=yes exit=0
a0=3 a1=7 a2=bff9bb74 a3=bff9bb74 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=AVC_PATH msg=audit(1151188279.672:1449): path="/var/dcc/map"
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
Thanks,
Marc
3:40 a.m.
New subject: postfix, procmail and SELinux - No Go
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.
11:07 a.m.
New subject: postfix, procmail and SELinux - No Go
Paul Howarth a écrit :
On Sat, 2006-06-24 at 17:40 -0500, Marc Schwartz wrote:
> '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?
actually razor discover and pyzor discover should just write
system-wide files in /var/cache in an ideal word, instead of having
every user re-download the list all by itself
Don't know if it's possible and if it is not, how difficult it would
be to fix.
BTW
- dcc is closed software, will never make it in FC or FE
- razor used to be FOSS but acquired some "not for commercial use"
features recently, so it's on the way out (dunno if it's still in FE
repos)
- pyzor is completely FOSS but seems to be going the sleeping beauty
way. What's worse the central pyzor server is on the sdsl setup of the
main developper and drops from the net every other week for long periods
It's all a shame because anyone who has run sa with and without
razor/pyzor will attest they improve sa efficentcy dramatically.
Since pyzor is in python maybe the Fedora project could setup a
central pyzor server for its users ?
Regards,
--
Nicolas Mailhot
3:53 p.m.
New subject: postfix, procmail and SELinux - No Go
Nicolas Mailhot wrote:
Paul Howarth a écrit :
> On Sat, 2006-06-24 at 17:40 -0500, Marc Schwartz wrote:
>> '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?
actually razor discover and pyzor discover should just write
system-wide files in /var/cache in an ideal word, instead of having
every user re-download the list all by itself
Don't know if it's possible and if it is not, how difficult it would
be to fix.
Guys, let me propose something here, at least as one possibility.
In reviewing the docs for razor and pyzor, it would seem that there are
some default file locations as we are experiencing. By default, these
appear to be user specific (ie. ~/.pyzor and ~/.razor), where the user
could be me, root or the "system". This includes the server updating
process.
It occurs to me that one potential confounding variable here is that I
am running these processes as a local user on a single user system,
rather than a system-wide approach as one might do with a central server
processing incoming e-mail for multiple user accounts. That includes my
use of ~/.procmailrc as the primary means to process both virus (via
clamassassin/clamav) and spam (via SA + these additional tools).
Presumably a SysAdmin on a multi-user system would take a different
approach and perhaps would use other means to integrate the processing
of viri and spam (such as Amavis as Nicolas has mentioned). This would
afford other approaches to the default configuration of these other tools.
To Nicolas' points below, there are some issues with these things moving
in a non-GPL mode, if they are not already there. I do note however
that both razor and pyzor are still in Extras for FC5 and are present in
Extras for devel (http://fedoraproject.org/extras/development/i386/). I
also whole heartedly support his contention that these tools
dramatically improve the processing of spam.
In either case, one option for me here within the notion of this being a
single user process, is to move the cron jobs that update razor and
pyzor from the system /etc/crontab to my user cron file vie "crontab -e"
(/var/spool/cron/marcs). I already have fetchmail and some backup
scripts running there anyway.
The dcc update process would need to stay in /etc/crontab since it
downloads, compiles and installs the system-wide dcc client.
In this way, the files that are getting updated would be limited to my
local user files (and perhaps still root's files), rather than the
system files in /.razor and /.pyzor.
Thoughts?
Another option, perhaps, would be for the FE razor and pyzor maintainers
to adjust the respective app defaults for FE with an eye towards SELinux
policy issues in future updates. In that way, perhaps the default
locations could be in /etc or /var as Nicolas notes above. That might
provide for a means to handle both single user and multi user
configurations, though the impact on other tools would need to be
considered as may be appropriate.
Paul, I will respond to your follow up shortly, as soon as I have
installed the updated policy files.
Regards,
Marc
BTW
- dcc is closed software, will never make it in FC or FE
- razor used to be FOSS but acquired some "not for commercial use"
features recently, so it's on the way out (dunno if it's still in FE
repos)
- pyzor is completely FOSS but seems to be going the sleeping beauty
way. What's worse the central pyzor server is on the sdsl setup of the
main developper and drops from the net every other week for long periods
It's all a shame because anyone who has run sa with and without
razor/pyzor will attest they improve sa efficentcy dramatically.
Since pyzor is in python maybe the Fedora project could setup a
central pyzor server for its users ?
6:38 a.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz wrote:
Nicolas Mailhot wrote:
> Paul Howarth a écrit :
>> On Sat, 2006-06-24 at 17:40 -0500, Marc Schwartz wrote:
>
>>> '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?
>
> actually razor discover and pyzor discover should just write
> system-wide files in /var/cache in an ideal word, instead of having
> every user re-download the list all by itself
>
> Don't know if it's possible and if it is not, how difficult it would
> be to fix.
Guys, let me propose something here, at least as one possibility.
In reviewing the docs for razor and pyzor, it would seem that there are
some default file locations as we are experiencing. By default, these
appear to be user specific (ie. ~/.pyzor and ~/.razor), where the user
could be me, root or the "system". This includes the server updating
process.
What I'm wondering is how this could end up creating directories /.razor
and /.pyzor since the root directory (as opposed to the /root directory)
is not the home directory of any user, and shouldn't be writable by
anyone other than root.
It occurs to me that one potential confounding variable here is that
I
am running these processes as a local user on a single user system,
rather than a system-wide approach as one might do with a central server
processing incoming e-mail for multiple user accounts. That includes my
use of ~/.procmailrc as the primary means to process both virus (via
clamassassin/clamav) and spam (via SA + these additional tools).
Presumably a SysAdmin on a multi-user system would take a different
approach and perhaps would use other means to integrate the processing
of viri and spam (such as Amavis as Nicolas has mentioned). This would
afford other approaches to the default configuration of these other tools.
The spamassassin wiki has a page on this:
http://wiki.apache.org/spamassassin/UsingPyzor
To Nicolas' points below, there are some issues with these things
moving
in a non-GPL mode, if they are not already there. I do note however
that both razor and pyzor are still in Extras for FC5 and are present in
Extras for devel (http://fedoraproject.org/extras/development/i386/). I
also whole heartedly support his contention that these tools
dramatically improve the processing of spam.
In either case, one option for me here within the notion of this being a
single user process, is to move the cron jobs that update razor and
pyzor from the system /etc/crontab to my user cron file vie "crontab -e"
(/var/spool/cron/marcs). I already have fetchmail and some backup
scripts running there anyway.
I think that would be a good move; it should at least prevent the
creation of directories straight under the root.
The dcc update process would need to stay in /etc/crontab since it
downloads, compiles and installs the system-wide dcc client.
Compiles as root? Ugh!
Another option, perhaps, would be for the FE razor and pyzor
maintainers
to adjust the respective app defaults for FE with an eye towards SELinux
policy issues in future updates. In that way, perhaps the default
locations could be in /etc or /var as Nicolas notes above. That might
provide for a means to handle both single user and multi user
configurations, though the impact on other tools would need to be
considered as may be appropriate.
If we can figure how how to make them work sanely, I'm confident that
the maintainers would be open to suggestions (preferably with patches).
Paul.
3:22 p.m.
New subject: postfix, procmail and SELinux - No Go
On Mon, 2006-06-26 at 12:38 +0100, Paul Howarth wrote:
Marc Schwartz wrote:
> Nicolas Mailhot wrote:
>> Paul Howarth a écrit :
>>> On Sat, 2006-06-24 at 17:40 -0500, Marc Schwartz wrote:
>>
>>>> '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?
>>
>> actually razor discover and pyzor discover should just write
>> system-wide files in /var/cache in an ideal word, instead of having
>> every user re-download the list all by itself
>>
>> Don't know if it's possible and if it is not, how difficult it would
>> be to fix.
>
> Guys, let me propose something here, at least as one possibility.
>
> In reviewing the docs for razor and pyzor, it would seem that there are
> some default file locations as we are experiencing. By default, these
> appear to be user specific (ie. ~/.pyzor and ~/.razor), where the user
> could be me, root or the "system". This includes the server updating
> process.
What I'm wondering is how this could end up creating directories /.razor
and /.pyzor since the root directory (as opposed to the /root directory)
is not the home directory of any user, and shouldn't be writable by
anyone other than root.
Not sure about why /.razor and /.pyzor get created. The files in them
are stamped with the same date/time as the cron jobs, however do not get
updated when I run the same update programs from the CLI as with root's
below. Something with ENV variables or UID I suspect, but not sure.
The root dirs (/root/.pyzor and /root/.razor, as well as the razor log
file in /root) seem to get created during the cron jobs and I could
replicate this from the CLI.
However, see more below.
> It occurs to me that one potential confounding variable here is
that I
> am running these processes as a local user on a single user system,
> rather than a system-wide approach as one might do with a central server
> processing incoming e-mail for multiple user accounts. That includes my
> use of ~/.procmailrc as the primary means to process both virus (via
> clamassassin/clamav) and spam (via SA + these additional tools).
>
> Presumably a SysAdmin on a multi-user system would take a different
> approach and perhaps would use other means to integrate the processing
> of viri and spam (such as Amavis as Nicolas has mentioned). This would
> afford other approaches to the default configuration of these other tools.
The spamassassin wiki has a page on this:
http://wiki.apache.org/spamassassin/UsingPyzor
Thanks for this. In addition, I read through:
http://wiki.apache.org/spamassassin/RazorSiteWide
http://wiki.apache.org/spamassassin/UsingRazor
http://wiki.apache.org/spamassassin/InstallingDCC
http://wiki.apache.org/spamassassin/UsingDcc
The result of which is the following:
1. I made the following adds in /etc/mail/spamassassin/local.cf:
pyzor_options --homedir /etc/mail/spamassassin
razor_config /etc/mail/spamassassin/.razor/razor-agent.conf
2. I created /etc/mail/spamassassin/.razor/razor-agent.conf, which
contains:
razorhome = /etc/mail/spamassassin/.razor/
3. I modified the /etc/crontab commands that execute the pyzor and razor
updates to:
# Run pyzor update at 1:10 am
10 01 * * * root /usr/bin/pyzor --homedir /etc/mail/spamassassin discover > /dev/null
# Run razor update at 1:20 am
20 01 * * * root /usr/bin/razor-admin -home=/etc/mail/spamassassin/.razor -discover >
/dev/null
The above now force the use of the system-wide SA settings in 1 and 2
above.
Note also that there is /etc/sysconfig/spamassassin, which contains:
SPAMDOPTIONS="-d -c -m2 -H"
I only modified the '-m2' option to reduce the number of concurrent
sessions from 5 (-m5) to 2. The '-H' options enables the specification
of a different HOME directory, which then enables the use of the above
config files for razor and pyzor when spamc/d are called. The other
options are FC installed defaults.
The result of all of this is that the pyzor and razor updates are now
limited to the system-wide file(s) in:
# For pyzor, the single file
/etc/mail/spamassassin/servers
# For razor, the dir tree
/etc/mail/spamassassin/.razor/*
Thus, no more user specific files are created. Yeah! :-)
Note also, that I _did not_ create new user groups to run these apps, as
is suggested on some of the above pages. The current configuration seems
to solve the problem without those additional steps.
> To Nicolas' points below, there are some issues with these
things moving
> in a non-GPL mode, if they are not already there. I do note however
> that both razor and pyzor are still in Extras for FC5 and are present in
> Extras for devel (http://fedoraproject.org/extras/development/i386/). I
> also whole heartedly support his contention that these tools
> dramatically improve the processing of spam.
>
> In either case, one option for me here within the notion of this being a
> single user process, is to move the cron jobs that update razor and
> pyzor from the system /etc/crontab to my user cron file vie "crontab -e"
> (/var/spool/cron/marcs). I already have fetchmail and some backup
> scripts running there anyway.
I think that would be a good move; it should at least prevent the
creation of directories straight under the root.
Well...hopefully with the above, we should be good to go, save DCC.
> The dcc update process would need to stay in /etc/crontab since
it
> downloads, compiles and installs the system-wide dcc client.
Compiles as root? Ugh!
Yep. If there are any options on the DCC install page that I noted in
my other reply that make sense here, let me know. I am willing to try
alternatives.
Of course, let me know on the dccproc context change and what you might
want to do about that.
> Another option, perhaps, would be for the FE razor and pyzor
maintainers
> to adjust the respective app defaults for FE with an eye towards SELinux
> policy issues in future updates. In that way, perhaps the default
> locations could be in /etc or /var as Nicolas notes above. That might
> provide for a means to handle both single user and multi user
> configurations, though the impact on other tools would need to be
> considered as may be appropriate.
If we can figure how how to make them work sanely, I'm confident that
the maintainers would be open to suggestions (preferably with patches).
Well, hopefully we are on the right track with the above.
OK...so now with all of that going on, here are the latest avc's:
# semodule -l
amavis 1.0.4
clamav 1.0.1
dcc 1.0.0
myclamav 0.1.1
mydcc 0.1.6
mypostfix 0.1.0
mypyzor 0.2.1
myspamassassin 0.1.1
procmail 0.5.4
pyzor 1.0.1
razor 1.0.0
type=AVC msg=audit(1151351642.927:3274): avc: denied { use } for pid=26956
comm="clamassassin" name="[251491]" dev=pipefs ino=251491
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fd
type=AVC msg=audit(1151351642.927:3274): avc: denied { write } for pid=26956
comm="clamassassin" name="[251491]" dev=pipefs ino=251491
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151351642.927:3274): arch=40000003 syscall=11 success=yes exit=0
a0=9502d60 a1=9502008 a2=95058f0 a3=0 items=3 pid=26956 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.927:3274): path="pipe:[251491]"
type=AVC_PATH msg=audit(1151351642.927:3274): path="pipe:[251491]"
type=CWD msg=audit(1151351642.927:3274): cwd="/home/marcs"
type=PATH msg=audit(1151351642.927:3274): item=0
name="/usr/local/bin/clamassassin" inode=3115337 dev=16:07 mode=0100555 ouid=0
ogid=0 rdev=00:00 obj=system_u:object_r:clamassassin_exec_t:s0
type=PATH msg=audit(1151351642.927:3274): item=1 name=(null) inode=1966191 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:shell_exec_t:s0
type=PATH msg=audit(1151351642.927:3274): item=2 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
type=AVC msg=audit(1151351642.927:3275): avc: denied { search } for pid=26956
comm="clamassassin" name="etc" dev=hdc7 ino=1048577
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:etc_t:s0
tclass=dir
type=SYSCALL msg=audit(1151351642.927:3275): arch=40000003 syscall=33 success=no exit=-2
a0=47fcc4df a1=4 a2=47fcffd8 a3=47fd06b8 items=1 pid=26956 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151351642.927:3275): cwd="/home/marcs"
type=PATH msg=audit(1151351642.927:3275): item=0 name="/etc/ld.so.preload"
obj=system_u:object_r:clamassassin_exec_t:s0
type=AVC msg=audit(1151351642.931:3276): avc: denied { read } for pid=26956
comm="clamassassin" name="ld.so.cache" dev=hdc7 ino=1049124
scontext=system_u:system_r:clamassassin_t:s0 tcontext=user_u:object_r:ld_so_cache_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.931:3276): arch=40000003 syscall=5 success=yes exit=3
a0=47fcc6c7 a1=0 a2=0 a3=47fd0890 items=1 pid=26956 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151351642.931:3276): cwd="/home/marcs"
type=PATH msg=audit(1151351642.931:3276): item=0 name="/etc/ld.so.cache"
inode=1049124 dev=16:07 mode=0100644 ouid=0 ogid=0 rdev=00:00
obj=user_u:object_r:ld_so_cache_t:s0
type=AVC msg=audit(1151351642.931:3277): avc: denied { getattr } for pid=26956
comm="clamassassin" name="ld.so.cache" dev=hdc7 ino=1049124
scontext=system_u:system_r:clamassassin_t:s0 tcontext=user_u:object_r:ld_so_cache_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.931:3277): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bfee7a5c a2=47fcffd8 a3=ffffffff items=0 pid=26956 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.931:3277): path="/etc/ld.so.cache"
type=AVC msg=audit(1151351642.931:3278): avc: denied { search } for pid=26956
comm="clamassassin" name="lib" dev=hdc7 ino=753665
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=dir
type=AVC msg=audit(1151351642.931:3278): avc: denied { read } for pid=26956
comm="clamassassin" name="libtermcap.so.2" dev=hdc7 ino=753723
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=lnk_file
type=AVC msg=audit(1151351642.931:3278): avc: denied { read } for pid=26956
comm="clamassassin" name="libtermcap.so.2.0.8" dev=hdc7 ino=754516
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.931:3278): arch=40000003 syscall=5 success=yes exit=3
a0=b7f95e11 a1=0 a2=1f3a0 a3=8 items=1 pid=26956 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamassassin"
exe="/bin/bash" subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151351642.931:3278): cwd="/home/marcs"
type=PATH msg=audit(1151351642.931:3278): item=0 name="/lib/libtermcap.so.2"
inode=754516 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:lib_t:s0
type=AVC msg=audit(1151351642.931:3279): avc: denied { getattr } for pid=26956
comm="clamassassin" name="libtermcap.so.2.0.8" dev=hdc7 ino=754516
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.931:3279): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bfee7ae0 a2=47fcffd8 a3=3 items=0 pid=26956 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.931:3279): path="/lib/libtermcap.so.2.0.8"
type=AVC msg=audit(1151351642.931:3280): avc: denied { execute } for pid=26956
comm="clamassassin" name="libtermcap.so.2.0.8" dev=hdc7 ino=754516
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.931:3280): arch=40000003 syscall=192 success=yes
exit=1208868864 a0=480de000 a1=3a88 a2=5 a3=802 items=0 pid=26956 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.931:3280): path="/lib/libtermcap.so.2.0.8"
type=AVC msg=audit(1151351642.931:3281): avc: denied { read } for pid=26956
comm="clamassassin" name="ld-2.4.so" dev=hdc7 ino=754491
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:ld_so_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.931:3281): arch=40000003 syscall=125 success=yes exit=0
a0=47fcf000 a1=1000 a2=1 a3=47fd0300 items=0 pid=26956 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.931:3281): path="/lib/ld-2.4.so"
type=AVC msg=audit(1151351642.931:3282): avc: denied { search } for pid=26956
comm="clamassassin" name="/" dev=proc ino=1
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=dir
type=AVC msg=audit(1151351642.931:3282): avc: denied { read } for pid=26956
comm="clamassassin" name="meminfo" dev=proc ino=-268435454
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.931:3282): arch=40000003 syscall=5 success=yes exit=3
a0=489093ef a1=0 a2=1b6 a3=9555240 items=1 pid=26956 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151351642.931:3282): cwd="/home/marcs"
type=PATH msg=audit(1151351642.931:3282): item=0 name="/proc/meminfo"
inode=4026531842 dev=00:03 mode=0100444 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:proc_t:s0
type=AVC msg=audit(1151351642.931:3283): avc: denied { getattr } for pid=26956
comm="clamassassin" name="meminfo" dev=proc ino=-268435454
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.931:3283): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bfee6038 a2=4891eff4 a3=3 items=0 pid=26956 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.931:3283): path="/proc/meminfo"
type=AVC msg=audit(1151351642.935:3284): avc: denied { search } for pid=26956
comm="clamassassin" name="usr" dev=hdc7 ino=3112961
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:usr_t:s0
tclass=dir
type=AVC msg=audit(1151351642.935:3284): avc: denied { search } for pid=26956
comm="clamassassin" name="bin" dev=hdc7 ino=3112982
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=dir
type=SYSCALL msg=audit(1151351642.935:3284): arch=40000003 syscall=5 success=yes exit=3
a0=9557018 a1=8000 a2=0 a3=8000 items=1 pid=26956 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamassassin"
exe="/bin/bash" subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151351642.935:3284): cwd="/home/marcs"
type=PATH msg=audit(1151351642.935:3284): item=0
name="/usr/local/bin/clamassassin" inode=3115337 dev=16:07 mode=0100555 ouid=0
ogid=0 rdev=00:00 obj=system_u:object_r:clamassassin_exec_t:s0
type=AVC msg=audit(1151351642.943:3285): avc: denied { execute } for pid=26957
comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=AVC msg=audit(1151351642.943:3285): avc: denied { execute_no_trans } for pid=26957
comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=AVC msg=audit(1151351642.943:3285): avc: denied { read } for pid=26957
comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=AVC msg=audit(1151351642.943:3285): avc: denied { execute } for pid=26957
comm="clamassassin" name="ld-2.4.so" dev=hdc7 ino=754491
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:ld_so_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.943:3285): arch=40000003 syscall=11 success=yes exit=0
a0=95572c0 a1=9557500 a2=955add0 a3=9557228 items=2 pid=26957 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="mktemp" exe="/bin/mktemp"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.943:3285): path="/bin/mktemp"
type=AVC_PATH msg=audit(1151351642.943:3285): path="/bin/mktemp"
type=CWD msg=audit(1151351642.943:3285): cwd="/home/marcs"
type=PATH msg=audit(1151351642.943:3285): item=0 name="/bin/mktemp"
inode=1966111 dev=16:07 mode=0100555 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:bin_t:s0
type=PATH msg=audit(1151351642.943:3285): 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
type=AVC msg=audit(1151351642.943:3286): avc: denied { read } for pid=26957
comm="mktemp" name="urandom" dev=tmpfs ino=2006
scontext=system_u:system_r:clamassassin_t:s0
tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1151351642.943:3286): arch=40000003 syscall=5 success=yes exit=3
a0=80494d8 a1=0 a2=48920120 a3=85af008 items=1 pid=26957 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="mktemp"
exe="/bin/mktemp" subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151351642.943:3286): cwd="/home/marcs"
type=PATH msg=audit(1151351642.943:3286): item=0 name="/dev/urandom" inode=2006
dev=00:0f mode=020444 ouid=0 ogid=0 rdev=01:09 obj=system_u:object_r:urandom_device_t:s0
type=AVC msg=audit(1151351642.947:3287): avc: denied { getattr } for pid=26957
comm="mktemp" name="[251497]" dev=pipefs ino=251497
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:clamassassin_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151351642.947:3287): arch=40000003 syscall=197 success=yes exit=0
a0=1 a1=bf8893d0 a2=4891eff4 a3=1 items=0 pid=26957 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="mktemp"
exe="/bin/mktemp" subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.947:3287): path="pipe:[251497]"
type=AVC msg=audit(1151351642.947:3288): avc: denied { write } for pid=26957
comm="mktemp" name="[251497]" dev=pipefs ino=251497
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:clamassassin_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151351642.947:3288): arch=40000003 syscall=4 success=yes exit=32
a0=1 a1=b7f9b000 a2=20 a3=20 items=0 pid=26957 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="mktemp"
exe="/bin/mktemp" subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.947:3288): path="pipe:[251497]"
type=AVC msg=audit(1151351642.947:3289): avc: denied { read } for pid=26956
comm="clamassassin" name="[251497]" dev=pipefs ino=251497
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:clamassassin_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151351642.947:3289): arch=40000003 syscall=3 success=yes exit=32
a0=3 a1=bfee7a18 a2=80 a3=80 items=0 pid=26956 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamassassin"
exe="/bin/bash" subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.947:3289): path="pipe:[251497]"
type=AVC msg=audit(1151351642.955:3290): avc: denied { use } for pid=26960
comm="clamscan" name="[251496]" dev=pipefs ino=251496
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:procmail_t:s0
tclass=fd
type=AVC msg=audit(1151351642.955:3290): avc: denied { read } for pid=26960
comm="clamscan" name="[251496]" dev=pipefs ino=251496
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:procmail_t:s0
tclass=fifo_file
type=AVC msg=audit(1151351642.955:3290): avc: denied { use } for pid=26960
comm="clamscan" name="[251491]" dev=pipefs ino=251491
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fd
type=AVC msg=audit(1151351642.955:3290): avc: denied { write } for pid=26960
comm="clamscan" name="[251491]" dev=pipefs ino=251491
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151351642.955:3290): arch=40000003 syscall=11 success=yes exit=0
a0=955ac00 a1=955a210 a2=955add0 a3=955ad90 items=2 pid=26960 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamscan" exe="/usr/bin/clamscan"
subj=system_u:system_r:clamscan_t:s0
type=AVC_PATH msg=audit(1151351642.955:3290): path="pipe:[251491]"
type=AVC_PATH msg=audit(1151351642.955:3290): path="pipe:[251491]"
type=AVC_PATH msg=audit(1151351642.955:3290): path="pipe:[251496]"
type=AVC_PATH msg=audit(1151351642.955:3290): path="pipe:[251496]"
type=CWD msg=audit(1151351642.955:3290): cwd="/home/marcs"
type=PATH msg=audit(1151351642.955:3290): item=0 name="/usr/bin/clamscan"
inode=3123838 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:clamscan_exec_t:s0
type=PATH msg=audit(1151351642.955:3290): 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
type=AVC msg=audit(1151351646.796:3291): avc: denied { search } for pid=26970
comm="pyzor" name="mail" dev=hdc7 ino=1049593
scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir
type=SYSCALL msg=audit(1151351646.796:3291): arch=40000003 syscall=5 success=no exit=-2
a0=99817f8 a1=8000 a2=1b6 a3=99337c8 items=1 pid=26970 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=CWD msg=audit(1151351646.796:3291): cwd="/"
type=PATH msg=audit(1151351646.796:3291): item=0
name="/etc/mail/spamassassin/config" obj=system_u:object_r:lib_t:s0
type=AVC msg=audit(1151351646.796:3292): avc: denied { getattr } for pid=26970
comm="pyzor" name="spamassassin" dev=hdc7 ino=1049810
scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir
type=SYSCALL msg=audit(1151351646.796:3292): arch=40000003 syscall=195 success=yes exit=0
a0=9982a78 a1=bfae9548 a2=4891eff4 a3=98f91b0 items=1 pid=26970 auid=4294967295 uid=500
gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="pyzor" exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=AVC_PATH msg=audit(1151351646.796:3292): path="/etc/mail/spamassassin"
type=CWD msg=audit(1151351646.796:3292): cwd="/"
type=PATH msg=audit(1151351646.796:3292): item=0 name="/etc/mail/spamassassin"
inode=1049810 dev=16:07 mode=040755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:etc_mail_t:s0
type=AVC msg=audit(1151351646.796:3293): avc: denied { getattr } for pid=26970
comm="pyzor" name="servers" dev=hdc7 ino=1051662
scontext=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file
type=SYSCALL msg=audit(1151351646.796:3293): arch=40000003 syscall=195 success=yes exit=0
a0=9982a78 a1=bfae9548 a2=4891eff4 a3=98f91b0 items=1 pid=26970 auid=4294967295 uid=500
gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="pyzor" exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=AVC_PATH msg=audit(1151351646.796:3293):
path="/etc/mail/spamassassin/servers"
type=CWD msg=audit(1151351646.796:3293): cwd="/"
type=PATH msg=audit(1151351646.796:3293): item=0
name="/etc/mail/spamassassin/servers" inode=1051662 dev=16:07 mode=0100644
ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0
type=AVC msg=audit(1151351646.796:3294): avc: denied { read } for pid=26970
comm="pyzor" name="servers" dev=hdc7 ino=1051662
scontext=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file
type=SYSCALL msg=audit(1151351646.796:3294): arch=40000003 syscall=5 success=yes exit=3
a0=9982a78 a1=8000 a2=1b6 a3=99337c8 items=1 pid=26970 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=CWD msg=audit(1151351646.796:3294): cwd="/"
type=PATH msg=audit(1151351646.796:3294): item=0
name="/etc/mail/spamassassin/servers" inode=1051662 dev=16:07 mode=0100644
ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0
type=AVC msg=audit(1151351651.760:3295): avc: denied { create } for pid=26973
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151351651.760:3295): arch=40000003 syscall=102 success=yes exit=3
a0=1 a1=bfaecda8 a2=4891eff4 a3=806a0ff items=0 pid=26973 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=SOCKETCALL msg=audit(1151351651.760:3295): nargs=3 a0=10 a1=3 a2=0
type=AVC msg=audit(1151351651.760:3296): avc: denied { bind } for pid=26973
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151351651.760:3296): arch=40000003 syscall=102 success=yes exit=0
a0=2 a1=bfaecda8 a2=4891eff4 a3=3 items=0 pid=26973 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(1151351651.760:3296): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151351651.760:3296): nargs=3 a0=3 a1=bfaecdb4 a2=c
type=AVC msg=audit(1151351651.760:3297): avc: denied { getattr } for pid=26973
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151351651.760:3297): arch=40000003 syscall=102 success=yes exit=0
a0=6 a1=bfaecda8 a2=4891eff4 a3=3 items=0 pid=26973 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(1151351651.760:3297): saddr=100000005D69000000000000
type=SOCKETCALL msg=audit(1151351651.760:3297): nargs=3 a0=3 a1=bfaecdb4 a2=bfaecdc0
type=AVC msg=audit(1151351651.760:3298): avc: denied { write } for pid=26973
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=AVC msg=audit(1151351651.760:3298): avc: denied { nlmsg_read } for pid=26973
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151351651.760:3298): arch=40000003 syscall=102 success=yes exit=20
a0=b a1=bfaebcf4 a2=4891eff4 a3=ffffffcc items=0 pid=26973 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(1151351651.760:3298): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151351651.760:3298): nargs=6 a0=3 a1=bfaecd6c a2=14 a3=0
a4=bfaecd80 a5=c
type=AVC msg=audit(1151351651.760:3299): avc: denied { read } for pid=26973
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151351651.760:3299): arch=40000003 syscall=102 success=yes
exit=128 a0=11 a1=bfaebcf4 a2=4891eff4 a3=ffffffcc items=0 pid=26973 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(1151351651.760:3299): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151351651.760:3299): nargs=3 a0=3 a1=bfaecd50 a2=0
type=AVC msg=audit(1151351651.764:3300): avc: denied { node_bind } for pid=26973
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(1151351651.764:3300): arch=40000003 syscall=102 success=yes exit=0
a0=2 a1=bfaecde0 a2=4891eff4 a3=806a0ff items=0 pid=26973 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(1151351651.764:3300): saddr=02000000000000000000000000000000
type=SOCKETCALL msg=audit(1151351651.764:3300): nargs=3 a0=4 a1=bfaece84 a2=10
type=AVC msg=audit(1151352002.668:3347): avc: denied { use } for pid=28046
comm="clamassassin" name="[254837]" dev=pipefs ino=254837
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fd
type=AVC msg=audit(1151352002.668:3347): avc: denied { write } for pid=28046
comm="clamassassin" name="[254837]" dev=pipefs ino=254837
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151352002.668:3347): arch=40000003 syscall=11 success=yes exit=0
a0=8f3ad60 a1=8f3a008 a2=8f3d6d0 a3=0 items=3 pid=28046 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352002.668:3347): path="pipe:[254837]"
type=AVC_PATH msg=audit(1151352002.668:3347): path="pipe:[254837]"
type=CWD msg=audit(1151352002.668:3347): cwd="/home/marcs"
type=PATH msg=audit(1151352002.668:3347): item=0
name="/usr/local/bin/clamassassin" inode=3115337 dev=16:07 mode=0100555 ouid=0
ogid=0 rdev=00:00 obj=system_u:object_r:clamassassin_exec_t:s0
type=PATH msg=audit(1151352002.668:3347): item=1 name=(null) inode=1966191 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:shell_exec_t:s0
type=PATH msg=audit(1151352002.668:3347): item=2 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
type=AVC msg=audit(1151352002.668:3348): avc: denied { search } for pid=28046
comm="clamassassin" name="etc" dev=hdc7 ino=1048577
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:etc_t:s0
tclass=dir
type=SYSCALL msg=audit(1151352002.668:3348): arch=40000003 syscall=33 success=no exit=-2
a0=47fcc4df a1=4 a2=47fcffd8 a3=47fd06b8 items=1 pid=28046 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151352002.668:3348): cwd="/home/marcs"
type=PATH msg=audit(1151352002.668:3348): item=0 name="/etc/ld.so.preload"
obj=system_u:object_r:clamassassin_exec_t:s0
type=AVC msg=audit(1151352002.668:3349): avc: denied { read } for pid=28046
comm="clamassassin" name="ld.so.cache" dev=hdc7 ino=1049124
scontext=system_u:system_r:clamassassin_t:s0 tcontext=user_u:object_r:ld_so_cache_t:s0
tclass=file
type=SYSCALL msg=audit(1151352002.668:3349): arch=40000003 syscall=5 success=yes exit=3
a0=47fcc6c7 a1=0 a2=0 a3=47fd0890 items=1 pid=28046 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151352002.668:3349): cwd="/home/marcs"
type=PATH msg=audit(1151352002.668:3349): item=0 name="/etc/ld.so.cache"
inode=1049124 dev=16:07 mode=0100644 ouid=0 ogid=0 rdev=00:00
obj=user_u:object_r:ld_so_cache_t:s0
type=AVC msg=audit(1151352002.668:3350): avc: denied { getattr } for pid=28046
comm="clamassassin" name="ld.so.cache" dev=hdc7 ino=1049124
scontext=system_u:system_r:clamassassin_t:s0 tcontext=user_u:object_r:ld_so_cache_t:s0
tclass=file
type=SYSCALL msg=audit(1151352002.668:3350): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bfd1d08c a2=47fcffd8 a3=ffffffff items=0 pid=28046 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352002.668:3350): path="/etc/ld.so.cache"
type=AVC msg=audit(1151352002.668:3351): avc: denied { search } for pid=28046
comm="clamassassin" name="lib" dev=hdc7 ino=753665
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=dir
type=AVC msg=audit(1151352002.668:3351): avc: denied { read } for pid=28046
comm="clamassassin" name="libtermcap.so.2.0.8" dev=hdc7 ino=754516
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1151352002.668:3351): arch=40000003 syscall=5 success=yes exit=3
a0=b7f30e11 a1=0 a2=1f3a0 a3=8 items=1 pid=28046 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamassassin"
exe="/bin/bash" subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151352002.668:3351): cwd="/home/marcs"
type=PATH msg=audit(1151352002.668:3351): item=0 name="/lib/libtermcap.so.2"
inode=754516 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:lib_t:s0
type=AVC msg=audit(1151352002.668:3352): avc: denied { getattr } for pid=28046
comm="clamassassin" name="libtermcap.so.2.0.8" dev=hdc7 ino=754516
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1151352002.668:3352): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bfd1d110 a2=47fcffd8 a3=3 items=0 pid=28046 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352002.668:3352): path="/lib/libtermcap.so.2.0.8"
type=AVC msg=audit(1151352002.668:3353): avc: denied { execute } for pid=28046
comm="clamassassin" name="libtermcap.so.2.0.8" dev=hdc7 ino=754516
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1151352002.668:3353): arch=40000003 syscall=192 success=yes
exit=1208868864 a0=480de000 a1=3a88 a2=5 a3=802 items=0 pid=28046 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352002.668:3353): path="/lib/libtermcap.so.2.0.8"
type=AVC msg=audit(1151352002.668:3354): avc: denied { read } for pid=28046
comm="clamassassin" name="ld-2.4.so" dev=hdc7 ino=754491
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:ld_so_t:s0
tclass=file
type=SYSCALL msg=audit(1151352002.668:3354): arch=40000003 syscall=125 success=yes exit=0
a0=47fcf000 a1=1000 a2=1 a3=47fd0300 items=0 pid=28046 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352002.668:3354): path="/lib/ld-2.4.so"
type=AVC msg=audit(1151352002.672:3355): avc: denied { search } for pid=28046
comm="clamassassin" name="/" dev=proc ino=1
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=dir
type=AVC msg=audit(1151352002.672:3355): avc: denied { read } for pid=28046
comm="clamassassin" name="meminfo" dev=proc ino=-268435454
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=file
type=SYSCALL msg=audit(1151352002.672:3355): arch=40000003 syscall=5 success=yes exit=3
a0=489093ef a1=0 a2=1b6 a3=90ba240 items=1 pid=28046 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151352002.672:3355): cwd="/home/marcs"
type=PATH msg=audit(1151352002.672:3355): item=0 name="/proc/meminfo"
inode=4026531842 dev=00:03 mode=0100444 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:proc_t:s0
type=AVC msg=audit(1151352002.672:3356): avc: denied { getattr } for pid=28046
comm="clamassassin" name="meminfo" dev=proc ino=-268435454
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=file
type=SYSCALL msg=audit(1151352002.672:3356): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bfd1b668 a2=4891eff4 a3=3 items=0 pid=28046 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352002.672:3356): path="/proc/meminfo"
type=AVC msg=audit(1151352002.672:3357): avc: denied { search } for pid=28046
comm="clamassassin" name="usr" dev=hdc7 ino=3112961
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:usr_t:s0
tclass=dir
type=AVC msg=audit(1151352002.672:3357): avc: denied { search } for pid=28046
comm="clamassassin" name="bin" dev=hdc7 ino=3112982
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=dir
type=SYSCALL msg=audit(1151352002.672:3357): arch=40000003 syscall=5 success=yes exit=3
a0=90bc018 a1=8000 a2=0 a3=8000 items=1 pid=28046 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamassassin"
exe="/bin/bash" subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151352002.672:3357): cwd="/home/marcs"
type=PATH msg=audit(1151352002.672:3357): item=0
name="/usr/local/bin/clamassassin" inode=3115337 dev=16:07 mode=0100555 ouid=0
ogid=0 rdev=00:00 obj=system_u:object_r:clamassassin_exec_t:s0
type=AVC msg=audit(1151352002.700:3358): avc: denied { execute } for pid=28047
comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=AVC msg=audit(1151352002.700:3358): avc: denied { execute_no_trans } for pid=28047
comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=AVC msg=audit(1151352002.700:3358): avc: denied { read } for pid=28047
comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=AVC msg=audit(1151352002.700:3358): avc: denied { execute } for pid=28047
comm="clamassassin" name="ld-2.4.so" dev=hdc7 ino=754491
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:ld_so_t:s0
tclass=file
type=AVC msg=audit(1151352002.704:3359): avc: denied { read } for pid=28046
comm="clamassassin" name="[254843]" dev=pipefs ino=254843
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:clamassassin_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151352002.700:3358): arch=40000003 syscall=11 success=yes exit=0
a0=90bc2c0 a1=90bc500 a2=90bfdd0 a3=90bc228 items=2 pid=28047 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="mktemp" exe="/bin/mktemp"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352002.700:3358): path="/bin/mktemp"
type=AVC_PATH msg=audit(1151352002.700:3358): path="/bin/mktemp"
type=CWD msg=audit(1151352002.700:3358): cwd="/home/marcs"
type=PATH msg=audit(1151352002.700:3358): item=0 name="/bin/mktemp"
inode=1966111 dev=16:07 mode=0100555 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:bin_t:s0
type=PATH msg=audit(1151352002.700:3358): 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
type=AVC msg=audit(1151352002.704:3360): avc: denied { read } for pid=28047
comm="mktemp" name="urandom" dev=tmpfs ino=2006
scontext=system_u:system_r:clamassassin_t:s0
tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1151352002.704:3360): arch=40000003 syscall=5 success=yes exit=3
a0=80494d8 a1=0 a2=48920120 a3=86e5008 items=1 pid=28047 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="mktemp"
exe="/bin/mktemp" subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151352002.704:3360): cwd="/home/marcs"
type=PATH msg=audit(1151352002.704:3360): item=0 name="/dev/urandom" inode=2006
dev=00:0f mode=020444 ouid=0 ogid=0 rdev=01:09 obj=system_u:object_r:urandom_device_t:s0
type=AVC msg=audit(1151352002.708:3361): avc: denied { getattr } for pid=28047
comm="mktemp" name="[254843]" dev=pipefs ino=254843
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:clamassassin_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151352002.708:3361): arch=40000003 syscall=197 success=yes exit=0
a0=1 a1=bf832b70 a2=4891eff4 a3=1 items=0 pid=28047 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="mktemp"
exe="/bin/mktemp" subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352002.708:3361): path="pipe:[254843]"
type=AVC msg=audit(1151352002.708:3362): avc: denied { write } for pid=28047
comm="mktemp" name="[254843]" dev=pipefs ino=254843
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:clamassassin_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151352002.704:3359): arch=40000003 syscall=3 success=yes exit=32
a0=3 a1=bfd1d048 a2=80 a3=80 items=0 pid=28046 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamassassin"
exe="/bin/bash" subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352002.704:3359): path="pipe:[254843]"
type=SYSCALL msg=audit(1151352002.708:3362): arch=40000003 syscall=4 success=yes exit=32
a0=1 a1=b7f65000 a2=20 a3=20 items=0 pid=28047 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="mktemp"
exe="/bin/mktemp" subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352002.708:3362): path="pipe:[254843]"
type=AVC msg=audit(1151352002.716:3363): avc: denied { use } for pid=28050
comm="clamscan" name="[254842]" dev=pipefs ino=254842
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:procmail_t:s0
tclass=fd
type=AVC msg=audit(1151352002.716:3363): avc: denied { read } for pid=28050
comm="clamscan" name="[254842]" dev=pipefs ino=254842
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:procmail_t:s0
tclass=fifo_file
type=AVC msg=audit(1151352002.716:3363): avc: denied { use } for pid=28050
comm="clamscan" name="[254837]" dev=pipefs ino=254837
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fd
type=AVC msg=audit(1151352002.716:3363): avc: denied { write } for pid=28050
comm="clamscan" name="[254837]" dev=pipefs ino=254837
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151352002.716:3363): arch=40000003 syscall=11 success=yes exit=0
a0=90bfc00 a1=90bf210 a2=90bfdd0 a3=90bfd90 items=2 pid=28050 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamscan" exe="/usr/bin/clamscan"
subj=system_u:system_r:clamscan_t:s0
type=AVC_PATH msg=audit(1151352002.716:3363): path="pipe:[254837]"
type=AVC_PATH msg=audit(1151352002.716:3363): path="pipe:[254837]"
type=AVC_PATH msg=audit(1151352002.716:3363): path="pipe:[254842]"
type=AVC_PATH msg=audit(1151352002.716:3363): path="pipe:[254842]"
type=CWD msg=audit(1151352002.716:3363): cwd="/home/marcs"
type=PATH msg=audit(1151352002.716:3363): item=0 name="/usr/bin/clamscan"
inode=3123838 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:clamscan_exec_t:s0
type=PATH msg=audit(1151352002.716:3363): 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
type=AVC msg=audit(1151352004.572:3364): avc: denied { execute } for pid=28055
comm="clamassassin" name="ld-2.4.so" dev=hdc7 ino=754491
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:ld_so_t:s0
tclass=file
type=AVC msg=audit(1151352004.572:3364): avc: denied { read } for pid=28055
comm="clamassassin" name="ld-2.4.so" dev=hdc7 ino=754491
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:ld_so_t:s0
tclass=file
type=SYSCALL msg=audit(1151352004.572:3364): arch=40000003 syscall=11 success=yes exit=0
a0=90bde00 a1=90c0fc8 a2=90bfdd0 a3=90c0320 items=2 pid=28055 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="formail" exe="/usr/bin/formail"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352004.572:3364): path="/lib/ld-2.4.so"
type=CWD msg=audit(1151352004.572:3364): cwd="/home/marcs"
type=PATH msg=audit(1151352004.572:3364): item=0 name="/usr/bin/formail"
inode=3133721 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:bin_t:s0
type=PATH msg=audit(1151352004.572:3364): 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
type=AVC msg=audit(1151352004.576:3365): avc: denied { search } for pid=28055
comm="formail" name="etc" dev=hdc7 ino=1048577
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:etc_t:s0
tclass=dir
type=SYSCALL msg=audit(1151352004.576:3365): arch=40000003 syscall=33 success=no exit=-2
a0=47fcc4df a1=4 a2=47fcffd8 a3=47fd06b8 items=1 pid=28055 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="formail" exe="/usr/bin/formail"
subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151352004.576:3365): cwd="/home/marcs"
type=PATH msg=audit(1151352004.576:3365): item=0 name="/etc/ld.so.preload"
obj=system_u:object_r:bin_t:s0
type=AVC msg=audit(1151352004.576:3366): avc: denied { read } for pid=28055
comm="formail" name="ld.so.cache" dev=hdc7 ino=1049124
scontext=system_u:system_r:clamassassin_t:s0 tcontext=user_u:object_r:ld_so_cache_t:s0
tclass=file
type=SYSCALL msg=audit(1151352004.576:3366): arch=40000003 syscall=5 success=yes exit=3
a0=47fcc6c7 a1=0 a2=0 a3=47fd0890 items=1 pid=28055 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="formail" exe="/usr/bin/formail"
subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151352004.576:3366): cwd="/home/marcs"
type=PATH msg=audit(1151352004.576:3366): item=0 name="/etc/ld.so.cache"
inode=1049124 dev=16:07 mode=0100644 ouid=0 ogid=0 rdev=00:00
obj=user_u:object_r:ld_so_cache_t:s0
type=AVC msg=audit(1151352004.576:3367): avc: denied { getattr } for pid=28055
comm="formail" name="ld.so.cache" dev=hdc7 ino=1049124
scontext=system_u:system_r:clamassassin_t:s0 tcontext=user_u:object_r:ld_so_cache_t:s0
tclass=file
type=SYSCALL msg=audit(1151352004.576:3367): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bf8a234c a2=47fcffd8 a3=ffffffff items=0 pid=28055 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="formail" exe="/usr/bin/formail"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352004.576:3367): path="/etc/ld.so.cache"
type=AVC msg=audit(1151352004.576:3368): avc: denied { read } for pid=28055
comm="formail" name="libm-2.4.so" dev=hdc7 ino=754494
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1151352004.576:3368): arch=40000003 syscall=5 success=yes exit=3
a0=b7fa69ed a1=0 a2=1f3a0 a3=8 items=1 pid=28055 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="formail"
exe="/usr/bin/formail" subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151352004.576:3368): cwd="/home/marcs"
type=PATH msg=audit(1151352004.576:3368): item=0 name="/lib/libm.so.6"
inode=754494 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:lib_t:s0
type=AVC msg=audit(1151352004.576:3369): avc: denied { getattr } for pid=28055
comm="formail" name="libm-2.4.so" dev=hdc7 ino=754494
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1151352004.576:3369): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bf8a23d0 a2=47fcffd8 a3=3 items=0 pid=28055 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="formail" exe="/usr/bin/formail"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352004.576:3369): path="/lib/libm-2.4.so"
type=AVC msg=audit(1151352004.576:3370): avc: denied { execute } for pid=28055
comm="formail" name="libm-2.4.so" dev=hdc7 ino=754494
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1151352004.576:3370): arch=40000003 syscall=192 success=yes
exit=1217548288 a0=48925000 a1=24080 a2=5 a3=802 items=0 pid=28055 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="formail" exe="/usr/bin/formail"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352004.576:3370): path="/lib/libm-2.4.so"
type=AVC msg=audit(1151352006.532:3371): avc: denied { search } for pid=28060
comm="pyzor" name="mail" dev=hdc7 ino=1049593
scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir
type=SYSCALL msg=audit(1151352006.532:3371): arch=40000003 syscall=5 success=no exit=-2
a0=887a7f8 a1=8000 a2=1b6 a3=882c7c8 items=1 pid=28060 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=CWD msg=audit(1151352006.532:3371): cwd="/"
type=PATH msg=audit(1151352006.532:3371): item=0
name="/etc/mail/spamassassin/config" obj=system_u:object_r:lib_t:s0
type=AVC msg=audit(1151352006.532:3372): avc: denied { getattr } for pid=28060
comm="pyzor" name="spamassassin" dev=hdc7 ino=1049810
scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir
type=SYSCALL msg=audit(1151352006.532:3372): arch=40000003 syscall=195 success=yes exit=0
a0=887ba78 a1=bfe4d0a8 a2=4891eff4 a3=87f21b0 items=1 pid=28060 auid=4294967295 uid=500
gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="pyzor" exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=AVC_PATH msg=audit(1151352006.532:3372): path="/etc/mail/spamassassin"
type=CWD msg=audit(1151352006.532:3372): cwd="/"
type=PATH msg=audit(1151352006.532:3372): item=0 name="/etc/mail/spamassassin"
inode=1049810 dev=16:07 mode=040755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:etc_mail_t:s0
type=AVC msg=audit(1151352006.532:3373): avc: denied { getattr } for pid=28060
comm="pyzor" name="servers" dev=hdc7 ino=1051662
scontext=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file
type=SYSCALL msg=audit(1151352006.532:3373): arch=40000003 syscall=195 success=yes exit=0
a0=887ba78 a1=bfe4d0a8 a2=4891eff4 a3=87f21b0 items=1 pid=28060 auid=4294967295 uid=500
gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="pyzor" exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=AVC_PATH msg=audit(1151352006.532:3373):
path="/etc/mail/spamassassin/servers"
type=CWD msg=audit(1151352006.532:3373): cwd="/"
type=PATH msg=audit(1151352006.532:3373): item=0
name="/etc/mail/spamassassin/servers" inode=1051662 dev=16:07 mode=0100644
ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0
type=AVC msg=audit(1151352006.532:3374): avc: denied { read } for pid=28060
comm="pyzor" name="servers" dev=hdc7 ino=1051662
scontext=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file
type=SYSCALL msg=audit(1151352006.532:3374): arch=40000003 syscall=5 success=yes exit=3
a0=887ba78 a1=8000 a2=1b6 a3=882c7c8 items=1 pid=28060 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=CWD msg=audit(1151352006.532:3374): cwd="/"
type=PATH msg=audit(1151352006.532:3374): item=0
name="/etc/mail/spamassassin/servers" inode=1051662 dev=16:07 mode=0100644
ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0
type=AVC msg=audit(1151352011.445:3375): avc: denied { create } for pid=28243
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151352011.445:3375): arch=40000003 syscall=102 success=yes exit=3
a0=1 a1=bfea5968 a2=4891eff4 a3=806a0ff items=0 pid=28243 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=SOCKETCALL msg=audit(1151352011.445:3375): nargs=3 a0=10 a1=3 a2=0
type=AVC msg=audit(1151352011.445:3376): avc: denied { bind } for pid=28243
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151352011.445:3376): arch=40000003 syscall=102 success=yes exit=0
a0=2 a1=bfea5968 a2=4891eff4 a3=3 items=0 pid=28243 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(1151352011.445:3376): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151352011.445:3376): nargs=3 a0=3 a1=bfea5974 a2=c
type=AVC msg=audit(1151352011.445:3377): avc: denied { getattr } for pid=28243
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151352011.445:3377): arch=40000003 syscall=102 success=yes exit=0
a0=6 a1=bfea5968 a2=4891eff4 a3=3 items=0 pid=28243 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(1151352011.445:3377): saddr=10000000536E000000000000
type=SOCKETCALL msg=audit(1151352011.445:3377): nargs=3 a0=3 a1=bfea5974 a2=bfea5980
type=AVC msg=audit(1151352011.449:3378): avc: denied { write } for pid=28243
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=AVC msg=audit(1151352011.449:3378): avc: denied { nlmsg_read } for pid=28243
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151352011.449:3378): arch=40000003 syscall=102 success=yes exit=20
a0=b a1=bfea48b4 a2=4891eff4 a3=ffffffcc items=0 pid=28243 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(1151352011.449:3378): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151352011.449:3378): nargs=6 a0=3 a1=bfea592c a2=14 a3=0
a4=bfea5940 a5=c
type=AVC msg=audit(1151352011.449:3379): avc: denied { read } for pid=28243
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151352011.449:3379): arch=40000003 syscall=102 success=yes
exit=128 a0=11 a1=bfea48b4 a2=4891eff4 a3=ffffffcc items=0 pid=28243 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(1151352011.449:3379): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151352011.449:3379): nargs=3 a0=3 a1=bfea5910 a2=0
type=AVC msg=audit(1151352011.449:3380): avc: denied { node_bind } for pid=28243
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(1151352011.449:3380): arch=40000003 syscall=102 success=yes exit=0
a0=2 a1=bfea59a0 a2=4891eff4 a3=806a0ff items=0 pid=28243 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(1151352011.449:3380): saddr=02000000000000000000000000000000
type=SOCKETCALL msg=audit(1151352011.449:3380): nargs=3 a0=4 a1=bfea5a44 a2=10
type=AVC msg=audit(1151352842.172:3433): avc: denied { use } for pid=8966
comm="clamassassin" name="[261675]" dev=pipefs ino=261675
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fd
type=AVC msg=audit(1151352842.172:3433): avc: denied { write } for pid=8966
comm="clamassassin" name="[261675]" dev=pipefs ino=261675
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151352842.172:3433): arch=40000003 syscall=11 success=yes exit=0
a0=9657d60 a1=9657008 a2=9659db0 a3=0 items=3 pid=8966 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352842.172:3433): path="pipe:[261675]"
type=AVC_PATH msg=audit(1151352842.172:3433): path="pipe:[261675]"
type=CWD msg=audit(1151352842.172:3433): cwd="/home/marcs"
type=PATH msg=audit(1151352842.172:3433): item=0
name="/usr/local/bin/clamassassin" inode=3115337 dev=16:07 mode=0100555 ouid=0
ogid=0 rdev=00:00 obj=system_u:object_r:clamassassin_exec_t:s0
type=PATH msg=audit(1151352842.172:3433): item=1 name=(null) inode=1966191 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:shell_exec_t:s0
type=PATH msg=audit(1151352842.172:3433): item=2 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
type=AVC msg=audit(1151352842.176:3434): avc: denied { search } for pid=8966
comm="clamassassin" name="etc" dev=hdc7 ino=1048577
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:etc_t:s0
tclass=dir
type=SYSCALL msg=audit(1151352842.176:3434): arch=40000003 syscall=33 success=no exit=-2
a0=47fcc4df a1=4 a2=47fcffd8 a3=47fd06b8 items=1 pid=8966 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151352842.176:3434): cwd="/home/marcs"
type=PATH msg=audit(1151352842.176:3434): item=0 name="/etc/ld.so.preload"
obj=system_u:object_r:clamassassin_exec_t:s0
type=AVC msg=audit(1151352842.176:3435): avc: denied { read } for pid=8966
comm="clamassassin" name="ld.so.cache" dev=hdc7 ino=1049124
scontext=system_u:system_r:clamassassin_t:s0 tcontext=user_u:object_r:ld_so_cache_t:s0
tclass=file
type=SYSCALL msg=audit(1151352842.176:3435): arch=40000003 syscall=5 success=yes exit=3
a0=47fcc6c7 a1=0 a2=0 a3=47fd0890 items=1 pid=8966 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151352842.176:3435): cwd="/home/marcs"
type=PATH msg=audit(1151352842.176:3435): item=0 name="/etc/ld.so.cache"
inode=1049124 dev=16:07 mode=0100644 ouid=0 ogid=0 rdev=00:00
obj=user_u:object_r:ld_so_cache_t:s0
type=AVC msg=audit(1151352842.176:3436): avc: denied { getattr } for pid=8966
comm="clamassassin" name="ld.so.cache" dev=hdc7 ino=1049124
scontext=system_u:system_r:clamassassin_t:s0 tcontext=user_u:object_r:ld_so_cache_t:s0
tclass=file
type=SYSCALL msg=audit(1151352842.176:3436): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bf93acac a2=47fcffd8 a3=ffffffff items=0 pid=8966 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352842.176:3436): path="/etc/ld.so.cache"
type=AVC msg=audit(1151352842.176:3437): avc: denied { search } for pid=8966
comm="clamassassin" name="lib" dev=hdc7 ino=753665
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=dir
type=AVC msg=audit(1151352842.176:3437): avc: denied { read } for pid=8966
comm="clamassassin" name="libtermcap.so.2" dev=hdc7 ino=753723
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=lnk_file
type=AVC msg=audit(1151352842.176:3437): avc: denied { read } for pid=8966
comm="clamassassin" name="libtermcap.so.2.0.8" dev=hdc7 ino=754516
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1151352842.176:3437): arch=40000003 syscall=5 success=yes exit=3
a0=b7f9be11 a1=0 a2=1f3a0 a3=8 items=1 pid=8966 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamassassin"
exe="/bin/bash" subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151352842.176:3437): cwd="/home/marcs"
type=PATH msg=audit(1151352842.176:3437): item=0 name="/lib/libtermcap.so.2"
inode=754516 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:lib_t:s0
type=AVC msg=audit(1151352842.176:3438): avc: denied { getattr } for pid=8966
comm="clamassassin" name="libtermcap.so.2.0.8" dev=hdc7 ino=754516
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1151352842.176:3438): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bf93ad30 a2=47fcffd8 a3=3 items=0 pid=8966 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352842.176:3438): path="/lib/libtermcap.so.2.0.8"
type=AVC msg=audit(1151352842.176:3439): avc: denied { execute } for pid=8966
comm="clamassassin" name="libtermcap.so.2.0.8" dev=hdc7 ino=754516
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1151352842.176:3439): arch=40000003 syscall=192 success=yes
exit=1208868864 a0=480de000 a1=3a88 a2=5 a3=802 items=0 pid=8966 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352842.176:3439): path="/lib/libtermcap.so.2.0.8"
type=AVC msg=audit(1151352842.176:3440): avc: denied { read } for pid=8966
comm="clamassassin" name="ld-2.4.so" dev=hdc7 ino=754491
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:ld_so_t:s0
tclass=file
type=SYSCALL msg=audit(1151352842.176:3440): arch=40000003 syscall=125 success=yes exit=0
a0=47fcf000 a1=1000 a2=1 a3=47fd0300 items=0 pid=8966 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352842.176:3440): path="/lib/ld-2.4.so"
type=AVC msg=audit(1151352842.176:3441): avc: denied { search } for pid=8966
comm="clamassassin" name="/" dev=proc ino=1
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=dir
type=AVC msg=audit(1151352842.176:3441): avc: denied { read } for pid=8966
comm="clamassassin" name="meminfo" dev=proc ino=-268435454
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=file
type=SYSCALL msg=audit(1151352842.176:3441): arch=40000003 syscall=5 success=yes exit=3
a0=489093ef a1=0 a2=1b6 a3=9f4f240 items=1 pid=8966 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151352842.176:3441): cwd="/home/marcs"
type=PATH msg=audit(1151352842.176:3441): item=0 name="/proc/meminfo"
inode=4026531842 dev=00:03 mode=0100444 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:proc_t:s0
type=AVC msg=audit(1151352842.176:3442): avc: denied { getattr } for pid=8966
comm="clamassassin" name="meminfo" dev=proc ino=-268435454
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=file
type=SYSCALL msg=audit(1151352842.176:3442): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bf939288 a2=4891eff4 a3=3 items=0 pid=8966 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352842.176:3442): path="/proc/meminfo"
type=AVC msg=audit(1151352842.176:3443): avc: denied { search } for pid=8966
comm="clamassassin" name="usr" dev=hdc7 ino=3112961
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:usr_t:s0
tclass=dir
type=AVC msg=audit(1151352842.176:3443): avc: denied { search } for pid=8966
comm="clamassassin" name="bin" dev=hdc7 ino=3112982
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=dir
type=SYSCALL msg=audit(1151352842.176:3443): arch=40000003 syscall=5 success=yes exit=3
a0=9f51018 a1=8000 a2=0 a3=8000 items=1 pid=8966 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamassassin"
exe="/bin/bash" subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151352842.176:3443): cwd="/home/marcs"
type=PATH msg=audit(1151352842.176:3443): item=0
name="/usr/local/bin/clamassassin" inode=3115337 dev=16:07 mode=0100555 ouid=0
ogid=0 rdev=00:00 obj=system_u:object_r:clamassassin_exec_t:s0
type=AVC msg=audit(1151352842.204:3444): avc: denied { execute } for pid=8967
comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=AVC msg=audit(1151352842.204:3444): avc: denied { execute_no_trans } for pid=8967
comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=AVC msg=audit(1151352842.204:3444): avc: denied { read } for pid=8967
comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=AVC msg=audit(1151352842.204:3444): avc: denied { execute } for pid=8967
comm="clamassassin" name="ld-2.4.so" dev=hdc7 ino=754491
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:ld_so_t:s0
tclass=file
type=SYSCALL msg=audit(1151352842.204:3444): arch=40000003 syscall=11 success=yes exit=0
a0=9f512c0 a1=9f51500 a2=9f54dd0 a3=9f51228 items=2 pid=8967 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="mktemp" exe="/bin/mktemp"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352842.204:3444): path="/bin/mktemp"
type=AVC_PATH msg=audit(1151352842.204:3444): path="/bin/mktemp"
type=CWD msg=audit(1151352842.204:3444): cwd="/home/marcs"
type=PATH msg=audit(1151352842.204:3444): item=0 name="/bin/mktemp"
inode=1966111 dev=16:07 mode=0100555 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:bin_t:s0
type=PATH msg=audit(1151352842.204:3444): 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
type=AVC msg=audit(1151352842.204:3445): avc: denied { read } for pid=8967
comm="mktemp" name="urandom" dev=tmpfs ino=2006
scontext=system_u:system_r:clamassassin_t:s0
tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1151352842.204:3445): arch=40000003 syscall=5 success=yes exit=3
a0=80494d8 a1=0 a2=48920120 a3=9624008 items=1 pid=8967 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="mktemp"
exe="/bin/mktemp" subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151352842.204:3445): cwd="/home/marcs"
type=PATH msg=audit(1151352842.204:3445): item=0 name="/dev/urandom" inode=2006
dev=00:0f mode=020444 ouid=0 ogid=0 rdev=01:09 obj=system_u:object_r:urandom_device_t:s0
type=AVC msg=audit(1151352842.204:3446): avc: denied { getattr } for pid=8967
comm="mktemp" name="[261681]" dev=pipefs ino=261681
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:clamassassin_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151352842.204:3446): arch=40000003 syscall=197 success=yes exit=0
a0=1 a1=bfabe600 a2=4891eff4 a3=1 items=0 pid=8967 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="mktemp"
exe="/bin/mktemp" subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352842.204:3446): path="pipe:[261681]"
type=AVC msg=audit(1151352842.208:3447): avc: denied { write } for pid=8967
comm="mktemp" name="[261681]" dev=pipefs ino=261681
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:clamassassin_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151352842.208:3447): arch=40000003 syscall=4 success=yes exit=32
a0=1 a1=b7f26000 a2=20 a3=20 items=0 pid=8967 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="mktemp"
exe="/bin/mktemp" subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352842.208:3447): path="pipe:[261681]"
type=AVC msg=audit(1151352842.208:3448): avc: denied { read } for pid=8966
comm="clamassassin" name="[261681]" dev=pipefs ino=261681
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:clamassassin_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151352842.208:3448): arch=40000003 syscall=3 success=yes exit=32
a0=3 a1=bf93ac68 a2=80 a3=80 items=0 pid=8966 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamassassin"
exe="/bin/bash" subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151352842.208:3448): path="pipe:[261681]"
type=AVC msg=audit(1151352842.208:3449): avc: denied { use } for pid=8972
comm="clamscan" name="[261680]" dev=pipefs ino=261680
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:procmail_t:s0
tclass=fd
type=AVC msg=audit(1151352842.208:3449): avc: denied { read } for pid=8972
comm="clamscan" name="[261680]" dev=pipefs ino=261680
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:procmail_t:s0
tclass=fifo_file
type=AVC msg=audit(1151352842.208:3449): avc: denied { use } for pid=8972
comm="clamscan" name="[261675]" dev=pipefs ino=261675
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fd
type=AVC msg=audit(1151352842.208:3449): avc: denied { write } for pid=8972
comm="clamscan" name="[261675]" dev=pipefs ino=261675
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151352842.208:3449): arch=40000003 syscall=11 success=yes exit=0
a0=9f54c00 a1=9f54210 a2=9f54dd0 a3=9f54d90 items=2 pid=8972 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamscan" exe="/usr/bin/clamscan"
subj=system_u:system_r:clamscan_t:s0
type=AVC_PATH msg=audit(1151352842.208:3449): path="pipe:[261675]"
type=AVC_PATH msg=audit(1151352842.208:3449): path="pipe:[261675]"
type=AVC_PATH msg=audit(1151352842.208:3449): path="pipe:[261680]"
type=AVC_PATH msg=audit(1151352842.208:3449): path="pipe:[261680]"
type=CWD msg=audit(1151352842.208:3449): cwd="/home/marcs"
type=PATH msg=audit(1151352842.208:3449): item=0 name="/usr/bin/clamscan"
inode=3123838 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:clamscan_exec_t:s0
type=PATH msg=audit(1151352842.208:3449): 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
type=AVC msg=audit(1151352843.476:3450): avc: denied { read } for pid=8997
comm="clamassassin" name="ld-linux.so.2" dev=hdc7 ino=757669
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=lnk_file
type=SYSCALL msg=audit(1151352843.476:3450): arch=40000003 syscall=11 success=yes exit=0
a0=9f52e00 a1=9f55fc8 a2=9f54dd0 a3=9f55320 items=2 pid=8997 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="formail" exe="/usr/bin/formail"
subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151352843.476:3450): cwd="/home/marcs"
type=PATH msg=audit(1151352843.476:3450): item=0 name="/usr/bin/formail"
inode=3133721 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:bin_t:s0
type=PATH msg=audit(1151352843.476:3450): 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
type=AVC msg=audit(1151352847.417:3451): avc: denied { search } for pid=9002
comm="pyzor" name="mail" dev=hdc7 ino=1049593
scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir
type=SYSCALL msg=audit(1151352847.417:3451): arch=40000003 syscall=5 success=no exit=-2
a0=85577f8 a1=8000 a2=1b6 a3=85097c8 items=1 pid=9002 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=CWD msg=audit(1151352847.417:3451): cwd="/"
type=PATH msg=audit(1151352847.417:3451): item=0
name="/etc/mail/spamassassin/config" obj=system_u:object_r:lib_t:s0
type=AVC msg=audit(1151352847.421:3452): avc: denied { getattr } for pid=9002
comm="pyzor" name="spamassassin" dev=hdc7 ino=1049810
scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir
type=SYSCALL msg=audit(1151352847.421:3452): arch=40000003 syscall=195 success=yes exit=0
a0=8558a78 a1=bfce9748 a2=4891eff4 a3=84cf1b0 items=1 pid=9002 auid=4294967295 uid=500
gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="pyzor" exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=AVC_PATH msg=audit(1151352847.421:3452): path="/etc/mail/spamassassin"
type=CWD msg=audit(1151352847.421:3452): cwd="/"
type=PATH msg=audit(1151352847.421:3452): item=0 name="/etc/mail/spamassassin"
inode=1049810 dev=16:07 mode=040755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:etc_mail_t:s0
type=AVC msg=audit(1151352847.421:3453): avc: denied { getattr } for pid=9002
comm="pyzor" name="servers" dev=hdc7 ino=1051662
scontext=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file
type=SYSCALL msg=audit(1151352847.421:3453): arch=40000003 syscall=195 success=yes exit=0
a0=8558a78 a1=bfce9748 a2=4891eff4 a3=84cf1b0 items=1 pid=9002 auid=4294967295 uid=500
gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="pyzor" exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=AVC_PATH msg=audit(1151352847.421:3453):
path="/etc/mail/spamassassin/servers"
type=CWD msg=audit(1151352847.421:3453): cwd="/"
type=PATH msg=audit(1151352847.421:3453): item=0
name="/etc/mail/spamassassin/servers" inode=1051662 dev=16:07 mode=0100644
ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0
type=AVC msg=audit(1151352847.421:3454): avc: denied { read } for pid=9002
comm="pyzor" name="servers" dev=hdc7 ino=1051662
scontext=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file
type=SYSCALL msg=audit(1151352847.421:3454): arch=40000003 syscall=5 success=yes exit=3
a0=8558a78 a1=8000 a2=1b6 a3=85097c8 items=1 pid=9002 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=CWD msg=audit(1151352847.421:3454): cwd="/"
type=PATH msg=audit(1151352847.421:3454): item=0
name="/etc/mail/spamassassin/servers" inode=1051662 dev=16:07 mode=0100644
ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0
type=AVC msg=audit(1151352847.945:3455): avc: denied { create } for pid=9003
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151352847.945:3455): arch=40000003 syscall=102 success=yes exit=3
a0=1 a1=bfed9998 a2=4891eff4 a3=806a0ff items=0 pid=9003 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=SOCKETCALL msg=audit(1151352847.945:3455): nargs=3 a0=10 a1=3 a2=0
type=AVC msg=audit(1151352847.949:3456): avc: denied { bind } for pid=9003
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151352847.949:3456): arch=40000003 syscall=102 success=yes exit=0
a0=2 a1=bfed9998 a2=4891eff4 a3=3 items=0 pid=9003 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(1151352847.949:3456): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151352847.949:3456): nargs=3 a0=3 a1=bfed99a4 a2=c
type=AVC msg=audit(1151352847.949:3457): avc: denied { getattr } for pid=9003
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151352847.949:3457): arch=40000003 syscall=102 success=yes exit=0
a0=6 a1=bfed9998 a2=4891eff4 a3=3 items=0 pid=9003 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(1151352847.949:3457): saddr=100000002B23000000000000
type=SOCKETCALL msg=audit(1151352847.949:3457): nargs=3 a0=3 a1=bfed99a4 a2=bfed99b0
type=AVC msg=audit(1151352847.949:3458): avc: denied { write } for pid=9003
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=AVC msg=audit(1151352847.949:3458): avc: denied { nlmsg_read } for pid=9003
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151352847.949:3458): arch=40000003 syscall=102 success=yes exit=20
a0=b a1=bfed88e4 a2=4891eff4 a3=ffffffcc items=0 pid=9003 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(1151352847.949:3458): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151352847.949:3458): nargs=6 a0=3 a1=bfed995c a2=14 a3=0
a4=bfed9970 a5=c
type=AVC msg=audit(1151352847.949:3459): avc: denied { read } for pid=9003
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151352847.949:3459): arch=40000003 syscall=102 success=yes
exit=128 a0=11 a1=bfed88e4 a2=4891eff4 a3=ffffffcc items=0 pid=9003 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(1151352847.949:3459): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151352847.949:3459): nargs=3 a0=3 a1=bfed9940 a2=0
type=AVC msg=audit(1151352847.953:3460): avc: denied { node_bind } for pid=9003
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(1151352847.953:3460): arch=40000003 syscall=102 success=yes exit=0
a0=2 a1=bfed99d0 a2=4891eff4 a3=806a0ff items=0 pid=9003 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(1151352847.953:3460): saddr=02000000000000000000000000000000
type=SOCKETCALL msg=audit(1151352847.953:3460): nargs=3 a0=4 a1=bfed9a74 a2=10
type=AVC msg=audit(1151353003.231:3476): avc: denied { search } for pid=9317
comm="pyzor" name="mail" dev=hdc7 ino=1049593
scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir
type=SYSCALL msg=audit(1151353003.231:3476): arch=40000003 syscall=5 success=no exit=-2
a0=8cc27f8 a1=8000 a2=1b6 a3=8c747c8 items=1 pid=9317 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=CWD msg=audit(1151353003.231:3476): cwd="/"
type=PATH msg=audit(1151353003.231:3476): item=0
name="/etc/mail/spamassassin/config" obj=system_u:object_r:lib_t:s0
type=AVC msg=audit(1151353003.231:3477): avc: denied { getattr } for pid=9317
comm="pyzor" name="spamassassin" dev=hdc7 ino=1049810
scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir
type=SYSCALL msg=audit(1151353003.231:3477): arch=40000003 syscall=195 success=yes exit=0
a0=8cc3a78 a1=bf83d298 a2=4891eff4 a3=8c3a1b0 items=1 pid=9317 auid=4294967295 uid=500
gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="pyzor" exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=AVC_PATH msg=audit(1151353003.231:3477): path="/etc/mail/spamassassin"
type=CWD msg=audit(1151353003.231:3477): cwd="/"
type=PATH msg=audit(1151353003.231:3477): item=0 name="/etc/mail/spamassassin"
inode=1049810 dev=16:07 mode=040755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:etc_mail_t:s0
type=AVC msg=audit(1151353003.231:3478): avc: denied { getattr } for pid=9317
comm="pyzor" name="servers" dev=hdc7 ino=1051662
scontext=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file
type=SYSCALL msg=audit(1151353003.231:3478): arch=40000003 syscall=195 success=yes exit=0
a0=8cc3a78 a1=bf83d298 a2=4891eff4 a3=8c3a1b0 items=1 pid=9317 auid=4294967295 uid=500
gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="pyzor" exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=AVC_PATH msg=audit(1151353003.231:3478):
path="/etc/mail/spamassassin/servers"
type=CWD msg=audit(1151353003.231:3478): cwd="/"
type=PATH msg=audit(1151353003.231:3478): item=0
name="/etc/mail/spamassassin/servers" inode=1051662 dev=16:07 mode=0100644
ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0
type=AVC msg=audit(1151353003.231:3479): avc: denied { read } for pid=9317
comm="pyzor" name="servers" dev=hdc7 ino=1051662
scontext=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file
type=SYSCALL msg=audit(1151353003.231:3479): arch=40000003 syscall=5 success=yes exit=3
a0=8cc3a78 a1=8000 a2=1b6 a3=8c747c8 items=1 pid=9317 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=CWD msg=audit(1151353003.231:3479): cwd="/"
type=PATH msg=audit(1151353003.231:3479): item=0
name="/etc/mail/spamassassin/servers" inode=1051662 dev=16:07 mode=0100644
ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0
type=AVC msg=audit(1151353008.163:3480): avc: denied { node_bind } for pid=9319
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(1151353008.163:3480): arch=40000003 syscall=102 success=yes exit=0
a0=2 a1=bfa51570 a2=4891eff4 a3=37 items=0 pid=9319 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(1151353008.163:3480): saddr=02000000000000000000000000000000
type=SOCKETCALL msg=audit(1151353008.163:3480): nargs=3 a0=4 a1=bfa51614 a2=10
If the above approach makes sense, then I think that this could become a
defacto install approach when running under SELinux, which is not a
general consideration for the more general installation instructions for
these various filtering apps.
This approach, I think, also has the attraction of not differentiating
between a single user install and a system-wide install, as I had
initially considered above.
Regards,
Marc
3:32 p.m.
New subject: postfix, procmail and SELinux - No Go
I won't comment on the sheer ugliness of having hidden dirs in /etc, but
I can only approve the general direction and it'd be great if all those
changes were merged in the various FC and FE packages affected.
Regards,
--
Nicolas Mailhot
6:05 p.m.
New subject: postfix, procmail and SELinux - No Go
On Mon, 2006-06-26 at 15:22 -0500, Marc Schwartz (via MN) wrote:
Not sure about why /.razor and /.pyzor get created. The files in
them
are stamped with the same date/time as the cron jobs, however do not get
updated when I run the same update programs from the CLI as with root's
below. Something with ENV variables or UID I suspect, but not sure.
Probably, yes.
The root dirs (/root/.pyzor and /root/.razor, as well as the razor
log
file in /root) seem to get created during the cron jobs and I could
replicate this from the CLI.
However, see more below.
> > It occurs to me that one potential confounding variable here is that I
> > am running these processes as a local user on a single user system,
> > rather than a system-wide approach as one might do with a central server
> > processing incoming e-mail for multiple user accounts. That includes my
> > use of ~/.procmailrc as the primary means to process both virus (via
> > clamassassin/clamav) and spam (via SA + these additional tools).
> >
> > Presumably a SysAdmin on a multi-user system would take a different
> > approach and perhaps would use other means to integrate the processing
> > of viri and spam (such as Amavis as Nicolas has mentioned). This would
> > afford other approaches to the default configuration of these other tools.
>
> The spamassassin wiki has a page on this:
>
> http://wiki.apache.org/spamassassin/UsingPyzor
Thanks for this. In addition, I read through:
http://wiki.apache.org/spamassassin/RazorSiteWide
http://wiki.apache.org/spamassassin/UsingRazor
http://wiki.apache.org/spamassassin/InstallingDCC
http://wiki.apache.org/spamassassin/UsingDcc
The result of which is the following:
1. I made the following adds in /etc/mail/spamassassin/local.cf:
pyzor_options --homedir /etc/mail/spamassassin
razor_config /etc/mail/spamassassin/.razor/razor-agent.conf
2. I created /etc/mail/spamassassin/.razor/razor-agent.conf, which
contains:
razorhome = /etc/mail/spamassassin/.razor/
I share Nicolas' feelings about having hidden directories in /etc; this
could be mitigated perhaps by having something like the ".pyzor"
directory being replaced by a symlink to a "pyzor" directory.
3. I modified the /etc/crontab commands that execute the pyzor and
razor
updates to:
# Run pyzor update at 1:10 am
10 01 * * * root /usr/bin/pyzor --homedir /etc/mail/spamassassin discover > /dev/null
# Run razor update at 1:20 am
20 01 * * * root /usr/bin/razor-admin -home=/etc/mail/spamassassin/.razor -discover >
/dev/null
The above now force the use of the system-wide SA settings in 1 and 2
above.
Good.
Note also that there is /etc/sysconfig/spamassassin, which contains:
SPAMDOPTIONS="-d -c -m2 -H"
I only modified the '-m2' option to reduce the number of concurrent
sessions from 5 (-m5) to 2. The '-H' options enables the specification
of a different HOME directory, which then enables the use of the above
config files for razor and pyzor when spamc/d are called. The other
options are FC installed defaults.
The result of all of this is that the pyzor and razor updates are now
limited to the system-wide file(s) in:
# For pyzor, the single file
/etc/mail/spamassassin/servers
# For razor, the dir tree
/etc/mail/spamassassin/.razor/*
Thus, no more user specific files are created. Yeah! :-)
Yeah!
Note also, that I _did not_ create new user groups to run these apps,
as
is suggested on some of the above pages. The current configuration seems
to solve the problem without those additional steps.
OK.
> > The dcc update process would need to stay in /etc/crontab
since it
> > downloads, compiles and installs the system-wide dcc client.
>
> Compiles as root? Ugh!
Yep. If there are any options on the DCC install page that I noted in
my other reply that make sense here, let me know. I am willing to try
alternatives.
Maybe later...
Of course, let me know on the dccproc context change and what you
might
want to do about that.
Doing restorecon in the cron job will do for now. We might come back to
this later to try to get it created with the correct context.
> > Another option, perhaps, would be for the FE razor and
pyzor maintainers
> > to adjust the respective app defaults for FE with an eye towards SELinux
> > policy issues in future updates. In that way, perhaps the default
> > locations could be in /etc or /var as Nicolas notes above. That might
> > provide for a means to handle both single user and multi user
> > configurations, though the impact on other tools would need to be
> > considered as may be appropriate.
>
> If we can figure how how to make them work sanely, I'm confident that
> the maintainers would be open to suggestions (preferably with patches).
Well, hopefully we are on the right track with the above.
Yes. I trust you're making notes :-)
OK...so now with all of that going on, here are the latest
avc's:
# semodule -l
amavis 1.0.4
clamav 1.0.1
dcc 1.0.0
myclamav 0.1.1
mydcc 0.1.6
mypostfix 0.1.0
mypyzor 0.2.1
myspamassassin 0.1.1
procmail 0.5.4
pyzor 1.0.1
razor 1.0.0
type=AVC msg=audit(1151351642.927:3274): avc: denied { use } for pid=26956
comm="clamassassin" name="[251491]" dev=pipefs ino=251491
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fd
type=AVC msg=audit(1151351642.927:3274): avc: denied { write } for pid=26956
comm="clamassassin" name="[251491]" dev=pipefs ino=251491
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151351642.927:3274): arch=40000003 syscall=11 success=yes exit=0
a0=9502d60 a1=9502008 a2=95058f0 a3=0 items=3 pid=26956 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.927:3274): path="pipe:[251491]"
type=AVC_PATH msg=audit(1151351642.927:3274): path="pipe:[251491]"
type=CWD msg=audit(1151351642.927:3274): cwd="/home/marcs"
type=PATH msg=audit(1151351642.927:3274): item=0
name="/usr/local/bin/clamassassin" inode=3115337 dev=16:07 mode=0100555 ouid=0
ogid=0 rdev=00:00 obj=system_u:object_r:clamassassin_exec_t:s0
type=PATH msg=audit(1151351642.927:3274): item=1 name=(null) inode=1966191 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:shell_exec_t:s0
type=PATH msg=audit(1151351642.927:3274): item=2 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
I'll come back to this.
type=AVC msg=audit(1151351642.927:3275): avc: denied { search } for
pid=26956 comm="clamassassin" name="etc" dev=hdc7 ino=1048577
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:etc_t:s0
tclass=dir
type=SYSCALL msg=audit(1151351642.927:3275): arch=40000003 syscall=33 success=no exit=-2
a0=47fcc4df a1=4 a2=47fcffd8 a3=47fd06b8 items=1 pid=26956 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151351642.927:3275): cwd="/home/marcs"
type=PATH msg=audit(1151351642.927:3275): item=0 name="/etc/ld.so.preload"
obj=system_u:object_r:clamassassin_exec_t:s0
type=AVC msg=audit(1151351642.931:3276): avc: denied { read } for pid=26956
comm="clamassassin" name="ld.so.cache" dev=hdc7 ino=1049124
scontext=system_u:system_r:clamassassin_t:s0 tcontext=user_u:object_r:ld_so_cache_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.931:3276): arch=40000003 syscall=5 success=yes exit=3
a0=47fcc6c7 a1=0 a2=0 a3=47fd0890 items=1 pid=26956 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151351642.931:3276): cwd="/home/marcs"
type=PATH msg=audit(1151351642.931:3276): item=0 name="/etc/ld.so.cache"
inode=1049124 dev=16:07 mode=0100644 ouid=0 ogid=0 rdev=00:00
obj=user_u:object_r:ld_so_cache_t:s0
type=AVC msg=audit(1151351642.931:3277): avc: denied { getattr } for pid=26956
comm="clamassassin" name="ld.so.cache" dev=hdc7 ino=1049124
scontext=system_u:system_r:clamassassin_t:s0 tcontext=user_u:object_r:ld_so_cache_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.931:3277): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bfee7a5c a2=47fcffd8 a3=ffffffff items=0 pid=26956 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.931:3277): path="/etc/ld.so.cache"
type=AVC msg=audit(1151351642.931:3278): avc: denied { search } for pid=26956
comm="clamassassin" name="lib" dev=hdc7 ino=753665
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=dir
type=AVC msg=audit(1151351642.931:3278): avc: denied { read } for pid=26956
comm="clamassassin" name="libtermcap.so.2" dev=hdc7 ino=753723
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=lnk_file
type=AVC msg=audit(1151351642.931:3278): avc: denied { read } for pid=26956
comm="clamassassin" name="libtermcap.so.2.0.8" dev=hdc7 ino=754516
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.931:3278): arch=40000003 syscall=5 success=yes exit=3
a0=b7f95e11 a1=0 a2=1f3a0 a3=8 items=1 pid=26956 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamassassin"
exe="/bin/bash" subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151351642.931:3278): cwd="/home/marcs"
type=PATH msg=audit(1151351642.931:3278): item=0 name="/lib/libtermcap.so.2"
inode=754516 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:lib_t:s0
type=AVC msg=audit(1151351642.931:3279): avc: denied { getattr } for pid=26956
comm="clamassassin" name="libtermcap.so.2.0.8" dev=hdc7 ino=754516
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.931:3279): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bfee7ae0 a2=47fcffd8 a3=3 items=0 pid=26956 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.931:3279): path="/lib/libtermcap.so.2.0.8"
type=AVC msg=audit(1151351642.931:3280): avc: denied { execute } for pid=26956
comm="clamassassin" name="libtermcap.so.2.0.8" dev=hdc7 ino=754516
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.931:3280): arch=40000003 syscall=192 success=yes
exit=1208868864 a0=480de000 a1=3a88 a2=5 a3=802 items=0 pid=26956 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.931:3280): path="/lib/libtermcap.so.2.0.8"
type=AVC msg=audit(1151351642.931:3281): avc: denied { read } for pid=26956
comm="clamassassin" name="ld-2.4.so" dev=hdc7 ino=754491
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:ld_so_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.931:3281): arch=40000003 syscall=125 success=yes exit=0
a0=47fcf000 a1=1000 a2=1 a3=47fd0300 items=0 pid=26956 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.931:3281): path="/lib/ld-2.4.so"
That's all about using shared libraries. Fixed.
type=AVC msg=audit(1151351642.931:3282): avc: denied { search } for
pid=26956 comm="clamassassin" name="/" dev=proc ino=1
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=dir
type=AVC msg=audit(1151351642.931:3282): avc: denied { read } for pid=26956
comm="clamassassin" name="meminfo" dev=proc ino=-268435454
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.931:3282): arch=40000003 syscall=5 success=yes exit=3
a0=489093ef a1=0 a2=1b6 a3=9555240 items=1 pid=26956 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151351642.931:3282): cwd="/home/marcs"
type=PATH msg=audit(1151351642.931:3282): item=0 name="/proc/meminfo"
inode=4026531842 dev=00:03 mode=0100444 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:proc_t:s0
type=AVC msg=audit(1151351642.931:3283): avc: denied { getattr } for pid=26956
comm="clamassassin" name="meminfo" dev=proc ino=-268435454
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.931:3283): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bfee6038 a2=4891eff4 a3=3 items=0 pid=26956 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.931:3283): path="/proc/meminfo"
We'll try dontaudit-ing this as it may be generic script startup stuff
that's not needed.
type=AVC msg=audit(1151351642.935:3284): avc: denied { search } for
pid=26956 comm="clamassassin" name="usr" dev=hdc7 ino=3112961
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:usr_t:s0
tclass=dir
type=AVC msg=audit(1151351642.935:3284): avc: denied { search } for pid=26956
comm="clamassassin" name="bin" dev=hdc7 ino=3112982
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=dir
type=SYSCALL msg=audit(1151351642.935:3284): arch=40000003 syscall=5 success=yes exit=3
a0=9557018 a1=8000 a2=0 a3=8000 items=1 pid=26956 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamassassin"
exe="/bin/bash" subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151351642.935:3284): cwd="/home/marcs"
type=PATH msg=audit(1151351642.935:3284): item=0
name="/usr/local/bin/clamassassin" inode=3115337 dev=16:07 mode=0100555 ouid=0
ogid=0 rdev=00:00 obj=system_u:object_r:clamassassin_exec_t:s0
type=AVC msg=audit(1151351642.943:3285): avc: denied { execute } for pid=26957
comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=AVC msg=audit(1151351642.943:3285): avc: denied { execute_no_trans } for
pid=26957 comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=AVC msg=audit(1151351642.943:3285): avc: denied { read } for pid=26957
comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:bin_t:s0
tclass=file
type=AVC msg=audit(1151351642.943:3285): avc: denied { execute } for pid=26957
comm="clamassassin" name="ld-2.4.so" dev=hdc7 ino=754491
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:object_r:ld_so_t:s0
tclass=file
type=SYSCALL msg=audit(1151351642.943:3285): arch=40000003 syscall=11 success=yes exit=0
a0=95572c0 a1=9557500 a2=955add0 a3=9557228 items=2 pid=26957 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="mktemp" exe="/bin/mktemp"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.943:3285): path="/bin/mktemp"
type=AVC_PATH msg=audit(1151351642.943:3285): path="/bin/mktemp"
type=CWD msg=audit(1151351642.943:3285): cwd="/home/marcs"
type=PATH msg=audit(1151351642.943:3285): item=0 name="/bin/mktemp"
inode=1966111 dev=16:07 mode=0100555 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:bin_t:s0
type=PATH msg=audit(1151351642.943:3285): 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
Trying to run /bin/mktemp to make a temp file. Fixed.
type=AVC msg=audit(1151351642.943:3286): avc: denied { read } for
pid=26957 comm="mktemp" name="urandom" dev=tmpfs ino=2006
scontext=system_u:system_r:clamassassin_t:s0
tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1151351642.943:3286): arch=40000003 syscall=5 success=yes exit=3
a0=80494d8 a1=0 a2=48920120 a3=85af008 items=1 pid=26957 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="mktemp"
exe="/bin/mktemp" subj=system_u:system_r:clamassassin_t:s0
type=CWD msg=audit(1151351642.943:3286): cwd="/home/marcs"
type=PATH msg=audit(1151351642.943:3286): item=0 name="/dev/urandom" inode=2006
dev=00:0f mode=020444 ouid=0 ogid=0 rdev=01:09 obj=system_u:object_r:urandom_device_t:s0
mktemp using a random number. Fixed.
type=AVC msg=audit(1151351642.947:3287): avc: denied { getattr }
for pid=26957 comm="mktemp" name="[251497]" dev=pipefs ino=251497
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:clamassassin_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151351642.947:3287): arch=40000003 syscall=197 success=yes exit=0
a0=1 a1=bf8893d0 a2=4891eff4 a3=1 items=0 pid=26957 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="mktemp"
exe="/bin/mktemp" subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.947:3287): path="pipe:[251497]"
type=AVC msg=audit(1151351642.947:3288): avc: denied { write } for pid=26957
comm="mktemp" name="[251497]" dev=pipefs ino=251497
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:clamassassin_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151351642.947:3288): arch=40000003 syscall=4 success=yes exit=32
a0=1 a1=b7f9b000 a2=20 a3=20 items=0 pid=26957 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="mktemp"
exe="/bin/mktemp" subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.947:3288): path="pipe:[251497]"
type=AVC msg=audit(1151351642.947:3289): avc: denied { read } for pid=26956
comm="clamassassin" name="[251497]" dev=pipefs ino=251497
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:clamassassin_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151351642.947:3289): arch=40000003 syscall=3 success=yes exit=32
a0=3 a1=bfee7a18 a2=80 a3=80 items=0 pid=26956 auid=4294967295 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="clamassassin"
exe="/bin/bash" subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151351642.947:3289): path="pipe:[251497]"
type=AVC msg=audit(1151351642.955:3290): avc: denied { use } for pid=26960
comm="clamscan" name="[251496]" dev=pipefs ino=251496
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:procmail_t:s0
tclass=fd
type=AVC msg=audit(1151351642.955:3290): avc: denied { read } for pid=26960
comm="clamscan" name="[251496]" dev=pipefs ino=251496
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:procmail_t:s0
tclass=fifo_file
type=AVC msg=audit(1151351642.955:3290): avc: denied { use } for pid=26960
comm="clamscan" name="[251491]" dev=pipefs ino=251491
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fd
type=AVC msg=audit(1151351642.955:3290): avc: denied { write } for pid=26960
comm="clamscan" name="[251491]" dev=pipefs ino=251491
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151351642.955:3290): arch=40000003 syscall=11 success=yes exit=0
a0=955ac00 a1=955a210 a2=955add0 a3=955ad90 items=2 pid=26960 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamscan" exe="/usr/bin/clamscan"
subj=system_u:system_r:clamscan_t:s0
type=AVC_PATH msg=audit(1151351642.955:3290): path="pipe:[251491]"
type=AVC_PATH msg=audit(1151351642.955:3290): path="pipe:[251491]"
type=AVC_PATH msg=audit(1151351642.955:3290): path="pipe:[251496]"
type=AVC_PATH msg=audit(1151351642.955:3290): path="pipe:[251496]"
type=CWD msg=audit(1151351642.955:3290): cwd="/home/marcs"
type=PATH msg=audit(1151351642.955:3290): item=0 name="/usr/bin/clamscan"
inode=3123838 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:clamscan_exec_t:s0
type=PATH msg=audit(1151351642.955:3290): 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
I'm not sure about this. audit2allow -R tells me that this may fix it:
#allow clamscan_t postfix_local_t:fd use;
#allow clamscan_t postfix_local_t:fifo_file write;
#allow clamscan_t procmail_t:fifo_file read;
clamav_domtrans_clamscan(clamscan_t)
type=AVC msg=audit(1151351646.796:3291): avc: denied { search } for
pid=26970 comm="pyzor" name="mail" dev=hdc7 ino=1049593
scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir
type=SYSCALL msg=audit(1151351646.796:3291): arch=40000003 syscall=5 success=no exit=-2
a0=99817f8 a1=8000 a2=1b6 a3=99337c8 items=1 pid=26970 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=CWD msg=audit(1151351646.796:3291): cwd="/"
type=PATH msg=audit(1151351646.796:3291): item=0
name="/etc/mail/spamassassin/config" obj=system_u:object_r:lib_t:s0
type=AVC msg=audit(1151351646.796:3292): avc: denied { getattr } for pid=26970
comm="pyzor" name="spamassassin" dev=hdc7 ino=1049810
scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:etc_mail_t:s0 tclass=dir
type=SYSCALL msg=audit(1151351646.796:3292): arch=40000003 syscall=195 success=yes exit=0
a0=9982a78 a1=bfae9548 a2=4891eff4 a3=98f91b0 items=1 pid=26970 auid=4294967295 uid=500
gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="pyzor" exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=AVC_PATH msg=audit(1151351646.796:3292): path="/etc/mail/spamassassin"
type=CWD msg=audit(1151351646.796:3292): cwd="/"
type=PATH msg=audit(1151351646.796:3292): item=0 name="/etc/mail/spamassassin"
inode=1049810 dev=16:07 mode=040755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:etc_mail_t:s0
type=AVC msg=audit(1151351646.796:3293): avc: denied { getattr } for pid=26970
comm="pyzor" name="servers" dev=hdc7 ino=1051662
scontext=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file
type=SYSCALL msg=audit(1151351646.796:3293): arch=40000003 syscall=195 success=yes exit=0
a0=9982a78 a1=bfae9548 a2=4891eff4 a3=98f91b0 items=1 pid=26970 auid=4294967295 uid=500
gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="pyzor" exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=AVC_PATH msg=audit(1151351646.796:3293):
path="/etc/mail/spamassassin/servers"
type=CWD msg=audit(1151351646.796:3293): cwd="/"
type=PATH msg=audit(1151351646.796:3293): item=0
name="/etc/mail/spamassassin/servers" inode=1051662 dev=16:07 mode=0100644
ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0
type=AVC msg=audit(1151351646.796:3294): avc: denied { read } for pid=26970
comm="pyzor" name="servers" dev=hdc7 ino=1051662
scontext=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file
type=SYSCALL msg=audit(1151351646.796:3294): arch=40000003 syscall=5 success=yes exit=3
a0=9982a78 a1=8000 a2=1b6 a3=99337c8 items=1 pid=26970 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=CWD msg=audit(1151351646.796:3294): cwd="/"
type=PATH msg=audit(1151351646.796:3294): item=0
name="/etc/mail/spamassassin/servers" inode=1051662 dev=16:07 mode=0100644
ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0
pyzor reading new site-wide config.
type=AVC msg=audit(1151351651.760:3295): avc: denied { create } for
pid=26973 comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151351651.760:3295): arch=40000003 syscall=102 success=yes exit=3
a0=1 a1=bfaecda8 a2=4891eff4 a3=806a0ff items=0 pid=26973 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=SOCKETCALL msg=audit(1151351651.760:3295): nargs=3 a0=10 a1=3 a2=0
type=AVC msg=audit(1151351651.760:3296): avc: denied { bind } for pid=26973
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151351651.760:3296): arch=40000003 syscall=102 success=yes exit=0
a0=2 a1=bfaecda8 a2=4891eff4 a3=3 items=0 pid=26973 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(1151351651.760:3296): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151351651.760:3296): nargs=3 a0=3 a1=bfaecdb4 a2=c
type=AVC msg=audit(1151351651.760:3297): avc: denied { getattr } for pid=26973
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151351651.760:3297): arch=40000003 syscall=102 success=yes exit=0
a0=6 a1=bfaecda8 a2=4891eff4 a3=3 items=0 pid=26973 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(1151351651.760:3297): saddr=100000005D69000000000000
type=SOCKETCALL msg=audit(1151351651.760:3297): nargs=3 a0=3 a1=bfaecdb4 a2=bfaecdc0
type=AVC msg=audit(1151351651.760:3298): avc: denied { write } for pid=26973
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=AVC msg=audit(1151351651.760:3298): avc: denied { nlmsg_read } for pid=26973
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151351651.760:3298): arch=40000003 syscall=102 success=yes
exit=20 a0=b a1=bfaebcf4 a2=4891eff4 a3=ffffffcc items=0 pid=26973 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(1151351651.760:3298): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151351651.760:3298): nargs=6 a0=3 a1=bfaecd6c a2=14 a3=0
a4=bfaecd80 a5=c
type=AVC msg=audit(1151351651.760:3299): avc: denied { read } for pid=26973
comm="dccproc" scontext=system_u:system_r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151351651.760:3299): arch=40000003 syscall=102 success=yes
exit=128 a0=11 a1=bfaebcf4 a2=4891eff4 a3=ffffffcc items=0 pid=26973 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(1151351651.760:3299): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151351651.760:3299): nargs=3 a0=3 a1=bfaecd50 a2=0
type=AVC msg=audit(1151351651.764:3300): avc: denied { node_bind } for pid=26973
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(1151351651.764:3300): arch=40000003 syscall=102 success=yes exit=0
a0=2 a1=bfaecde0 a2=4891eff4 a3=806a0ff items=0 pid=26973 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(1151351651.764:3300): saddr=02000000000000000000000000000000
type=SOCKETCALL msg=audit(1151351651.764:3300): nargs=3 a0=4 a1=bfaece84 a2=10
Lots of network stuff. Added.
(snip)
The rest looked like repeats to me.
If the above approach makes sense, then I think that this could
become a
defacto install approach when running under SELinux, which is not a
general consideration for the more general installation instructions for
these various filtering apps.
This approach, I think, also has the attraction of not differentiating
between a single user install and a system-wide install, as I had
initially considered above.
Should be worth a page on the Fedora wiki eventually.
Updated policy:
::::::::::::::
myclamav.te
::::::::::::::
policy_module(myclamav, 0.1.2)
require {
type clamd_t;
type clamscan_t;
type clamscan_tmp_t;
type freshclam_t;
type postfix_local_t;
type procmail_t;
};
type clamassassin_t;
domain_type(clamassassin_t)
type clamassassin_exec_t;
domain_entry_file(clamassassin_t,clamassassin_exec_t)
# ========================================
# clamassassin local policy
# ========================================
# Transition from unconfined for command-line usage
ifdef(`targeted_policy',`
clamav_domtrans_clamassassin(unconfined_t)
')
# clamassassin uses pipes
allow clamassassin_t self:fifo_file rw_file_perms;
# When clamassassin writes temp files, they're for clamscan to process
# so make them clamscan_tmp_t
allow clamassassin_t clamscan_tmp_t:dir create_dir_perms;
allow clamassassin_t clamscan_tmp_t:file create_file_perms;
files_tmp_filetrans(clamassassin_t, clamscan_tmp_t, { file dir })
# Use shared libraries
libs_use_ld_so(clamassassin_t)
libs_use_shared_libs(clamassassin_t)
# Run binaries such as /bin/mktemp
corecmd_exec_bin(clamassassin_t)
files_search_usr(clamassassin_t)
# Allow clamassassin (mktemp) to read /dev/urandom
dev_read_urand(clamassassin_t)
# clamassassin probably doesn't need to be able to read /proc/meminfo
kernel_dontaudit_list_proc(clamassassin_t)
kernel_dontaudit_read_system_state(clamassassin_t)
# clamassassin needs to be able to call clamscan
clamav_domtrans_clamscan(clamassassin_t)
# ========================================
# clamd local policy
# ========================================
kernel_read_kernel_sysctls(clamd_t)
# ========================================
# clamscan local policy
# ========================================
# ---------------------------------------------------
# These are suggestions from audit2allow -R
# ---------------------------------------------------
#allow clamscan_t postfix_local_t:fd use;
#allow clamscan_t postfix_local_t:fifo_file write;
#allow clamscan_t procmail_t:fifo_file read;
clamav_domtrans_clamscan(clamscan_t)
#allow clamscan_t procmail_t:fd use;
procmail_domtrans(clamscan_t)
# ========================================
# freshclam local policy
# ========================================
# Allow freshclam to send syslog messages
logging_send_syslog_msg(freshclam_t)
# Allow freshclam to read generic kernel sysctls
kernel_read_kernel_sysctls(freshclam_t)
::::::::::::::
mydcc.te
::::::::::::::
policy_module(mydcc, 0.1.7)
# ==================================================
# Declarations
# ==================================================
require {
type dcc_client_t;
}
# ==================================================
# DCC client local policy
# ==================================================
allow dcc_client_t self:netlink_route_socket r_netlink_socket_perms;
corenet_udp_bind_inaddr_any_node(dcc_client_t)
spamassassin_read_spamd_tmp_files(dcc_client_t)
::::::::::::::
mypyzor.te
::::::::::::::
policy_module(mypyzor, 0.2.2)
require {
type etc_mail_t;
type pyzor_t;
type pyzor_exec_t;
type pyzor_port_t;
type spamd_t;
};
# temp files
type pyzor_tmp_t;
files_tmp_file(pyzor_tmp_t)
# Allow pyzor to create and use temp files and dirs
allow pyzor_t pyzor_tmp_t:dir create_dir_perms;
allow pyzor_t pyzor_tmp_t:file create_file_perms;
files_type(pyzor_tmp_t)
files_tmp_filetrans(pyzor_t, pyzor_tmp_t, { file dir })
# Allow pyzor to read config (and any other file...)
# from user home directories
userdom_read_unpriv_users_home_content_files(pyzor_t)
# Allow pyzor to read /dev/urandom
dev_read_urand(pyzor_t)
# Allow pyzor to send and receive pyzor messages!
allow pyzor_t pyzor_port_t:udp_socket send_msg;
allow pyzor_t pyzor_port_t:udp_socket recv_msg;
# Allow spamd to signal pyzor (kill/hup ?)
allow spamd_t pyzor_t:process signal;
# This doesn't seem to break anything
dontaudit spamd_t pyzor_exec_t:file getattr;
# Read sitewide config
allow pyzor_t etc_mail_t:dir { getattr search };
allow pyzor_t etc_mail_t:file { getattr read };
# Allow pyzor to ...?
corecmd_search_bin(pyzor_t)
kernel_read_kernel_sysctls(pyzor_t)
# It does a getattr on /usr/bin/time for reasons unknown...
dontaudit pyzor_t bin_t:dir getattr;
dontaudit pyzor_t bin_t:file getattr;
# Pyzor/python probably doesn't need to be able to read /proc/meminfo
kernel_dontaudit_list_proc(pyzor_t)
kernel_dontaudit_read_system_state(pyzor_t)
Paul.
11:11 p.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-06-27 at 00:05 +0100, Paul Howarth wrote:
On Mon, 2006-06-26 at 15:22 -0500, Marc Schwartz (via MN) wrote:
> Not sure about why /.razor and /.pyzor get created. The files in them
> are stamped with the same date/time as the cron jobs, however do not get
> updated when I run the same update programs from the CLI as with root's
> below. Something with ENV variables or UID I suspect, but not sure.
Probably, yes.
> The root dirs (/root/.pyzor and /root/.razor, as well as the razor log
> file in /root) seem to get created during the cron jobs and I could
> replicate this from the CLI.
>
> However, see more below.
<snip>
> >
> > The spamassassin wiki has a page on this:
> >
> > http://wiki.apache.org/spamassassin/UsingPyzor
>
> Thanks for this. In addition, I read through:
>
> http://wiki.apache.org/spamassassin/RazorSiteWide
> http://wiki.apache.org/spamassassin/UsingRazor
> http://wiki.apache.org/spamassassin/InstallingDCC
> http://wiki.apache.org/spamassassin/UsingDcc
>
> The result of which is the following:
>
> 1. I made the following adds in /etc/mail/spamassassin/local.cf:
>
> pyzor_options --homedir /etc/mail/spamassassin
> razor_config /etc/mail/spamassassin/.razor/razor-agent.conf
>
>
> 2. I created /etc/mail/spamassassin/.razor/razor-agent.conf, which
> contains:
>
> razorhome = /etc/mail/spamassassin/.razor/
I share Nicolas' feelings about having hidden directories in /etc; this
could be mitigated perhaps by having something like the ".pyzor"
directory being replaced by a symlink to a "pyzor" directory.
No disagreement with either of you here.
The key here I believe is that we demonstrated a proof of concept, in
that we can control the locations where these files get written and do
so in a system-wide fashion. Even if this ends up being unique to FC/FE
based installations due to SELinux requirements.
I have no vested interest in the specific locations and only used the
examples from the SA wiki as the basis for the initial attempt.
We can certainly come to some appropriate consensus as to where we want
them, whether higher in /etc or perhaps in /var.
If you guys provide some feedback, I can make the requisite changes.
> 3. I modified the /etc/crontab commands that execute the pyzor
and razor
> updates to:
>
> # Run pyzor update at 1:10 am
> 10 01 * * * root /usr/bin/pyzor --homedir /etc/mail/spamassassin discover >
/dev/null
>
> # Run razor update at 1:20 am
> 20 01 * * * root /usr/bin/razor-admin -home=/etc/mail/spamassassin/.razor -discover
> /dev/null
>
>
> The above now force the use of the system-wide SA settings in 1 and 2
> above.
Good.
Yes indeed.
> Note also that there is /etc/sysconfig/spamassassin, which
contains:
>
> SPAMDOPTIONS="-d -c -m2 -H"
>
> I only modified the '-m2' option to reduce the number of concurrent
> sessions from 5 (-m5) to 2. The '-H' options enables the specification
> of a different HOME directory, which then enables the use of the above
> config files for razor and pyzor when spamc/d are called. The other
> options are FC installed defaults.
>
>
> The result of all of this is that the pyzor and razor updates are now
> limited to the system-wide file(s) in:
>
> # For pyzor, the single file
> /etc/mail/spamassassin/servers
>
> # For razor, the dir tree
> /etc/mail/spamassassin/.razor/*
>
> Thus, no more user specific files are created. Yeah! :-)
Yeah!
:-)
> Note also, that I _did not_ create new user groups to run these
apps, as
> is suggested on some of the above pages. The current configuration seems
> to solve the problem without those additional steps.
OK.
> > > The dcc update process would need to stay in /etc/crontab since it
> > > downloads, compiles and installs the system-wide dcc client.
> >
> > Compiles as root? Ugh!
>
> Yep. If there are any options on the DCC install page that I noted in
> my other reply that make sense here, let me know. I am willing to try
> alternatives.
Maybe later...
OK.
> Of course, let me know on the dccproc context change and what
you might
> want to do about that.
Doing restorecon in the cron job will do for now. We might come back to
this later to try to get it created with the correct context.
OK. As noted in my other reply, the change to /etc/crontab has been
made.
> > > Another option, perhaps, would be for the FE razor and
pyzor maintainers
> > > to adjust the respective app defaults for FE with an eye towards SELinux
> > > policy issues in future updates. In that way, perhaps the default
> > > locations could be in /etc or /var as Nicolas notes above. That might
> > > provide for a means to handle both single user and multi user
> > > configurations, though the impact on other tools would need to be
> > > considered as may be appropriate.
> >
> > If we can figure how how to make them work sanely, I'm confident that
> > the maintainers would be open to suggestions (preferably with patches).
>
> Well, hopefully we are on the right track with the above.
Yes. I trust you're making notes :-)
Well, I have some of the key posts back and forth and of course the main
reference will be the list archive of this now, rather lengthy
thread... :-)
<snip of avc's and comments>
(snip)
The rest looked like repeats to me.
> If the above approach makes sense, then I think that this could become a
> defacto install approach when running under SELinux, which is not a
> general consideration for the more general installation instructions for
> these various filtering apps.
>
> This approach, I think, also has the attraction of not differentiating
> between a single user install and a system-wide install, as I had
> initially considered above.
Should be worth a page on the Fedora wiki eventually.
Yes indeed. 'lonely wolf' had requested this of me before I went to
Vienna and I'll need to get back to that once we stabilize things here.
Updated policy:
<snip>
# semodule -l
amavis 1.0.4
clamav 1.0.1
dcc 1.0.0
myclamav 0.1.2
mydcc 0.1.7
mypostfix 0.1.0
mypyzor 0.2.2
myspamassassin 0.1.1
procmail 0.5.4
pyzor 1.0.1
razor 1.0.0
New avc's:
type=AVC msg=audit(1151379242.395:1987): avc: denied { use } for pid=32340
comm="clamassassin" name="[125798]" dev=pipefs ino=125 798
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fd
type=AVC msg=audit(1151379242.395:1987): avc: denied { write } for pid=32340
comm="clamassassin" name="[125798]" dev=pipefs ino=1 25798
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151379242.395:1987): arch=40000003 syscall=11 success=yes exit=0
a0=98dfd60 a1=98df008 a2=98e2bc8 a3=0 items =3 pid=32340 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151379242.395:1987): path="pipe:[125798]"
type=AVC_PATH msg=audit(1151379242.395:1987): path="pipe:[125798]"
type=CWD msg=audit(1151379242.395:1987): cwd="/home/marcs"
type=PATH msg=audit(1151379242.395:1987): item=0
name="/usr/local/bin/clamassassin" inode=3115337 dev=16:07 mode=0100555 ouid=0
ogid =0 rdev=00:00 obj=system_u:object_r:clamassassin_exec_t:s0
type=PATH msg=audit(1151379242.395:1987): item=1 name=(null) inode=1966191 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=syste m_u:object_r:shell_exec_t:s0
type=PATH msg=audit(1151379242.395:1987): item=2 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
type=AVC msg=audit(1151379242.411:1988): avc: denied { read } for pid=32344
comm="clamscan" name="[125803]" dev=pipefs ino=125803
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:procmail_t:s0
tclass=fifo_file
type=AVC msg=audit(1151379242.411:1988): avc: denied { use } for pid=32344
comm="clamscan" name="[125798]" dev=pipefs ino=125798
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fd
type=AVC msg=audit(1151379242.411:1988): avc: denied { write } for pid=32344
comm="clamscan" name="[125798]" dev=pipefs ino=12579 8
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151379242.411:1988): arch=40000003 syscall=11 success=yes exit=0
a0=8477c00 a1=8477210 a2=8477dd0 a3=8477d90 items=2 pid=32344 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamscan " exe="/usr/bin/clamscan"
subj=system_u:system_r:clamscan_t:s0
type=AVC_PATH msg=audit(1151379242.411:1988): path="pipe:[125798]"
type=AVC_PATH msg=audit(1151379242.411:1988): path="pipe:[125798]"
type=AVC_PATH msg=audit(1151379242.411:1988): path="pipe:[125803]"
type=CWD msg=audit(1151379242.411:1988): cwd="/home/marcs"
type=PATH msg=audit(1151379242.411:1988): item=0 name="/usr/bin/clamscan"
inode=3123838 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00 :00
obj=system_u:object_r:clamscan_exec_t:s0
type=PATH msg=audit(1151379242.411:1988): 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
type=AVC msg=audit(1151379270.259:1989): avc: denied { search } for pid=32363
comm="dccproc" name="/" dev=proc ino=1 scontext=sys
tem_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=dir
type=AVC msg=audit(1151379270.259:1989): avc: denied { read } for pid=32363
comm="dccproc" name="meminfo" dev=proc ino=-268435454
scontext=system_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=file
type=SYSCALL msg=audit(1151379270.259:1989): arch=40000003 syscall=5 success=yes exit=5
a0=489093ef a1=0 a2=1b6 a3=9d26630 items=1 p id=32363 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/b in/dccproc" subj=system_u:system_r:dcc_client_t:s0
type=CWD msg=audit(1151379270.259:1989): cwd="/var/dcc"
type=PATH msg=audit(1151379270.259:1989): item=0 name="/proc/meminfo"
inode=4026531842 dev=00:03 mode=0100444 ouid=0 ogid=0 rdev=00: 00
obj=system_u:object_r:proc_t:s0
type=AVC msg=audit(1151379270.259:1990): avc: denied { getattr } for pid=32363
comm="dccproc" name="meminfo" dev=proc ino=-268435 454
scontext=system_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=file
type=SYSCALL msg=audit(1151379270.259:1990): arch=40000003 syscall=197 success=yes exit=0
a0=5 a1=bfb18dfc a2=4891eff4 a3=5 items=0 pid=32363 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=AVC_PATH msg=audit(1151379270.259:1990): path="/proc/meminfo"
type=AVC msg=audit(1151380802.089:2109): avc: denied { use } for pid=3200
comm="clamassassin" name="[133367]" dev=pipefs ino=1333 67
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fd
type=AVC msg=audit(1151380802.089:2109): avc: denied { write } for pid=3200
comm="clamassassin" name="[133367]" dev=pipefs ino=13 3367
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151380802.089:2109): arch=40000003 syscall=11 success=yes exit=0
a0=8c66d60 a1=8c66008 a2=8c69f20 a3=0 items =3 pid=3200 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" e xe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151380802.089:2109): path="pipe:[133367]"
type=AVC_PATH msg=audit(1151380802.089:2109): path="pipe:[133367]"
type=CWD msg=audit(1151380802.089:2109): cwd="/home/marcs"
type=PATH msg=audit(1151380802.089:2109): item=0
name="/usr/local/bin/clamassassin" inode=3115337 dev=16:07 mode=0100555 ouid=0
ogid =0 rdev=00:00 obj=system_u:object_r:clamassassin_exec_t:s0
type=PATH msg=audit(1151380802.089:2109): item=1 name=(null) inode=1966191 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=syste m_u:object_r:shell_exec_t:s0
type=PATH msg=audit(1151380802.089:2109): item=2 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
type=AVC msg=audit(1151380802.101:2110): avc: denied { read } for pid=3204
comm="clamscan" name="[133372]" dev=pipefs ino=133372
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:procmail_t:s0
tclass=fifo_file
type=AVC msg=audit(1151380802.101:2110): avc: denied { use } for pid=3204
comm="clamscan" name="[133367]" dev=pipefs ino=133367 s
context=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fd
type=AVC msg=audit(1151380802.101:2110): avc: denied { write } for pid=3204
comm="clamscan" name="[133367]" dev=pipefs ino=133367
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151380802.101:2110): arch=40000003 syscall=11 success=yes exit=0
a0=9d2bc00 a1=9d2b210 a2=9d2bdd0 a3=9d2bd90 items=2 pid=3204 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamscan" exe="/usr/bin/clamscan"
subj=system_u:system_r:clamscan_t:s0
type=AVC_PATH msg=audit(1151380802.101:2110): path="pipe:[133367]"
type=AVC_PATH msg=audit(1151380802.101:2110): path="pipe:[133367]"
type=AVC_PATH msg=audit(1151380802.101:2110): path="pipe:[133372]"
type=CWD msg=audit(1151380802.101:2110): cwd="/home/marcs"
type=PATH msg=audit(1151380802.101:2110): item=0 name="/usr/bin/clamscan"
inode=3123838 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00 :00
obj=system_u:object_r:clamscan_exec_t:s0
type=PATH msg=audit(1151380802.101:2110): 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
Thanks Paul.
Marc
11:20 a.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz wrote:
On Tue, 2006-06-27 at 00:05 +0100, Paul Howarth wrote:
> I share Nicolas' feelings about having hidden directories in /etc; this
> could be mitigated perhaps by having something like the ".pyzor"
> directory being replaced by a symlink to a "pyzor" directory.
No disagreement with either of you here.
The key here I believe is that we demonstrated a proof of concept, in
that we can control the locations where these files get written and do
so in a system-wide fashion. Even if this ends up being unique to FC/FE
based installations due to SELinux requirements.
I have no vested interest in the specific locations and only used the
examples from the SA wiki as the basis for the initial attempt.
We can certainly come to some appropriate consensus as to where we want
them, whether higher in /etc or perhaps in /var.
If you guys provide some feedback, I can make the requisite changes.
I think the main issue isn't really whether the directories live under
/var, /etc etc., but that they are "hidden" directories with names
starting with a dot. Can the tools be persuaded to use other, more
visible directory names?
> Updated policy:
<snip>
# semodule -l
amavis 1.0.4
clamav 1.0.1
dcc 1.0.0
myclamav 0.1.2
mydcc 0.1.7
mypostfix 0.1.0
mypyzor 0.2.2
myspamassassin 0.1.1
procmail 0.5.4
pyzor 1.0.1
razor 1.0.0
New avc's:
type=AVC msg=audit(1151379242.395:1987): avc: denied { use } for pid=32340
comm="clamassassin" name="[125798]" dev=pipefs ino=125 798
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fd
type=AVC msg=audit(1151379242.395:1987): avc: denied { write } for pid=32340
comm="clamassassin" name="[125798]" dev=pipefs ino=1 25798
scontext=system_u:system_r:clamassassin_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151379242.395:1987): arch=40000003 syscall=11 success=yes exit=0
a0=98dfd60 a1=98df008 a2=98e2bc8 a3=0 items =3 pid=32340 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamassassin" exe="/bin/bash"
subj=system_u:system_r:clamassassin_t:s0
type=AVC_PATH msg=audit(1151379242.395:1987): path="pipe:[125798]"
type=AVC_PATH msg=audit(1151379242.395:1987): path="pipe:[125798]"
type=CWD msg=audit(1151379242.395:1987): cwd="/home/marcs"
type=PATH msg=audit(1151379242.395:1987): item=0
name="/usr/local/bin/clamassassin" inode=3115337 dev=16:07 mode=0100555 ouid=0
ogid =0 rdev=00:00 obj=system_u:object_r:clamassassin_exec_t:s0
type=PATH msg=audit(1151379242.395:1987): item=1 name=(null) inode=1966191 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=syste m_u:object_r:shell_exec_t:s0
type=PATH msg=audit(1151379242.395:1987): item=2 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
I *think* this is clamassassin output being piped into postfix_local_t.
type=AVC msg=audit(1151379242.411:1988): avc: denied { read } for
pid=32344 comm="clamscan" name="[125803]" dev=pipefs ino=125803
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:procmail_t:s0
tclass=fifo_file
type=AVC msg=audit(1151379242.411:1988): avc: denied { use } for pid=32344
comm="clamscan" name="[125798]" dev=pipefs ino=125798
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fd
type=AVC msg=audit(1151379242.411:1988): avc: denied { write } for pid=32344
comm="clamscan" name="[125798]" dev=pipefs ino=12579 8
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0
tclass=fifo_file
type=SYSCALL msg=audit(1151379242.411:1988): arch=40000003 syscall=11 success=yes exit=0
a0=8477c00 a1=8477210 a2=8477dd0 a3=8477d90 items=2 pid=32344 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamscan " exe="/usr/bin/clamscan"
subj=system_u:system_r:clamscan_t:s0
type=AVC_PATH msg=audit(1151379242.411:1988): path="pipe:[125798]"
type=AVC_PATH msg=audit(1151379242.411:1988): path="pipe:[125798]"
type=AVC_PATH msg=audit(1151379242.411:1988): path="pipe:[125803]"
type=CWD msg=audit(1151379242.411:1988): cwd="/home/marcs"
type=PATH msg=audit(1151379242.411:1988): item=0 name="/usr/bin/clamscan"
inode=3123838 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00 :00
obj=system_u:object_r:clamscan_exec_t:s0
type=PATH msg=audit(1151379242.411:1988): 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
audit2allow -R suggested clamav_domtrans_clamscan(clamscan_t) for this.
I don't know exactly what's happening here, why audit2allow suggested
that solution, nor why that solution didn't work (as it was in
yesterday's version). Any ideas anyone?
I'll add the raw allow rules for now.
type=AVC msg=audit(1151379270.259:1989): avc: denied { search } for
pid=32363 comm="dccproc" name="/" dev=proc ino=1 scontext=sys
tem_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=dir
type=AVC msg=audit(1151379270.259:1989): avc: denied { read } for pid=32363
comm="dccproc" name="meminfo" dev=proc ino=-268435454
scontext=system_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=file
type=SYSCALL msg=audit(1151379270.259:1989): arch=40000003 syscall=5 success=yes exit=5
a0=489093ef a1=0 a2=1b6 a3=9d26630 items=1 p id=32363 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/b in/dccproc" subj=system_u:system_r:dcc_client_t:s0
type=CWD msg=audit(1151379270.259:1989): cwd="/var/dcc"
type=PATH msg=audit(1151379270.259:1989): item=0 name="/proc/meminfo"
inode=4026531842 dev=00:03 mode=0100444 ouid=0 ogid=0 rdev=00: 00
obj=system_u:object_r:proc_t:s0
type=AVC msg=audit(1151379270.259:1990): avc: denied { getattr } for pid=32363
comm="dccproc" name="meminfo" dev=proc ino=-268435 454
scontext=system_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=file
type=SYSCALL msg=audit(1151379270.259:1990): arch=40000003 syscall=197 success=yes exit=0
a0=5 a1=bfb18dfc a2=4891eff4 a3=5 items=0 pid=32363 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=AVC_PATH msg=audit(1151379270.259:1990): path="/proc/meminfo"
I think this may be generic startup code, probably dontaudit-able. We'll
see.
The rest are repeats.
Updated policy:
::::::::::::::
myclamav.te
::::::::::::::
policy_module(myclamav, 0.1.3)
require {
type clamd_t;
type clamscan_t;
type clamscan_tmp_t;
type freshclam_t;
type postfix_local_t;
type procmail_t;
};
type clamassassin_t;
domain_type(clamassassin_t)
type clamassassin_exec_t;
domain_entry_file(clamassassin_t,clamassassin_exec_t)
# ========================================
# clamassassin local policy
# ========================================
# Transition from unconfined for command-line usage
ifdef(`targeted_policy',`
clamav_domtrans_clamassassin(unconfined_t)
')
# clamassassin uses pipes
allow clamassassin_t self:fifo_file rw_file_perms;
# When clamassassin writes temp files, they're for clamscan to process
# so make them clamscan_tmp_t
allow clamassassin_t clamscan_tmp_t:dir create_dir_perms;
allow clamassassin_t clamscan_tmp_t:file create_file_perms;
files_tmp_filetrans(clamassassin_t, clamscan_tmp_t, { file dir })
# Use shared libraries
libs_use_ld_so(clamassassin_t)
libs_use_shared_libs(clamassassin_t)
# Run binaries such as /bin/mktemp
corecmd_exec_bin(clamassassin_t)
files_search_usr(clamassassin_t)
# Allow clamassassin (mktemp) to read /dev/urandom
dev_read_urand(clamassassin_t)
# Is this clamassassin writing via a pipe to postfix_local_t?
allow clamassassin_t postfix_local_t:fd use;
allow clamassassin_t postfix_local_t:fifo_file write;
# clamassassin probably doesn't need to be able to read /proc/meminfo
kernel_dontaudit_list_proc(clamassassin_t)
kernel_dontaudit_read_system_state(clamassassin_t)
# clamassassin needs to be able to call clamscan
clamav_domtrans_clamscan(clamassassin_t)
# ========================================
# clamd local policy
# ========================================
kernel_read_kernel_sysctls(clamd_t)
# ========================================
# clamscan local policy
# ========================================
# Is this clamscan writing via a pipe to postfix_local_t?
allow clamscan_t postfix_local_t:fd use;
allow clamscan_t postfix_local_t:fifo_file write;
# Is this clamscan_t reading via a pipe from procmail_t?
allow clamscan_t procmail_t:fifo_file read;
# ========================================
# freshclam local policy
# ========================================
# Allow freshclam to send syslog messages
logging_send_syslog_msg(freshclam_t)
# Allow freshclam to read generic kernel sysctls
kernel_read_kernel_sysctls(freshclam_t)
::::::::::::::
mydcc.te
::::::::::::::
policy_module(mydcc, 0.1.8)
# ==================================================
# Declarations
# ==================================================
require {
type dcc_client_t;
}
# ==================================================
# DCC client local policy
# ==================================================
allow dcc_client_t self:netlink_route_socket r_netlink_socket_perms;
corenet_udp_bind_inaddr_any_node(dcc_client_t)
# dcc_client probably doesn't need to be able to read /proc/meminfo
kernel_dontaudit_list_proc(dcc_client_t)
kernel_dontaudit_read_system_state(dcc_client_t)
spamassassin_read_spamd_tmp_files(dcc_client_t)
Paul.
11:48 a.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-06-27 at 17:20 +0100, Paul Howarth wrote:
Marc Schwartz wrote:
> On Tue, 2006-06-27 at 00:05 +0100, Paul Howarth wrote:
>> I share Nicolas' feelings about having hidden directories in /etc; this
>> could be mitigated perhaps by having something like the ".pyzor"
>> directory being replaced by a symlink to a "pyzor" directory.
>
> No disagreement with either of you here.
>
> The key here I believe is that we demonstrated a proof of concept, in
> that we can control the locations where these files get written and do
> so in a system-wide fashion. Even if this ends up being unique to FC/FE
> based installations due to SELinux requirements.
>
> I have no vested interest in the specific locations and only used the
> examples from the SA wiki as the basis for the initial attempt.
>
> We can certainly come to some appropriate consensus as to where we want
> them, whether higher in /etc or perhaps in /var.
>
> If you guys provide some feedback, I can make the requisite changes.
I think the main issue isn't really whether the directories live under
/var, /etc etc., but that they are "hidden" directories with names
starting with a dot. Can the tools be persuaded to use other, more
visible directory names?
Paul,
Just a quick reply here for clarification.
First, I'm an idiot. I took the term hidden to mean "buried", as opposed
to a file or folder that requires the use of 'ls -a' to be seen.
So, with that clarification, I think that the only change required here
would be to make /etc/spamassassin/.razor be /etc/spamassassin/razor.
pyzor is just in /etc/spamassassin, where it uses the 'servers' file and
dcc is otherwise unaffected.
If you wanted, I could move the pyzor 'servers' file (and edit the
requisite local.conf file) to use /etc/spamassassin/pyzor/servers
instead.
Thus, changing:
/etc/mail/spamassassin/local.cf
/etc/mail/spamassassin/.razor/razor-agent.conf
and the crontab entries to use razor instead of .razor should be all
that is required here. Same for pyzor if we move the servers file.
Do those changes affect any of the policies that we have in process,
before I move forward?
Thanks,
Marc
12:34 p.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-06-27 at 17:20 +0100, Paul Howarth wrote:
<snip>
The changes to the razor and pyzor locations have been made.
I did move .razor to /etc/mail/spamassassin/razor and I also moved pyzor
to /etc/mail/spamassassin/pyzor.
Note that in my prior reply, the paths that I listed
as /etc/spamassassin/... should in fact be /etc/mail/spamassassin. My
typos.
<snip of avc's and comments>
Updated policy:
<snip of new policies>
# semodule -l
amavis 1.0.4
clamav 1.0.1
dcc 1.0.0
myclamav 0.1.3
mydcc 0.1.8
mypostfix 0.1.0
mypyzor 0.2.2
myspamassassin 0.1.1
procmail 0.5.4
pyzor 1.0.1
razor 1.0.0
type=AVC msg=audit(1151428802.918:884): avc: denied { use } for pid=5062
comm="clamscan" name="[150534]" dev=pipefs ino=150534
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:procmail_t:s0
tclass=fd
type=SYSCALL msg=audit(1151428802.918:884): arch=40000003 syscall=11 success=yes exit=0
a0=9181c00 a1=9181210 a2=9181dd0 a3=9181d90 items=2 pid=5062 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamscan" exe="/usr/bin/clamscan"
subj=system_u:system_r:clamscan_t:s0
type=AVC_PATH msg=audit(1151428802.918:884): path="pipe:[150534]"
type=CWD msg=audit(1151428802.918:884): cwd="/home/marcs"
type=PATH msg=audit(1151428802.918:884): item=0 name="/usr/bin/clamscan"
inode=3123838 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:clamscan_exec_t:s0
type=PATH msg=audit(1151428802.918:884): 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
type=AVC msg=audit(1151428805.919:885): avc: denied { create } for pid=5084
comm="pyzor" scontext=system_u:system_r:pyzor_t:s0
tcontext=system_u:system_r:pyzor_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151428805.919:885): arch=40000003 syscall=102 success=yes exit=3
a0=1 a1=bfeffef8 a2=4891eff4 a3=95fe1b0 items=0 pid=5084 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=SOCKETCALL msg=audit(1151428805.919:885): nargs=3 a0=10 a1=3 a2=0
type=AVC msg=audit(1151428805.923:886): avc: denied { bind } for pid=5084
comm="pyzor" scontext=system_u:system_r:pyzor_t:s0
tcontext=system_u:system_r:pyzor_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151428805.923:886): arch=40000003 syscall=102 success=yes exit=0
a0=2 a1=bfeffef8 a2=4891eff4 a3=3 items=0 pid=5084 auid=4294967295 uid=500 gid=0 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=SOCKADDR msg=audit(1151428805.923:886): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151428805.923:886): nargs=3 a0=3 a1=bfefff04 a2=c
type=AVC msg=audit(1151428805.923:887): avc: denied { getattr } for pid=5084
comm="pyzor" scontext=system_u:system_r:pyzor_t:s0
tcontext=system_u:system_r:pyzor_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151428805.923:887): arch=40000003 syscall=102 success=yes exit=0
a0=6 a1=bfeffef8 a2=4891eff4 a3=3 items=0 pid=5084 auid=4294967295 uid=500 gid=0 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=SOCKADDR msg=audit(1151428805.923:887): saddr=10000000DC13000000000000
type=SOCKETCALL msg=audit(1151428805.923:887): nargs=3 a0=3 a1=bfefff04 a2=bfefff10
type=AVC msg=audit(1151428805.923:888): avc: denied { write } for pid=5084
comm="pyzor" scontext=system_u:system_r:pyzor_t:s0
tcontext=system_u:system_r:pyzor_t:s0 tclass=netlink_route_socket
type=AVC msg=audit(1151428805.923:888): avc: denied { nlmsg_read } for pid=5084
comm="pyzor" scontext=system_u:system_r:pyzor_t:s0
tcontext=system_u:system_r:pyzor_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151428805.923:888): arch=40000003 syscall=102 success=yes exit=20
a0=b a1=bfefee44 a2=4891eff4 a3=ffffffcc items=0 pid=5084 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=SOCKADDR msg=audit(1151428805.923:888): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151428805.923:888): nargs=6 a0=3 a1=bfeffebc a2=14 a3=0
a4=bfeffed0 a5=c
type=AVC msg=audit(1151428805.923:889): avc: denied { read } for pid=5084
comm="pyzor" scontext=system_u:system_r:pyzor_t:s0
tcontext=system_u:system_r:pyzor_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151428805.923:889): arch=40000003 syscall=102 success=yes exit=128
a0=11 a1=bfefee44 a2=4891eff4 a3=ffffffcc items=0 pid=5084 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=SOCKADDR msg=audit(1151428805.923:889): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151428805.923:889): nargs=3 a0=3 a1=bfeffea0 a2=0
type=AVC msg=audit(1151428805.923:890): avc: denied { search } for pid=5084
comm="pyzor" name="nscd" dev=dm-1 ino=87802
scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:nscd_var_run_t:s0
tclass=dir
type=SYSCALL msg=audit(1151428805.923:890): arch=40000003 syscall=102 success=no exit=-2
a0=3 a1=bfeffab4 a2=4891eff4 a3=48909fd4 items=0 pid=5084 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=SOCKADDR msg=audit(1151428805.923:890):
saddr=01002F7661722F72756E2F6E7363642F736F636B657400D8CD0040F3CD00AC8BC9B718FBEFBF6B5AC300AC8BC9B780DBC7B71C2360094ACCC00020E0C9B7241F600900000000E4D8CD00AC8BC9B700000000F8FCEFBF7BC7C600AC8BC9B780DBC7B71C236009E4D8CD0001000000
type=SOCKETCALL msg=audit(1151428805.923:890): nargs=3 a0=3 a1=bfeffac6 a2=6e
type=AVC msg=audit(1151428805.923:891): avc: denied { name_connect } for pid=5084
comm="pyzor" dest=80 scontext=system_u:system_r:pyzor_t:s0
tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1151428805.923:891): avc: denied { send_msg } for pid=5084
comm="pyzor" saddr=192.168.0.64 src=40031 daddr=66.35.250.209 dest=80 netif=eth0
scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:http_port_t:s0
tclass=tcp_socket
type=AVC msg=audit(1151428806.007:892): avc: denied { recv_msg } for pid=5078
comm="clamscan" saddr=66.35.250.209 src=80 daddr=192.168.0.64 dest=40031
netif=eth0 scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:http_port_t:s0
tclass=tcp_socket
type=SYSCALL msg=audit(1151428805.923:891): arch=40000003 syscall=102 success=yes exit=0
a0=3 a1=bfeffe10 a2=2c9118 a3=b7ef3aa0 items=0 pid=5084 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=SOCKADDR msg=audit(1151428805.923:891): saddr=020000504223FAD10000000000000000
type=SOCKETCALL msg=audit(1151428805.923:891): nargs=3 a0=3 a1=b7ef3ab8 a2=10
One thing to note here. I am on the new kernel: 2.6.17-1.2139_FC5
There have been some flaky things going on with networking as you may
have noted on the general FC list, just in case any of that is relevant
here. I have not installed the new (updates testing) initscripts as of
yet, as I am still trying to get a sense of where things stand. I have
seen some issues with network configs and device labelling issues,
including wireless instability (using the bcm43xx driver) which was
working under the former kernel with ndiswrapper. FWIW.
Thanks,
Marc
9:08 a.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-06-27 at 12:34 -0500, Marc Schwartz (via MN) wrote:
On Tue, 2006-06-27 at 17:20 +0100, Paul Howarth wrote:
# semodule -l
amavis 1.0.4
clamav 1.0.1
dcc 1.0.0
myclamav 0.1.3
mydcc 0.1.8
mypostfix 0.1.0
mypyzor 0.2.2
myspamassassin 0.1.1
procmail 0.5.4
pyzor 1.0.1
razor 1.0.0
type=AVC msg=audit(1151428802.918:884): avc: denied { use } for pid=5062
comm="clamscan" name="[150534]" dev=pipefs ino=150534
scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:procmail_t:s0
tclass=fd
type=SYSCALL msg=audit(1151428802.918:884): arch=40000003 syscall=11 success=yes exit=0
a0=9181c00 a1=9181210 a2=9181dd0 a3=9181d90 items=2 pid=5062 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamscan" exe="/usr/bin/clamscan"
subj=system_u:system_r:clamscan_t:s0
type=AVC_PATH msg=audit(1151428802.918:884): path="pipe:[150534]"
type=CWD msg=audit(1151428802.918:884): cwd="/home/marcs"
type=PATH msg=audit(1151428802.918:884): item=0 name="/usr/bin/clamscan"
inode=3123838 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:clamscan_exec_t:s0
type=PATH msg=audit(1151428802.918:884): 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
I believe this is clamscan reading data piped from procmail. Either than
or an inherited file descriptor.
type=AVC msg=audit(1151428805.919:885): avc: denied { create } for
pid=5084 comm="pyzor" scontext=system_u:system_r:pyzor_t:s0
tcontext=system_u:system_r:pyzor_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151428805.919:885): arch=40000003 syscall=102 success=yes exit=3
a0=1 a1=bfeffef8 a2=4891eff4 a3=95fe1b0 items=0 pid=5084 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=SOCKETCALL msg=audit(1151428805.919:885): nargs=3 a0=10 a1=3 a2=0
type=AVC msg=audit(1151428805.923:886): avc: denied { bind } for pid=5084
comm="pyzor" scontext=system_u:system_r:pyzor_t:s0
tcontext=system_u:system_r:pyzor_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151428805.923:886): arch=40000003 syscall=102 success=yes exit=0
a0=2 a1=bfeffef8 a2=4891eff4 a3=3 items=0 pid=5084 auid=4294967295 uid=500 gid=0 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=SOCKADDR msg=audit(1151428805.923:886): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151428805.923:886): nargs=3 a0=3 a1=bfefff04 a2=c
type=AVC msg=audit(1151428805.923:887): avc: denied { getattr } for pid=5084
comm="pyzor" scontext=system_u:system_r:pyzor_t:s0
tcontext=system_u:system_r:pyzor_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151428805.923:887): arch=40000003 syscall=102 success=yes exit=0
a0=6 a1=bfeffef8 a2=4891eff4 a3=3 items=0 pid=5084 auid=4294967295 uid=500 gid=0 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=SOCKADDR msg=audit(1151428805.923:887): saddr=10000000DC13000000000000
type=SOCKETCALL msg=audit(1151428805.923:887): nargs=3 a0=3 a1=bfefff04 a2=bfefff10
type=AVC msg=audit(1151428805.923:888): avc: denied { write } for pid=5084
comm="pyzor" scontext=system_u:system_r:pyzor_t:s0
tcontext=system_u:system_r:pyzor_t:s0 tclass=netlink_route_socket
type=AVC msg=audit(1151428805.923:888): avc: denied { nlmsg_read } for pid=5084
comm="pyzor" scontext=system_u:system_r:pyzor_t:s0
tcontext=system_u:system_r:pyzor_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151428805.923:888): arch=40000003 syscall=102 success=yes exit=20
a0=b a1=bfefee44 a2=4891eff4 a3=ffffffcc items=0 pid=5084 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=SOCKADDR msg=audit(1151428805.923:888): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151428805.923:888): nargs=6 a0=3 a1=bfeffebc a2=14 a3=0
a4=bfeffed0 a5=c
type=AVC msg=audit(1151428805.923:889): avc: denied { read } for pid=5084
comm="pyzor" scontext=system_u:system_r:pyzor_t:s0
tcontext=system_u:system_r:pyzor_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1151428805.923:889): arch=40000003 syscall=102 success=yes
exit=128 a0=11 a1=bfefee44 a2=4891eff4 a3=ffffffcc items=0 pid=5084 auid=4294967295
uid=500 gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="pyzor" exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=SOCKADDR msg=audit(1151428805.923:889): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1151428805.923:889): nargs=3 a0=3 a1=bfeffea0 a2=0
pyzor reading the routing table.
type=AVC msg=audit(1151428805.923:890): avc: denied { search } for
pid=5084 comm="pyzor" name="nscd" dev=dm-1 ino=87802
scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:nscd_var_run_t:s0
tclass=dir
type=SYSCALL msg=audit(1151428805.923:890): arch=40000003 syscall=102 success=no exit=-2
a0=3 a1=bfeffab4 a2=4891eff4 a3=48909fd4 items=0 pid=5084 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=SOCKADDR msg=audit(1151428805.923:890):
saddr=01002F7661722F72756E2F6E7363642F736F636B657400D8CD0040F3CD00AC8BC9B718FBEFBF6B5AC300AC8BC9B780DBC7B71C2360094ACCC00020E0C9B7241F600900000000E4D8CD00AC8BC9B700000000F8FCEFBF7BC7C600AC8BC9B780DBC7B71C236009E4D8CD0001000000
type=SOCKETCALL msg=audit(1151428805.923:890): nargs=3 a0=3 a1=bfeffac6 a2=6e
Using nscd.
type=AVC msg=audit(1151428805.923:891): avc: denied { name_connect
} for pid=5084 comm="pyzor" dest=80 scontext=system_u:system_r:pyzor_t:s0
tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1151428805.923:891): avc: denied { send_msg } for pid=5084
comm="pyzor" saddr=192.168.0.64 src=40031 daddr=66.35.250.209 dest=80 netif=eth0
scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:http_port_t:s0
tclass=tcp_socket
type=AVC msg=audit(1151428806.007:892): avc: denied { recv_msg } for pid=5078
comm="clamscan" saddr=66.35.250.209 src=80 daddr=192.168.0.64 dest=40031
netif=eth0 scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:http_port_t:s0
tclass=tcp_socket
type=SYSCALL msg=audit(1151428805.923:891): arch=40000003 syscall=102 success=yes exit=0
a0=3 a1=bfeffe10 a2=2c9118 a3=b7ef3aa0 items=0 pid=5084 auid=4294967295 uid=500 gid=0
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="pyzor"
exe="/usr/bin/python" subj=system_u:system_r:pyzor_t:s0
type=SOCKADDR msg=audit(1151428805.923:891): saddr=020000504223FAD10000000000000000
type=SOCKETCALL msg=audit(1151428805.923:891): nargs=3 a0=3 a1=b7ef3ab8 a2=10
Get data from remote web server.
One thing to note here. I am on the new kernel: 2.6.17-1.2139_FC5
There have been some flaky things going on with networking as you may
have noted on the general FC list, just in case any of that is relevant
here. I have not installed the new (updates testing) initscripts as of
yet, as I am still trying to get a sense of where things stand. I have
seen some issues with network configs and device labelling issues,
including wireless instability (using the bcm43xx driver) which was
working under the former kernel with ndiswrapper. FWIW.
I don't think that any of the above AVCs are related to this.
Updated policy:
::::::::::::::
myclamav.te
::::::::::::::
policy_module(myclamav, 0.1.4)
require {
type clamd_t;
type clamscan_t;
type clamscan_tmp_t;
type freshclam_t;
type postfix_local_t;
type procmail_t;
};
type clamassassin_t;
domain_type(clamassassin_t)
type clamassassin_exec_t;
domain_entry_file(clamassassin_t,clamassassin_exec_t)
# ========================================
# clamassassin local policy
# ========================================
# Transition from unconfined for command-line usage
ifdef(`targeted_policy',`
clamav_domtrans_clamassassin(unconfined_t)
')
# clamassassin uses pipes
allow clamassassin_t self:fifo_file rw_file_perms;
# When clamassassin writes temp files, they're for clamscan to process
# so make them clamscan_tmp_t
allow clamassassin_t clamscan_tmp_t:dir create_dir_perms;
allow clamassassin_t clamscan_tmp_t:file create_file_perms;
files_tmp_filetrans(clamassassin_t, clamscan_tmp_t, { file dir })
# Use shared libraries
libs_use_ld_so(clamassassin_t)
libs_use_shared_libs(clamassassin_t)
# Run binaries such as /bin/mktemp
corecmd_exec_bin(clamassassin_t)
files_search_usr(clamassassin_t)
# Allow clamassassin (mktemp) to read /dev/urandom
dev_read_urand(clamassassin_t)
# Is this clamassassin writing via a pipe to postfix_local_t?
allow clamassassin_t postfix_local_t:fd use;
allow clamassassin_t postfix_local_t:fifo_file write;
# clamassassin probably doesn't need to be able to read /proc/meminfo
kernel_dontaudit_list_proc(clamassassin_t)
kernel_dontaudit_read_system_state(clamassassin_t)
# clamassassin needs to be able to call clamscan
clamav_domtrans_clamscan(clamassassin_t)
# ========================================
# clamd local policy
# ========================================
kernel_read_kernel_sysctls(clamd_t)
# ========================================
# clamscan local policy
# ========================================
# Is this clamscan writing via a pipe to postfix_local_t?
allow clamscan_t postfix_local_t:fd use;
allow clamscan_t postfix_local_t:fifo_file write;
# Is this clamscan_t reading via a pipe from procmail_t?
allow clamscan_t procmail_t:fd use;
allow clamscan_t procmail_t:fifo_file read;
# ========================================
# freshclam local policy
# ========================================
# Allow freshclam to send syslog messages
logging_send_syslog_msg(freshclam_t)
# Allow freshclam to read generic kernel sysctls
kernel_read_kernel_sysctls(freshclam_t)
::::::::::::::
mypyzor.te
::::::::::::::
policy_module(mypyzor, 0.2.3)
require {
type etc_mail_t;
type http_port_t;
type pyzor_t;
type pyzor_exec_t;
type pyzor_port_t;
type spamd_t;
};
# temp files
type pyzor_tmp_t;
files_tmp_file(pyzor_tmp_t)
# Allow pyzor to create and use temp files and dirs
allow pyzor_t pyzor_tmp_t:dir create_dir_perms;
allow pyzor_t pyzor_tmp_t:file create_file_perms;
files_type(pyzor_tmp_t)
files_tmp_filetrans(pyzor_t, pyzor_tmp_t, { file dir })
# Allow pyzor to read config (and any other file...)
# from user home directories
userdom_read_unpriv_users_home_content_files(pyzor_t)
# Allow pyzor to read /dev/urandom
dev_read_urand(pyzor_t)
# Work with nscd
nscd_socket_use(pyzor_t)
# Allow pyzor to send and receive pyzor messages!
allow pyzor_t pyzor_port_t:udp_socket send_msg;
allow pyzor_t pyzor_port_t:udp_socket recv_msg;
# Get data from remote websites
allow pyzor_t http_port_t:tcp_socket { name_connect recv_msg send_msg };
# Allow spamd to signal pyzor (kill/hup ?)
# [should be an interface for this in pyzor.if]
allow spamd_t pyzor_t:process signal;
# This doesn't seem to break anything
# [should be an interface for this in pyzor.if]
dontaudit spamd_t pyzor_exec_t:file getattr;
# Read sitewide config
allow pyzor_t etc_mail_t:dir { getattr search };
allow pyzor_t etc_mail_t:file { getattr read };
# Allow pyzor to read the routing table
allow pyzor_t self:netlink_route_socket { r_netlink_socket_perms };
# Allow pyzor to ...?
corecmd_search_bin(pyzor_t)
kernel_read_kernel_sysctls(pyzor_t)
# It does a getattr on /usr/bin/time for reasons unknown...
dontaudit pyzor_t bin_t:dir getattr;
dontaudit pyzor_t bin_t:file getattr;
# Pyzor/python probably doesn't need to be able to read /proc/meminfo
kernel_dontaudit_list_proc(pyzor_t)
kernel_dontaudit_read_system_state(pyzor_t)
Paul.
2:22 p.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-28 at 15:08 +0100, Paul Howarth wrote:
On Tue, 2006-06-27 at 12:34 -0500, Marc Schwartz (via MN) wrote:
<snip old avc's>
> One thing to note here. I am on the new kernel:
2.6.17-1.2139_FC5
>
> There have been some flaky things going on with networking as you may
> have noted on the general FC list, just in case any of that is relevant
> here. I have not installed the new (updates testing) initscripts as of
> yet, as I am still trying to get a sense of where things stand. I have
> seen some issues with network configs and device labelling issues,
> including wireless instability (using the bcm43xx driver) which was
> working under the former kernel with ndiswrapper. FWIW.
I don't think that any of the above AVCs are related to this.
OK. Wanted to make note of it, just in case.
<snip new policies>
# semodule -l
amavis 1.0.4
clamav 1.0.1
dcc 1.0.0
myclamav 0.1.4
mydcc 0.1.8
mypostfix 0.1.0
mypyzor 0.2.3
myspamassassin 0.1.1
procmail 0.5.4
pyzor 1.0.1
razor 1.0.0
New avc's:
type=AVC msg=audit(1151521329.964:1158): avc: denied { search } for pid=5442
comm="local" name="clamav" dev=dm-1 ino=44957
scontext=system_u:system_r:postfix_local_t:s0
tcontext=system_u:object_r:clamd_var_lib_t:s0 tclass=dir
type=SYSCALL msg=audit(1151521329.964:1158): arch=40000003 syscall=196 success=no exit=-2
a0=939f848 a1=bffd2e80 a2=721ff4 a3=3 items=1 pid=5442 auid=4294967295 uid=0 gid=0
euid=100 suid=0 fsuid=100 egid=101 sgid=0 fsgid=101 tty=(none) comm="local"
exe="/usr/libexec/postfix/local" subj=system_u:system_r:postfix_local_t:s0
type=CWD msg=audit(1151521329.964:1158): cwd="/var/spool/postfix"
type=PATH msg=audit(1151521329.964:1158): item=0 name="/var/lib/clamav/.forward"
obj=system_u:object_r:etc_t:s0
type=AVC msg=audit(1151521329.988:1159): avc: denied { search } for pid=5449
comm="procmail" name="clamav" dev=dm-1 ino=44957
scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamd_var_lib_t:s0
tclass=dir
type=SYSCALL msg=audit(1151521329.988:1159): arch=40000003 syscall=195 success=no exit=-2
a0=8dd0d60 a1=bfe27a6c a2=4891eff4 a3=0 items=1 pid=5449 auid=4294967295 uid=100 gid=101
euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none)
comm="procmail" exe="/usr/bin/procmail"
subj=system_u:system_r:procmail_t:s0
type=CWD msg=audit(1151521329.988:1159): cwd="/var/spool/postfix"
Getting better. :-)
Thanks,
Marc
3:13 p.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-28 at 14:22 -0500, Marc Schwartz (via MN) wrote:
On Wed, 2006-06-28 at 15:08 +0100, Paul Howarth wrote:
> On Tue, 2006-06-27 at 12:34 -0500, Marc Schwartz (via MN) wrote:
<snip old avc's>
> > One thing to note here. I am on the new kernel: 2.6.17-1.2139_FC5
> >
> > There have been some flaky things going on with networking as you may
> > have noted on the general FC list, just in case any of that is relevant
> > here. I have not installed the new (updates testing) initscripts as of
> > yet, as I am still trying to get a sense of where things stand. I have
> > seen some issues with network configs and device labelling issues,
> > including wireless instability (using the bcm43xx driver) which was
> > working under the former kernel with ndiswrapper. FWIW.
>
> I don't think that any of the above AVCs are related to this.
OK. Wanted to make note of it, just in case.
<snip new policies>
# semodule -l
amavis 1.0.4
clamav 1.0.1
dcc 1.0.0
myclamav 0.1.4
mydcc 0.1.8
mypostfix 0.1.0
mypyzor 0.2.3
myspamassassin 0.1.1
procmail 0.5.4
pyzor 1.0.1
razor 1.0.0
New avc's:
type=AVC msg=audit(1151521329.964:1158): avc: denied { search } for pid=5442
comm="local" name="clamav" dev=dm-1 ino=44957
scontext=system_u:system_r:postfix_local_t:s0
tcontext=system_u:object_r:clamd_var_lib_t:s0 tclass=dir
type=SYSCALL msg=audit(1151521329.964:1158): arch=40000003 syscall=196 success=no exit=-2
a0=939f848 a1=bffd2e80 a2=721ff4 a3=3 items=1 pid=5442 auid=4294967295 uid=0 gid=0
euid=100 suid=0 fsuid=100 egid=101 sgid=0 fsgid=101 tty=(none) comm="local"
exe="/usr/libexec/postfix/local" subj=system_u:system_r:postfix_local_t:s0
type=CWD msg=audit(1151521329.964:1158): cwd="/var/spool/postfix"
type=PATH msg=audit(1151521329.964:1158): item=0
name="/var/lib/clamav/.forward" obj=system_u:object_r:etc_t:s0
postfix local looking in /var/lib/clamav
type=AVC msg=audit(1151521329.988:1159): avc: denied { search } for
pid=5449 comm="procmail" name="clamav" dev=dm-1 ino=44957
scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamd_var_lib_t:s0
tclass=dir
type=SYSCALL msg=audit(1151521329.988:1159): arch=40000003 syscall=195 success=no exit=-2
a0=8dd0d60 a1=bfe27a6c a2=4891eff4 a3=0 items=1 pid=5449 auid=4294967295 uid=100 gid=101
euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none)
comm="procmail" exe="/usr/bin/procmail"
subj=system_u:system_r:procmail_t:s0
type=CWD msg=audit(1151521329.988:1159): cwd="/var/spool/postfix"
same for procmail
This appears to be postfix local and procmail trying to
read /var/lib/clamav/.forward; does that sound reasonable?
You can bump myclamav.te to version 0.1.5 and append the following:
# ===========================================
# things that should be done via an interface
# ===========================================
allow postfix_local_t clamd_var_lib_t:dir r_dir_perms;
allow procmail_t clamd_var_lib_t:dir r_dir_perms;
Paul.
3:56 p.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-28 at 21:13 +0100, Paul Howarth wrote:
On Wed, 2006-06-28 at 14:22 -0500, Marc Schwartz (via MN) wrote:
>
> <snip old avc's>
> <snip new policies>
>
> # semodule -l
> amavis 1.0.4
> clamav 1.0.1
> dcc 1.0.0
> myclamav 0.1.4
> mydcc 0.1.8
> mypostfix 0.1.0
> mypyzor 0.2.3
> myspamassassin 0.1.1
> procmail 0.5.4
> pyzor 1.0.1
> razor 1.0.0
>
>
> New avc's:
>
> type=AVC msg=audit(1151521329.964:1158): avc: denied { search } for pid=5442
comm="local" name="clamav" dev=dm-1 ino=44957
scontext=system_u:system_r:postfix_local_t:s0
tcontext=system_u:object_r:clamd_var_lib_t:s0 tclass=dir
> type=SYSCALL msg=audit(1151521329.964:1158): arch=40000003 syscall=196 success=no
exit=-2 a0=939f848 a1=bffd2e80 a2=721ff4 a3=3 items=1 pid=5442 auid=4294967295 uid=0 gid=0
euid=100 suid=0 fsuid=100 egid=101 sgid=0 fsgid=101 tty=(none) comm="local"
exe="/usr/libexec/postfix/local" subj=system_u:system_r:postfix_local_t:s0
> type=CWD msg=audit(1151521329.964:1158): cwd="/var/spool/postfix"
> type=PATH msg=audit(1151521329.964:1158): item=0
name="/var/lib/clamav/.forward" obj=system_u:object_r:etc_t:s0
postfix local looking in /var/lib/clamav
> type=AVC msg=audit(1151521329.988:1159): avc: denied { search } for pid=5449
comm="procmail" name="clamav" dev=dm-1 ino=44957
scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamd_var_lib_t:s0
tclass=dir
> type=SYSCALL msg=audit(1151521329.988:1159): arch=40000003 syscall=195 success=no
exit=-2 a0=8dd0d60 a1=bfe27a6c a2=4891eff4 a3=0 items=1 pid=5449 auid=4294967295 uid=100
gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none)
comm="procmail" exe="/usr/bin/procmail"
subj=system_u:system_r:procmail_t:s0
> type=CWD msg=audit(1151521329.988:1159): cwd="/var/spool/postfix"
same for procmail
This appears to be postfix local and procmail trying to
read /var/lib/clamav/.forward; does that sound reasonable?
There are no .forward files on my system at all, unless that is a temp
file, which does not make sense location-wise.
A Google search came up empty for that file, so I can only presume that
there are certain configuration scenarios where the pipelining of
e-mails would require that file.
Since I am using clamassassin, I also searched through that script and
noted nothing relevant here.
Not sure what else to make of it.
You can bump myclamav.te to version 0.1.5 and append the following:
# ===========================================
# things that should be done via an interface
# ===========================================
allow postfix_local_t clamd_var_lib_t:dir r_dir_perms;
allow procmail_t clamd_var_lib_t:dir r_dir_perms;
Paul.
Done, including the add in your second e-mail.
# semodule -l
amavis 1.0.4
clamav 1.0.1
dcc 1.0.0
myclamav 0.1.5
mydcc 0.1.8
mypostfix 0.1.0
mypyzor 0.2.3
myspamassassin 0.1.1
procmail 0.5.4
pyzor 1.0.1
razor 1.0.0
No further avc's at this time.
Is it time to venture back into the Enforcing World once again?
Thanks,
Marc
4:23 p.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-28 at 15:56 -0500, Marc Schwartz (via MN) wrote:
On Wed, 2006-06-28 at 21:13 +0100, Paul Howarth wrote:
> On Wed, 2006-06-28 at 14:22 -0500, Marc Schwartz (via MN) wrote:
> > New avc's:
> >
> > type=AVC msg=audit(1151521329.964:1158): avc: denied { search } for pid=5442
comm="local" name="clamav" dev=dm-1 ino=44957
scontext=system_u:system_r:postfix_local_t:s0
tcontext=system_u:object_r:clamd_var_lib_t:s0 tclass=dir
> > type=SYSCALL msg=audit(1151521329.964:1158): arch=40000003 syscall=196
success=no exit=-2 a0=939f848 a1=bffd2e80 a2=721ff4 a3=3 items=1 pid=5442 auid=4294967295
uid=0 gid=0 euid=100 suid=0 fsuid=100 egid=101 sgid=0 fsgid=101 tty=(none)
comm="local" exe="/usr/libexec/postfix/local"
subj=system_u:system_r:postfix_local_t:s0
> > type=CWD msg=audit(1151521329.964:1158): cwd="/var/spool/postfix"
> > type=PATH msg=audit(1151521329.964:1158): item=0
name="/var/lib/clamav/.forward" obj=system_u:object_r:etc_t:s0
>
> postfix local looking in /var/lib/clamav
>
> > type=AVC msg=audit(1151521329.988:1159): avc: denied { search } for pid=5449
comm="procmail" name="clamav" dev=dm-1 ino=44957
scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:clamd_var_lib_t:s0
tclass=dir
> > type=SYSCALL msg=audit(1151521329.988:1159): arch=40000003 syscall=195
success=no exit=-2 a0=8dd0d60 a1=bfe27a6c a2=4891eff4 a3=0 items=1 pid=5449
auid=4294967295 uid=100 gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101
tty=(none) comm="procmail" exe="/usr/bin/procmail"
subj=system_u:system_r:procmail_t:s0
> > type=CWD msg=audit(1151521329.988:1159): cwd="/var/spool/postfix"
>
> same for procmail
>
> This appears to be postfix local and procmail trying to
> read /var/lib/clamav/.forward; does that sound reasonable?
There are no .forward files on my system at all, unless that is a temp
file, which does not make sense location-wise.
A Google search came up empty for that file, so I can only presume that
there are certain configuration scenarios where the pipelining of
e-mails would require that file.
Since I am using clamassassin, I also searched through that script and
noted nothing relevant here.
Not sure what else to make of it.
That might be dontaudit-able. Is /var/lib/clamav any user's home
directory?
> You can bump myclamav.te to version 0.1.5 and append the
following:
>
> # ===========================================
> # things that should be done via an interface
> # ===========================================
> allow postfix_local_t clamd_var_lib_t:dir r_dir_perms;
> allow procmail_t clamd_var_lib_t:dir r_dir_perms;
>
> Paul.
Done, including the add in your second e-mail.
# semodule -l
amavis 1.0.4
clamav 1.0.1
dcc 1.0.0
myclamav 0.1.5
mydcc 0.1.8
mypostfix 0.1.0
mypyzor 0.2.3
myspamassassin 0.1.1
procmail 0.5.4
pyzor 1.0.1
razor 1.0.0
No further avc's at this time.
Is it time to venture back into the Enforcing World once again?
Give it a try. Bear in mind it may fail if any of the dontaudit rules
should be allows instead.
Paul.
4:38 p.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-28 at 22:23 +0100, Paul Howarth wrote:
On Wed, 2006-06-28 at 15:56 -0500, Marc Schwartz (via MN) wrote:
<snip>
>
> There are no .forward files on my system at all, unless that is a temp
> file, which does not make sense location-wise.
>
> A Google search came up empty for that file, so I can only presume that
> there are certain configuration scenarios where the pipelining of
> e-mails would require that file.
>
> Since I am using clamassassin, I also searched through that script and
> noted nothing relevant here.
>
> Not sure what else to make of it.
That might be dontaudit-able. Is /var/lib/clamav any user's home
directory?
The /var/lib/clamav tree appears to be owned by 'clamav', both user and
group:
$ ls -l /var/lib
total 264
...
drwxr-xr-x 2 clamav clamav 4096 Jun 28 11:00 clamav
...
ls -l /var/lib/clamav
total 8832
-rw-r--r-- 1 clamav clamav 4050 Jun 28 11:01 clamav-4d6166b710f63075
-rw-r--r-- 1 clamav clamav 3640966 Jun 9 16:49 clamav-651c96be267fc93e
-rw-r--r-- 1 clamav clamav 380351 Jun 28 08:00 daily.cvd
-rw-r--r-- 1 clamav clamav 4978654 Jun 9 18:00 main.cvd
$ cat /etc/passwd | grep clamav
clamav:x:100:101:Clamav database update user:/var/lib/clamav:/sbin/nologin
$ cat /etc/group | grep clamav
clamav:x:101:
<snip>
>
> No further avc's at this time.
>
> Is it time to venture back into the Enforcing World once again?
Give it a try. Bear in mind it may fail if any of the dontaudit rules
should be allows instead.
I'll wait for any comments that you have on the above first.
Thanks,
Marc
5:13 p.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-28 at 16:38 -0500, Marc Schwartz (via MN) wrote:
On Wed, 2006-06-28 at 22:23 +0100, Paul Howarth wrote:
> On Wed, 2006-06-28 at 15:56 -0500, Marc Schwartz (via MN) wrote:
<snip>
> >
> > There are no .forward files on my system at all, unless that is a temp
> > file, which does not make sense location-wise.
> >
> > A Google search came up empty for that file, so I can only presume that
> > there are certain configuration scenarios where the pipelining of
> > e-mails would require that file.
> >
> > Since I am using clamassassin, I also searched through that script and
> > noted nothing relevant here.
> >
> > Not sure what else to make of it.
>
> That might be dontaudit-able. Is /var/lib/clamav any user's home
> directory?
The /var/lib/clamav tree appears to be owned by 'clamav', both user and
group:
$ ls -l /var/lib
total 264
...
drwxr-xr-x 2 clamav clamav 4096 Jun 28 11:00 clamav
...
ls -l /var/lib/clamav
total 8832
-rw-r--r-- 1 clamav clamav 4050 Jun 28 11:01 clamav-4d6166b710f63075
-rw-r--r-- 1 clamav clamav 3640966 Jun 9 16:49 clamav-651c96be267fc93e
-rw-r--r-- 1 clamav clamav 380351 Jun 28 08:00 daily.cvd
-rw-r--r-- 1 clamav clamav 4978654 Jun 9 18:00 main.cvd
$ cat /etc/passwd | grep clamav
clamav:x:100:101:Clamav database update user:/var/lib/clamav:/sbin/nologin
$ cat /etc/group | grep clamav
clamav:x:101:
The search in /var/lib/clamav is probably a result of something running
as that user, perhaps procmail. Does the clamav user get any mail?
Paul.
10:15 p.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-28 at 23:13 +0100, Paul Howarth wrote:
On Wed, 2006-06-28 at 16:38 -0500, Marc Schwartz (via MN) wrote:
> On Wed, 2006-06-28 at 22:23 +0100, Paul Howarth wrote:
> > On Wed, 2006-06-28 at 15:56 -0500, Marc Schwartz (via MN) wrote:
>
> <snip>
>
> > >
> > > There are no .forward files on my system at all, unless that is a temp
> > > file, which does not make sense location-wise.
> > >
> > > A Google search came up empty for that file, so I can only presume that
> > > there are certain configuration scenarios where the pipelining of
> > > e-mails would require that file.
> > >
> > > Since I am using clamassassin, I also searched through that script and
> > > noted nothing relevant here.
> > >
> > > Not sure what else to make of it.
> >
> > That might be dontaudit-able. Is /var/lib/clamav any user's home
> > directory?
>
> The /var/lib/clamav tree appears to be owned by 'clamav', both user and
> group:
>
> $ ls -l /var/lib
> total 264
> ...
> drwxr-xr-x 2 clamav clamav 4096 Jun 28 11:00 clamav
> ...
>
> ls -l /var/lib/clamav
> total 8832
> -rw-r--r-- 1 clamav clamav 4050 Jun 28 11:01 clamav-4d6166b710f63075
> -rw-r--r-- 1 clamav clamav 3640966 Jun 9 16:49 clamav-651c96be267fc93e
> -rw-r--r-- 1 clamav clamav 380351 Jun 28 08:00 daily.cvd
> -rw-r--r-- 1 clamav clamav 4978654 Jun 9 18:00 main.cvd
>
>
> $ cat /etc/passwd | grep clamav
> clamav:x:100:101:Clamav database update user:/var/lib/clamav:/sbin/nologin
>
>
> $ cat /etc/group | grep clamav
> clamav:x:101:
The search in /var/lib/clamav is probably a result of something running
as that user, perhaps procmail. Does the clamav user get any mail?
Paul,
Good call. Yes indeed.
It would appear that clamav (the user) gets mail when there are problems
with the hourly database updates. For example, if there are DNS problems
or other issues with server access. I do see these coming from the root
account, which then get forwarded to my user account via the postfix
mapping. I had not paid attention, until now, regarding the multiple
e-mail addresses in the To: field.
After doing some searching, it turns out that this is configured
in /etc/crond./clamav-update.
In that file, mail is targeted (by default) to go to root, postmaster,
webmaster and clamav. Now that I have looked at the content
of /var/spool/mail/clamav, I do note that the mail is indeed sent to the
aforementioned users.
Of course, postmaster and webmaster do not exist on my system as users.
Also, in the file is the following:
## It is ok to execute it as root; freshclam drops privileges and becomes
## user 'clamav' as soon as possible
0 */3 * * * root /usr/share/clamav/freshclam-sleep
From other sources, it would appear that the freshclam programs, even
if
started as root, will setuid to clamav. This is configured
in /etc/freshclam.conf. The default is:
# By default when started freshclam drops privileges and switches to the
# "clamav" user. This directive allows you to change the database owner.
# Default: clamav (may depend on installation options)
#DatabaseOwner clamav
I could adjust the e-mail targets or other settings if you need me to.
Let me know.
Thanks,
Marc
2:29 a.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-28 at 22:15 -0500, Marc Schwartz wrote:
On Wed, 2006-06-28 at 23:13 +0100, Paul Howarth wrote:
> On Wed, 2006-06-28 at 16:38 -0500, Marc Schwartz (via MN) wrote:
> > On Wed, 2006-06-28 at 22:23 +0100, Paul Howarth wrote:
> > > On Wed, 2006-06-28 at 15:56 -0500, Marc Schwartz (via MN) wrote:
> >
> > <snip>
> >
> > > >
> > > > There are no .forward files on my system at all, unless that is a
temp
> > > > file, which does not make sense location-wise.
> > > >
> > > > A Google search came up empty for that file, so I can only presume
that
> > > > there are certain configuration scenarios where the pipelining of
> > > > e-mails would require that file.
> > > >
> > > > Since I am using clamassassin, I also searched through that script
and
> > > > noted nothing relevant here.
> > > >
> > > > Not sure what else to make of it.
> > >
> > > That might be dontaudit-able. Is /var/lib/clamav any user's home
> > > directory?
> >
> > The /var/lib/clamav tree appears to be owned by 'clamav', both user
and
> > group:
> >
> > $ ls -l /var/lib
> > total 264
> > ...
> > drwxr-xr-x 2 clamav clamav 4096 Jun 28 11:00 clamav
> > ...
> >
> > ls -l /var/lib/clamav
> > total 8832
> > -rw-r--r-- 1 clamav clamav 4050 Jun 28 11:01 clamav-4d6166b710f63075
> > -rw-r--r-- 1 clamav clamav 3640966 Jun 9 16:49 clamav-651c96be267fc93e
> > -rw-r--r-- 1 clamav clamav 380351 Jun 28 08:00 daily.cvd
> > -rw-r--r-- 1 clamav clamav 4978654 Jun 9 18:00 main.cvd
> >
> >
> > $ cat /etc/passwd | grep clamav
> > clamav:x:100:101:Clamav database update user:/var/lib/clamav:/sbin/nologin
> >
> >
> > $ cat /etc/group | grep clamav
> > clamav:x:101:
>
> The search in /var/lib/clamav is probably a result of something running
> as that user, perhaps procmail. Does the clamav user get any mail?
Paul,
Good call. Yes indeed.
It would appear that clamav (the user) gets mail when there are problems
with the hourly database updates. For example, if there are DNS problems
or other issues with server access. I do see these coming from the root
account, which then get forwarded to my user account via the postfix
mapping. I had not paid attention, until now, regarding the multiple
e-mail addresses in the To: field.
After doing some searching, it turns out that this is configured
in /etc/crond./clamav-update.
In that file, mail is targeted (by default) to go to root, postmaster,
webmaster and clamav. Now that I have looked at the content
of /var/spool/mail/clamav, I do note that the mail is indeed sent to the
aforementioned users.
Of course, postmaster and webmaster do not exist on my system as users.
Also, in the file is the following:
## It is ok to execute it as root; freshclam drops privileges and becomes
## user 'clamav' as soon as possible
0 */3 * * * root /usr/share/clamav/freshclam-sleep
>From other sources, it would appear that the freshclam programs, even if
started as root, will setuid to clamav. This is configured
in /etc/freshclam.conf. The default is:
# By default when started freshclam drops privileges and switches to the
# "clamav" user. This directive allows you to change the database owner.
# Default: clamav (may depend on installation options)
#DatabaseOwner clamav
I could adjust the e-mail targets or other settings if you need me to.
I think the email targets are OK; you should just alias clamav,
webmaster, and postmaster (every mail system should have a postmaster)
to root, which in turn is aliased to you.
Paul.
8:27 a.m.
New subject: postfix, procmail and SELinux - No Go
On Thu, 2006-06-29 at 08:29 +0100, Paul Howarth wrote:
On Wed, 2006-06-28 at 22:15 -0500, Marc Schwartz wrote:
> On Wed, 2006-06-28 at 23:13 +0100, Paul Howarth wrote:
> > > >
> > > > That might be dontaudit-able. Is /var/lib/clamav any user's home
> > > > directory?
> > >
> > > The /var/lib/clamav tree appears to be owned by 'clamav', both
user and
> > > group:
> > >
> > > $ ls -l /var/lib
> > > total 264
> > > ...
> > > drwxr-xr-x 2 clamav clamav 4096 Jun 28 11:00 clamav
> > > ...
> > >
> > > ls -l /var/lib/clamav
> > > total 8832
> > > -rw-r--r-- 1 clamav clamav 4050 Jun 28 11:01 clamav-4d6166b710f63075
> > > -rw-r--r-- 1 clamav clamav 3640966 Jun 9 16:49 clamav-651c96be267fc93e
> > > -rw-r--r-- 1 clamav clamav 380351 Jun 28 08:00 daily.cvd
> > > -rw-r--r-- 1 clamav clamav 4978654 Jun 9 18:00 main.cvd
> > >
> > >
> > > $ cat /etc/passwd | grep clamav
> > > clamav:x:100:101:Clamav database update
user:/var/lib/clamav:/sbin/nologin
> > >
> > >
> > > $ cat /etc/group | grep clamav
> > > clamav:x:101:
> >
> > The search in /var/lib/clamav is probably a result of something running
> > as that user, perhaps procmail. Does the clamav user get any mail?
>
> Paul,
>
> Good call. Yes indeed.
>
> It would appear that clamav (the user) gets mail when there are problems
> with the hourly database updates. For example, if there are DNS problems
> or other issues with server access. I do see these coming from the root
> account, which then get forwarded to my user account via the postfix
> mapping. I had not paid attention, until now, regarding the multiple
> e-mail addresses in the To: field.
>
> After doing some searching, it turns out that this is configured
> in /etc/crond./clamav-update.
>
> In that file, mail is targeted (by default) to go to root, postmaster,
> webmaster and clamav. Now that I have looked at the content
> of /var/spool/mail/clamav, I do note that the mail is indeed sent to the
> aforementioned users.
>
> Of course, postmaster and webmaster do not exist on my system as users.
>
> Also, in the file is the following:
>
> ## It is ok to execute it as root; freshclam drops privileges and becomes
> ## user 'clamav' as soon as possible
> 0 */3 * * * root /usr/share/clamav/freshclam-sleep
>
> >From other sources, it would appear that the freshclam programs, even if
> started as root, will setuid to clamav. This is configured
> in /etc/freshclam.conf. The default is:
>
> # By default when started freshclam drops privileges and switches to the
> # "clamav" user. This directive allows you to change the database owner.
> # Default: clamav (may depend on installation options)
> #DatabaseOwner clamav
>
>
> I could adjust the e-mail targets or other settings if you need me to.
I think the email targets are OK; you should just alias clamav,
webmaster, and postmaster (every mail system should have a postmaster)
to root, which in turn is aliased to you.
Paul,
I aliased clamav to root. postmaster and webmaster were already aliased
to root.
I am also now in Enforcing mode.
We should probably give this a good 24 hours to run through the various
cycles of e-mails and cron jobs.
If anything comes up in the mean time, I'll post back.
Just for reference, current policies loaded:
amavis 1.0.4
clamav 1.0.1
dcc 1.0.0
myclamav 0.1.5
mydcc 0.1.8
mypostfix 0.1.0
mypyzor 0.2.3
myspamassassin 0.1.1
procmail 0.5.4
pyzor 1.0.1
razor 1.0.0
Thanks for all the help.
Marc
6:38 p.m.
New subject: postfix, procmail and SELinux - No Go
Paul,
I just got home and noted the following avc's which appear to be a
post-reboot scenario.
There are some that appear to be networking related, which may indeed be
associated with the kernel related reports. I have more than one network
profile, where I used one at home that has a fixed IP address behind a
router. At work, I use NM with DHCP. As I noted in a prior post, some
network things have been flaky with the new kernel.
Is this an indication that I should consider the 'updates testing'
initscripts update as referenced in other threads on the general lists?
Up until the reboot, there were no other avc's.
Note also what appears to be a double "//" in the path to the
razor-agent.log. Not sure where that comes from, as the mods that I
made in the config files are:
local.cf:
razor_config /etc/mail/spamassassin/razor/razor-agent.conf
razor-agent.conf :
razorhome = /etc/mail/spamassassin/razor/
The trailing '/' in the second file was there previously.
New avc's:
type=AVC msg=audit(1151607255.655:1577): avc: denied { signal } for pid=2283
comm="spamd" scontext=system_u:system_r:spamd_t:s0 t
context=system_u:system_r:dcc_client_t:s0 tclass=process
type=SYSCALL msg=audit(1151607255.655:1577): arch=40000003 syscall=37 success=no exit=-13
a0=780b a1=f a2=2b5b8c a3=90e7894 items=0 pid=2283 auid=4294967295 uid=0 gid=0 euid=500
suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd"
exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0
type=AVC msg=audit(1151620643.074:452): avc: denied { append } for pid=2312
comm="spamd" name="razor-agent.log" dev=hdc7 ino=1081 390
scontext=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file
type=SYSCALL msg=audit(1151620643.074:452): arch=40000003 syscall=5 success=no exit=-13
a0=b5c6ee0 a1=8441 a2=1b6 a3=8441 items=1 pi d=2312 auid=4294967295 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="spamd"
exe="/usr/bin/perl" subj=syst em_u:system_r:spamd_t:s0
type=CWD msg=audit(1151620643.074:452): cwd="/"
type=PATH msg=audit(1151620643.074:452): item=0
name="/etc/mail/spamassassin/razor//razor-agent.log" parent=1081385 dev=16:07
mode=0 40755 ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0
type=AVC msg=audit(1151620645.415:453): avc: denied { setgid } for pid=2410
comm="dccproc" capability=6 scontext=system_u:system_ r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=capability
type=SYSCALL msg=audit(1151620645.415:453): arch=40000003 syscall=210 success=yes exit=0
a0=ffffffff a1=0 a2=ffffffff a3=47fcfcc0 it ems=0 pid=2410 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="dccproc"
exe="/usr/local/bin /dccproc" subj=system_u:system_r:dcc_client_t:s0
type=AVC msg=audit(1151620795.471:481): avc: denied { use } for pid=5120
comm="dhclient" name="[10508]" dev=pipefs ino=10508 scon
text=user_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=fd
type=AVC msg=audit(1151620795.471:481): avc: denied { use } for pid=5120
comm="dhclient" name="[10508]" dev=pipefs ino=10508 scon
text=user_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=fd
type=SYSCALL msg=audit(1151620795.471:481): arch=40000003 syscall=11 success=yes exit=0
a0=99120f8 a1=993b580 a2=9912608 a3=993b5f0 items=2 pid=5120 auid=500 uid=0 gid=500 euid=0
suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) comm="dhclient"
exe="/sbin/dhcl ient" subj=user_u:system_r:dhcpc_t:s0
type=AVC_PATH msg=audit(1151620795.471:481): path="pipe:[10508]"
type=AVC_PATH msg=audit(1151620795.471:481): path="pipe:[10508]"
type=CWD msg=audit(1151620795.471:481): cwd="/etc/sysconfig/network-scripts"
type=PATH msg=audit(1151620795.471:481): item=0 name="/sbin/dhclient"
inode=3542818 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:dhcpc_exec_t:s0
type=PATH msg=audit(1151620795.471:481): 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
type=AVC msg=audit(1151620808.228:498): avc: denied { use } for pid=5217
comm="dhclient-script" name="[10508]" dev=pipefs ino=105 08
scontext=user_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255
tclass=fd
type=AVC msg=audit(1151620808.228:498): avc: denied { use } for pid=5217
comm="dhclient-script" name="[10508]" dev=pipefs ino=105 08
scontext=user_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255
tclass=fd
type=SYSCALL msg=audit(1151620808.228:498): arch=40000003 syscall=11 success=yes exit=0
a0=9fdff30 a1=a0044c8 a2=9fe1378 a3=a002498 items=3 pid=5217 auid=500 uid=0 gid=500 euid=0
suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) comm="dhclient-script"
exe="/bi n/bash" subj=user_u:system_r:dhcpc_t:s0
type=AVC_PATH msg=audit(1151620808.228:498): path="pipe:[10508]"
type=AVC_PATH msg=audit(1151620808.228:498): path="pipe:[10508]"
type=CWD msg=audit(1151620808.228:498): cwd="/etc/sysconfig/network-scripts"
type=PATH msg=audit(1151620808.228:498): item=0 name="/sbin/dhclient-script"
inode=3548518 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev =00:00
obj=system_u:object_r:dhcpc_exec_t:s0
type=PATH msg=audit(1151620808.228:498): item=1 name=(null) inode=1966191 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system _u:object_r:shell_exec_t:s0
type=PATH msg=audit(1151620808.228:498): item=2 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
Thanks,
Marc
8:19 a.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz wrote:
I just got home and noted the following avc's which appear to be
a
post-reboot scenario.
There are some that appear to be networking related, which may indeed be
associated with the kernel related reports. I have more than one network
profile, where I used one at home that has a fixed IP address behind a
router. At work, I use NM with DHCP. As I noted in a prior post, some
network things have been flaky with the new kernel.
Is this an indication that I should consider the 'updates testing'
initscripts update as referenced in other threads on the general lists?
Possibly; my understanding of the update is that it fixes the order of
assignment of network devices at boot time. This is useful to me for
instance, as I have a two-interface firewall, which doesn't work if it
boots with the internal and external interfaces the wrong way around.
Up until the reboot, there were no other avc's.
Note also what appears to be a double "//" in the path to the
razor-agent.log. Not sure where that comes from, as the mods that I
made in the config files are:
local.cf:
razor_config /etc/mail/spamassassin/razor/razor-agent.conf
razor-agent.conf :
razorhome = /etc/mail/spamassassin/razor/
The trailing '/' in the second file was there previously.
You could try it without the trailing slash and see what happens. Double
slashes aren't usually an issue though.
New avc's:
type=AVC msg=audit(1151607255.655:1577): avc: denied { signal } for pid=2283
comm="spamd" scontext=system_u:system_r:spamd_t:s0 t
context=system_u:system_r:dcc_client_t:s0 tclass=process
type=SYSCALL msg=audit(1151607255.655:1577): arch=40000003 syscall=37 success=no exit=-13
a0=780b a1=f a2=2b5b8c a3=90e7894 items=0 pid=2283 auid=4294967295 uid=0 gid=0 euid=500
suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd"
exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0
Spamassassin signalling dcc_client. I wonder if the "a1" value is the
signal number? If so, that's SIGTERM.
type=AVC msg=audit(1151620643.074:452): avc: denied { append } for
pid=2312 comm="spamd" name="razor-agent.log" dev=hdc7 ino=1081 390
scontext=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file
type=SYSCALL msg=audit(1151620643.074:452): arch=40000003 syscall=5 success=no exit=-13
a0=b5c6ee0 a1=8441 a2=1b6 a3=8441 items=1 pi d=2312 auid=4294967295 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="spamd"
exe="/usr/bin/perl" subj=syst em_u:system_r:spamd_t:s0
type=CWD msg=audit(1151620643.074:452): cwd="/"
type=PATH msg=audit(1151620643.074:452): item=0
name="/etc/mail/spamassassin/razor//razor-agent.log" parent=1081385 dev=16:07
mode=0 40755 ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0
Trying to append to /etc/mail/spamassassin/razor/razor-agent.log, which
of course is etc_mail_t. Is there any way to persuade razor to put this
log in /var/log instead?
type=AVC msg=audit(1151620645.415:453): avc: denied { setgid } for
pid=2410 comm="dccproc" capability=6 scontext=system_u:system_ r:dcc_client_t:s0
tcontext=system_u:system_r:dcc_client_t:s0 tclass=capability
type=SYSCALL msg=audit(1151620645.415:453): arch=40000003 syscall=210 success=yes exit=0
a0=ffffffff a1=0 a2=ffffffff a3=47fcfcc0 it ems=0 pid=2410 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="dccproc"
exe="/usr/local/bin /dccproc" subj=system_u:system_r:dcc_client_t:s0
dccproc changing its group ID.
type=AVC msg=audit(1151620795.471:481): avc: denied { use } for
pid=5120 comm="dhclient" name="[10508]" dev=pipefs ino=10508 scon
text=user_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=fd
type=AVC msg=audit(1151620795.471:481): avc: denied { use } for pid=5120
comm="dhclient" name="[10508]" dev=pipefs ino=10508 scon
text=user_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=fd
type=SYSCALL msg=audit(1151620795.471:481): arch=40000003 syscall=11 success=yes exit=0
a0=99120f8 a1=993b580 a2=9912608 a3=993b5f0 items=2 pid=5120 auid=500 uid=0 gid=500 euid=0
suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) comm="dhclient"
exe="/sbin/dhcl ient" subj=user_u:system_r:dhcpc_t:s0
type=AVC_PATH msg=audit(1151620795.471:481): path="pipe:[10508]"
type=AVC_PATH msg=audit(1151620795.471:481): path="pipe:[10508]"
type=CWD msg=audit(1151620795.471:481): cwd="/etc/sysconfig/network-scripts"
type=PATH msg=audit(1151620795.471:481): item=0 name="/sbin/dhclient"
inode=3542818 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:dhcpc_exec_t:s0
type=PATH msg=audit(1151620795.471:481): 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
type=AVC msg=audit(1151620808.228:498): avc: denied { use } for pid=5217
comm="dhclient-script" name="[10508]" dev=pipefs ino=105 08
scontext=user_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255
tclass=fd
type=AVC msg=audit(1151620808.228:498): avc: denied { use } for pid=5217
comm="dhclient-script" name="[10508]" dev=pipefs ino=105 08
scontext=user_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255
tclass=fd
type=SYSCALL msg=audit(1151620808.228:498): arch=40000003 syscall=11 success=yes exit=0
a0=9fdff30 a1=a0044c8 a2=9fe1378 a3=a002498 items=3 pid=5217 auid=500 uid=0 gid=500 euid=0
suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) comm="dhclient-script"
exe="/bi n/bash" subj=user_u:system_r:dhcpc_t:s0
type=AVC_PATH msg=audit(1151620808.228:498): path="pipe:[10508]"
type=AVC_PATH msg=audit(1151620808.228:498): path="pipe:[10508]"
type=CWD msg=audit(1151620808.228:498): cwd="/etc/sysconfig/network-scripts"
type=PATH msg=audit(1151620808.228:498): item=0 name="/sbin/dhclient-script"
inode=3548518 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev =00:00
obj=system_u:object_r:dhcpc_exec_t:s0
type=PATH msg=audit(1151620808.228:498): item=1 name=(null) inode=1966191 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system _u:object_r:shell_exec_t:s0
type=PATH msg=audit(1151620808.228:498): item=2 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
These appear to be unrelated network issues.
Could be allowed by having
xserver_use_xdm_fds(dhcpc_t)
in the sysnetwork policy but I'm not sure what's happening there and if
that would be the right thing to do.
Updated policy:
::::::::::::::
mydcc.if
::::::::::::::
########################################
## <summary>
## Signal the dcc client
## </summary>
## <param name="domain">
## <summary>
## The type of the process performing this action.
## </summary>
## </param>
#
interface(`dcc_signal_client',`
gen_require(`
type dcc_client_t;
')
allow $1 dcc_client_t:process signal;
')
::::::::::::::
myspamassassin.te
::::::::::::::
policy_module(myspamassassin, 0.1.2)
require {
type spamd_t;
}
# This will be included in FC5 policy when dcc module is included
dcc_domtrans_client(spamd_t)
# This is already supposed to be included but doesn't seem to be working
pyzor_domtrans(spamd_t)
# This will be included in FC5 policy when razor module is included
razor_domtrans(spamd_t)
# Signal the dcc client (SIGTERM is used?)
dcc_signal_client(spamd_t)
::::::::::::::
mydcc.te
::::::::::::::
policy_module(mydcc, 0.1.9)
# ==================================================
# Declarations
# ==================================================
require {
type dcc_client_t;
}
# ==================================================
# DCC client local policy
# ==================================================
allow dcc_client_t self:capability setgid;
allow dcc_client_t self:netlink_route_socket r_netlink_socket_perms;
corenet_udp_bind_inaddr_any_node(dcc_client_t)
# dcc_client probably doesn't need to be able to read /proc/meminfo
kernel_dontaudit_list_proc(dcc_client_t)
kernel_dontaudit_read_system_state(dcc_client_t)
spamassassin_read_spamd_tmp_files(dcc_client_t)
Paul.
12:38 p.m.
New subject: postfix, procmail and SELinux - No Go
On Fri, 2006-06-30 at 14:19 +0100, Paul Howarth wrote:
Marc Schwartz wrote:
> I just got home and noted the following avc's which appear to be a
> post-reboot scenario.
>
> There are some that appear to be networking related, which may indeed be
> associated with the kernel related reports. I have more than one network
> profile, where I used one at home that has a fixed IP address behind a
> router. At work, I use NM with DHCP. As I noted in a prior post, some
> network things have been flaky with the new kernel.
>
> Is this an indication that I should consider the 'updates testing'
> initscripts update as referenced in other threads on the general lists?
Possibly; my understanding of the update is that it fixes the order of
assignment of network devices at boot time. This is useful to me for
instance, as I have a two-interface firewall, which doesn't work if it
boots with the internal and external interfaces the wrong way around.
Yeah, eth0 (should be a hardwired connection) and eth1 (which should be
a wireless connection) have been frequently switching back and forth.
Under the former kernel, the wireless was wlan0 when using ndiswrapper.
OK. I updated the rpm.
I have not fully tested the updated scripts, but what was interesting is
that I had modified rc.sysinit to handle my LUKS partitions during boot,
but the update (which includes the default file) did not overwrite my
modified version. I presume that there may be an entry in the spec file
for the rpm to check for this, though I have not taken the time to
review it.
> Up until the reboot, there were no other avc's.
>
> Note also what appears to be a double "//" in the path to the
> razor-agent.log. Not sure where that comes from, as the mods that I
> made in the config files are:
>
> local.cf:
> razor_config /etc/mail/spamassassin/razor/razor-agent.conf
>
> razor-agent.conf :
> razorhome = /etc/mail/spamassassin/razor/
>
> The trailing '/' in the second file was there previously.
You could try it without the trailing slash and see what happens. Double
slashes aren't usually an issue though.
I'll leave it for now and see if it continues to show.
> New avc's:
>
> type=AVC msg=audit(1151607255.655:1577): avc: denied { signal } for pid=2283
comm="spamd" scontext=system_u:system_r:spamd_t:s0 t
context=system_u:system_r:dcc_client_t:s0 tclass=process
> type=SYSCALL msg=audit(1151607255.655:1577): arch=40000003 syscall=37 success=no
exit=-13 a0=780b a1=f a2=2b5b8c a3=90e7894 items=0 pid=2283 auid=4294967295 uid=0 gid=0
euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd"
exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0
Spamassassin signalling dcc_client. I wonder if the "a1" value is the
signal number? If so, that's SIGTERM.
> type=AVC msg=audit(1151620643.074:452): avc: denied { append } for pid=2312
comm="spamd" name="razor-agent.log" dev=hdc7 ino=1081 390
scontext=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:etc_mail_t:s0 tclass=file
> type=SYSCALL msg=audit(1151620643.074:452): arch=40000003 syscall=5 success=no
exit=-13 a0=b5c6ee0 a1=8441 a2=1b6 a3=8441 items=1 pi d=2312 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="spamd"
exe="/usr/bin/perl" subj=syst em_u:system_r:spamd_t:s0
> type=CWD msg=audit(1151620643.074:452): cwd="/"
> type=PATH msg=audit(1151620643.074:452): item=0
name="/etc/mail/spamassassin/razor//razor-agent.log" parent=1081385 dev=16:07
mode=0 40755 ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0
Trying to append to /etc/mail/spamassassin/razor/razor-agent.log, which
of course is etc_mail_t. Is there any way to persuade razor to put this
log in /var/log instead?
Yep. Done. I made a change in:
/etc/mail/spamassassin/razor/razor-agent.conf
Now with a line:
logfile = /var/log/razor-agent.log
which was just
logfile = razor-agent.log
Specifying the full path overrides the normal home dir for razor files.
After a spamassassin service restart, the log file is now:
ls -lZ /var/log/razor-agent.log
-rw-r--r-- root root user_u:object_r:var_log_t /var/log/razor-agent.log
Note the change in context below.
> type=AVC msg=audit(1151620645.415:453): avc: denied { setgid }
for pid=2410 comm="dccproc" capability=6 scontext=system_u:system_
r:dcc_client_t:s0 tcontext=system_u:system_r:dcc_client_t:s0 tclass=capability
> type=SYSCALL msg=audit(1151620645.415:453): arch=40000003 syscall=210 success=yes
exit=0 a0=ffffffff a1=0 a2=ffffffff a3=47fcfcc0 it ems=0 pid=2410 auid=4294967295 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="dccproc"
exe="/usr/local/bin /dccproc" subj=system_u:system_r:dcc_client_t:s0
dccproc changing its group ID.
> type=AVC msg=audit(1151620795.471:481): avc: denied { use } for pid=5120
comm="dhclient" name="[10508]" dev=pipefs ino=10508 scon
text=user_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=fd
> type=AVC msg=audit(1151620795.471:481): avc: denied { use } for pid=5120
comm="dhclient" name="[10508]" dev=pipefs ino=10508 scon
text=user_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=fd
> type=SYSCALL msg=audit(1151620795.471:481): arch=40000003 syscall=11 success=yes
exit=0 a0=99120f8 a1=993b580 a2=9912608 a3=993b5f0 items=2 pid=5120 auid=500 uid=0 gid=500
euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) comm="dhclient"
exe="/sbin/dhcl ient" subj=user_u:system_r:dhcpc_t:s0
> type=AVC_PATH msg=audit(1151620795.471:481): path="pipe:[10508]"
> type=AVC_PATH msg=audit(1151620795.471:481): path="pipe:[10508]"
> type=CWD msg=audit(1151620795.471:481):
cwd="/etc/sysconfig/network-scripts"
> type=PATH msg=audit(1151620795.471:481): item=0 name="/sbin/dhclient"
inode=3542818 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:dhcpc_exec_t:s0
> type=PATH msg=audit(1151620795.471:481): 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
> type=AVC msg=audit(1151620808.228:498): avc: denied { use } for pid=5217
comm="dhclient-script" name="[10508]" dev=pipefs ino=105 08
scontext=user_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255
tclass=fd
> type=AVC msg=audit(1151620808.228:498): avc: denied { use } for pid=5217
comm="dhclient-script" name="[10508]" dev=pipefs ino=105 08
scontext=user_u:system_r:dhcpc_t:s0 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255
tclass=fd
> type=SYSCALL msg=audit(1151620808.228:498): arch=40000003 syscall=11 success=yes
exit=0 a0=9fdff30 a1=a0044c8 a2=9fe1378 a3=a002498 items=3 pid=5217 auid=500 uid=0 gid=500
euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none)
comm="dhclient-script" exe="/bi n/bash"
subj=user_u:system_r:dhcpc_t:s0
> type=AVC_PATH msg=audit(1151620808.228:498): path="pipe:[10508]"
> type=AVC_PATH msg=audit(1151620808.228:498): path="pipe:[10508]"
> type=CWD msg=audit(1151620808.228:498):
cwd="/etc/sysconfig/network-scripts"
> type=PATH msg=audit(1151620808.228:498): item=0
name="/sbin/dhclient-script" inode=3548518 dev=16:07 mode=0100755 ouid=0 ogid=0
rdev =00:00 obj=system_u:object_r:dhcpc_exec_t:s0
> type=PATH msg=audit(1151620808.228:498): item=1 name=(null) inode=1966191 dev=16:07
mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system _u:object_r:shell_exec_t:s0
> type=PATH msg=audit(1151620808.228:498): item=2 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
These appear to be unrelated network issues.
Could be allowed by having
xserver_use_xdm_fds(dhcpc_t)
in the sysnetwork policy but I'm not sure what's happening there and if
that would be the right thing to do.
Updated policy:
::::::::::::::
mydcc.if
::::::::::::::
########################################
## <summary>
## Signal the dcc client
## </summary>
## <param name="domain">
## <summary>
## The type of the process performing this action.
## </summary>
## </param>
#
interface(`dcc_signal_client',`
gen_require(`
type dcc_client_t;
')
allow $1 dcc_client_t:process signal;
')
::::::::::::::
myspamassassin.te
::::::::::::::
policy_module(myspamassassin, 0.1.2)
require {
type spamd_t;
}
# This will be included in FC5 policy when dcc module is included
dcc_domtrans_client(spamd_t)
# This is already supposed to be included but doesn't seem to be working
pyzor_domtrans(spamd_t)
# This will be included in FC5 policy when razor module is included
razor_domtrans(spamd_t)
# Signal the dcc client (SIGTERM is used?)
dcc_signal_client(spamd_t)
::::::::::::::
mydcc.te
::::::::::::::
policy_module(mydcc, 0.1.9)
# ==================================================
# Declarations
# ==================================================
require {
type dcc_client_t;
}
# ==================================================
# DCC client local policy
# ==================================================
allow dcc_client_t self:capability setgid;
allow dcc_client_t self:netlink_route_socket r_netlink_socket_perms;
corenet_udp_bind_inaddr_any_node(dcc_client_t)
# dcc_client probably doesn't need to be able to read /proc/meminfo
kernel_dontaudit_list_proc(dcc_client_t)
kernel_dontaudit_read_system_state(dcc_client_t)
spamassassin_read_spamd_tmp_files(dcc_client_t)
Policies updated:
amavis 1.0.4
clamav 1.0.1
dcc 1.0.0
myclamav 0.1.5
mydcc 0.1.9
mypostfix 0.1.0
mypyzor 0.2.3
myspamassassin 0.1.2
procmail 0.5.4
pyzor 1.0.1
razor 1.0.0
I also ran a restorecon on /var/log/razor-agent.log, which is now:
ls -lZ /var/log/razor-agent.log
-rw-r--r-- root root system_u:object_r:razor_log_t /var/log/razor-agent.log
New avc's so far, after manually running all relevant cron jobs and a
re-boot:
type=AVC msg=audit(1151774266.909:5311): avc: denied { search } for pid=11652
comm="spamd" name="log" dev=dm-1 ino=73126
scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir
type=SYSCALL msg=audit(1151774266.909:5311): arch=40000003 syscall=5 success=no exit=-13
a0=b1676f0 a1=8441 a2=1b6 a3=8441 items=1 pid=11652 auid=500 uid=0 gid=0 euid=500 suid=0
fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd"
exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0
type=CWD msg=audit(1151774266.909:5311): cwd="/"
type=PATH msg=audit(1151774266.909:5311): item=0 name="/var/log/razor-agent.log"
obj=user_u:object_r:etc_mail_t:s0
type=AVC msg=audit(1151774267.629:5312): avc: denied { read } for pid=18080
comm="dccproc" name=".fonts.cache-2" dev=hdc7 ino=427877
scontext=system_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:user_home_t:s0
tclass=file
type=SYSCALL msg=audit(1151774267.629:5312): arch=40000003 syscall=11 success=yes exit=0
a0=b0c96b8 a1=a432fd8 a2=b18feb8 a3=bfce606c items=2 pid=18080 auid=500 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(1151774267.629:5312):
path="/root/.rh-fontconfig/.fonts.cache-2"
type=CWD msg=audit(1151774267.629:5312): cwd="/"
type=PATH msg=audit(1151774267.629:5312): item=0 name="/usr/local/bin/dccproc"
inode=3118478 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(1151774267.629:5312): 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
Thanks,
Marc
11:53 a.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz wrote:
On Fri, 2006-06-30 at 14:19 +0100, Paul Howarth wrote:
> Marc Schwartz wrote:
>> I just got home and noted the following avc's which appear to be a
>> post-reboot scenario.
>>
>> There are some that appear to be networking related, which may indeed be
>> associated with the kernel related reports. I have more than one network
>> profile, where I used one at home that has a fixed IP address behind a
>> router. At work, I use NM with DHCP. As I noted in a prior post, some
>> network things have been flaky with the new kernel.
>>
>> Is this an indication that I should consider the 'updates testing'
>> initscripts update as referenced in other threads on the general lists?
> Possibly; my understanding of the update is that it fixes the order of
> assignment of network devices at boot time. This is useful to me for
> instance, as I have a two-interface firewall, which doesn't work if it
> boots with the internal and external interfaces the wrong way around.
Yeah, eth0 (should be a hardwired connection) and eth1 (which should be
a wireless connection) have been frequently switching back and forth.
Under the former kernel, the wireless was wlan0 when using ndiswrapper.
OK. I updated the rpm.
I have not fully tested the updated scripts, but what was interesting is
that I had modified rc.sysinit to handle my LUKS partitions during boot,
but the update (which includes the default file) did not overwrite my
modified version. I presume that there may be an entry in the spec file
for the rpm to check for this, though I have not taken the time to
review it.
It may be that rc.sysinit was unchanged in the new package version, so
your local changes would be retained. Only if there was a change to
rc.sysinit would you get a .rpmnew or .rpmsave file.
>> type=AVC msg=audit(1151620643.074:452): avc: denied {
append } for pid=2312 comm="spamd" name="razor-agent.log" dev=hdc7
ino=1081 390 scontext=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:etc_mail_t:s0
tclass=file
>> type=SYSCALL msg=audit(1151620643.074:452): arch=40000003 syscall=5 success=no
exit=-13 a0=b5c6ee0 a1=8441 a2=1b6 a3=8441 items=1 pi d=2312 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="spamd"
exe="/usr/bin/perl" subj=syst em_u:system_r:spamd_t:s0
>> type=CWD msg=audit(1151620643.074:452): cwd="/"
>> type=PATH msg=audit(1151620643.074:452): item=0
name="/etc/mail/spamassassin/razor//razor-agent.log" parent=1081385 dev=16:07
mode=0 40755 ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0
> Trying to append to /etc/mail/spamassassin/razor/razor-agent.log, which
> of course is etc_mail_t. Is there any way to persuade razor to put this
> log in /var/log instead?
Yep. Done. I made a change in:
/etc/mail/spamassassin/razor/razor-agent.conf
Now with a line:
logfile = /var/log/razor-agent.log
which was just
logfile = razor-agent.log
Specifying the full path overrides the normal home dir for razor files.
After a spamassassin service restart, the log file is now:
ls -lZ /var/log/razor-agent.log
-rw-r--r-- root root user_u:object_r:var_log_t /var/log/razor-agent.log
Note the change in context below.
Not sure what to do about this. I would like the file to be created with
the right context really. Unfortunately it is a process in the spamd_t
domain that is creating this file rather than one in the razor_t domain.
Can you check that /usr/bin/razor* have context type razor_exec_t?
If they don't, try:
# restorecon -v /usr/bin/razor*
Policies updated:
amavis 1.0.4
clamav 1.0.1
dcc 1.0.0
myclamav 0.1.5
mydcc 0.1.9
mypostfix 0.1.0
mypyzor 0.2.3
myspamassassin 0.1.2
procmail 0.5.4
pyzor 1.0.1
razor 1.0.0
I also ran a restorecon on /var/log/razor-agent.log, which is now:
ls -lZ /var/log/razor-agent.log
-rw-r--r-- root root system_u:object_r:razor_log_t /var/log/razor-agent.log
New avc's so far, after manually running all relevant cron jobs and a
re-boot:
type=AVC msg=audit(1151774266.909:5311): avc: denied { search } for pid=11652
comm="spamd" name="log" dev=dm-1 ino=73126
scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir
type=SYSCALL msg=audit(1151774266.909:5311): arch=40000003 syscall=5 success=no exit=-13
a0=b1676f0 a1=8441 a2=1b6 a3=8441 items=1 pid=11652 auid=500 uid=0 gid=0 euid=500 suid=0
fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd"
exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0
type=CWD msg=audit(1151774266.909:5311): cwd="/"
type=PATH msg=audit(1151774266.909:5311): item=0
name="/var/log/razor-agent.log" obj=user_u:object_r:etc_mail_t:s0
spamd_t trying to write the razor log. I think this should be razor_t
doing this so we'll leave it for now.
type=AVC msg=audit(1151774267.629:5312): avc: denied { read } for
pid=18080 comm="dccproc" name=".fonts.cache-2" dev=hdc7 ino=427877
scontext=system_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:user_home_t:s0
tclass=file
type=SYSCALL msg=audit(1151774267.629:5312): arch=40000003 syscall=11 success=yes exit=0
a0=b0c96b8 a1=a432fd8 a2=b18feb8 a3=bfce606c items=2 pid=18080 auid=500 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(1151774267.629:5312):
path="/root/.rh-fontconfig/.fonts.cache-2"
type=CWD msg=audit(1151774267.629:5312): cwd="/"
type=PATH msg=audit(1151774267.629:5312): item=0 name="/usr/local/bin/dccproc"
inode=3118478 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(1151774267.629:5312): 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
Any thoughts on why dccproc might be wanting to read
/root/.rh-fontconfig/.fonts.cache-2?
Paul.
1:58 p.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-07-04 at 17:53 +0100, Paul Howarth wrote:
Marc Schwartz wrote:
> On Fri, 2006-06-30 at 14:19 +0100, Paul Howarth wrote:
>> Marc Schwartz wrote:
>>> I just got home and noted the following avc's which appear to be a
>>> post-reboot scenario.
>>>
>>> There are some that appear to be networking related, which may indeed be
>>> associated with the kernel related reports. I have more than one network
>>> profile, where I used one at home that has a fixed IP address behind a
>>> router. At work, I use NM with DHCP. As I noted in a prior post, some
>>> network things have been flaky with the new kernel.
>>>
>>> Is this an indication that I should consider the 'updates testing'
>>> initscripts update as referenced in other threads on the general lists?
>> Possibly; my understanding of the update is that it fixes the order of
>> assignment of network devices at boot time. This is useful to me for
>> instance, as I have a two-interface firewall, which doesn't work if it
>> boots with the internal and external interfaces the wrong way around.
>
> Yeah, eth0 (should be a hardwired connection) and eth1 (which should be
> a wireless connection) have been frequently switching back and forth.
>
> Under the former kernel, the wireless was wlan0 when using ndiswrapper.
>
> OK. I updated the rpm.
>
> I have not fully tested the updated scripts, but what was interesting is
> that I had modified rc.sysinit to handle my LUKS partitions during boot,
> but the update (which includes the default file) did not overwrite my
> modified version. I presume that there may be an entry in the spec file
> for the rpm to check for this, though I have not taken the time to
> review it.
It may be that rc.sysinit was unchanged in the new package version, so
your local changes would be retained. Only if there was a change to
rc.sysinit would you get a .rpmnew or .rpmsave file.
OK. Thanks.
Yeah, according to a check (using cpio, etc. to extract the file) it was
unchanged relative to the prior original version.
I wanted to be sure on this, since it could affect my ability to unlock
the LUKS protected partitions on boot.
>>> type=AVC msg=audit(1151620643.074:452): avc: denied {
append } for pid=2312 comm="spamd" name="razor-agent.log" dev=hdc7
ino=1081 390 scontext=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:etc_mail_t:s0
tclass=file
>>> type=SYSCALL msg=audit(1151620643.074:452): arch=40000003 syscall=5
success=no exit=-13 a0=b5c6ee0 a1=8441 a2=1b6 a3=8441 items=1 pi d=2312 auid=4294967295
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="spamd"
exe="/usr/bin/perl" subj=syst em_u:system_r:spamd_t:s0
>>> type=CWD msg=audit(1151620643.074:452): cwd="/"
>>> type=PATH msg=audit(1151620643.074:452): item=0
name="/etc/mail/spamassassin/razor//razor-agent.log" parent=1081385 dev=16:07
mode=0 40755 ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0
>> Trying to append to /etc/mail/spamassassin/razor/razor-agent.log, which
>> of course is etc_mail_t. Is there any way to persuade razor to put this
>> log in /var/log instead?
>
> Yep. Done. I made a change in:
>
> /etc/mail/spamassassin/razor/razor-agent.conf
>
> Now with a line:
>
> logfile = /var/log/razor-agent.log
>
> which was just
>
> logfile = razor-agent.log
>
> Specifying the full path overrides the normal home dir for razor files.
>
> After a spamassassin service restart, the log file is now:
>
> ls -lZ /var/log/razor-agent.log
> -rw-r--r-- root root user_u:object_r:var_log_t /var/log/razor-agent.log
>
> Note the change in context below.
Not sure what to do about this. I would like the file to be created with
the right context really. Unfortunately it is a process in the spamd_t
domain that is creating this file rather than one in the razor_t domain.
Can you check that /usr/bin/razor* have context type razor_exec_t?
Currently:
ls -lZ /usr/bin/razor*
-rwxr-xr-x root root system_u:object_r:razor_exec_t /usr/bin/razor-admin
-rwxr-xr-x root root system_u:object_r:razor_exec_t /usr/bin/razor-check
-rwxr-xr-x root root system_u:object_r:razor_exec_t /usr/bin/razor-client
-rwxr-xr-x root root system_u:object_r:razor_exec_t /usr/bin/razor-report
If they don't, try:
# restorecon -v /usr/bin/razor*
> Policies updated:
>
> amavis 1.0.4
> clamav 1.0.1
> dcc 1.0.0
> myclamav 0.1.5
> mydcc 0.1.9
> mypostfix 0.1.0
> mypyzor 0.2.3
> myspamassassin 0.1.2
> procmail 0.5.4
> pyzor 1.0.1
> razor 1.0.0
>
> I also ran a restorecon on /var/log/razor-agent.log, which is now:
>
> ls -lZ /var/log/razor-agent.log
> -rw-r--r-- root root system_u:object_r:razor_log_t /var/log/razor-agent.log
>
> New avc's so far, after manually running all relevant cron jobs and a
> re-boot:
>
> type=AVC msg=audit(1151774266.909:5311): avc: denied { search } for pid=11652
comm="spamd" name="log" dev=dm-1 ino=73126
scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir
> type=SYSCALL msg=audit(1151774266.909:5311): arch=40000003 syscall=5 success=no
exit=-13 a0=b1676f0 a1=8441 a2=1b6 a3=8441 items=1 pid=11652 auid=500 uid=0 gid=0 euid=500
suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd"
exe="/usr/bin/perl" subj=system_u:system_r:spamd_t:s0
> type=CWD msg=audit(1151774266.909:5311): cwd="/"
> type=PATH msg=audit(1151774266.909:5311): item=0
name="/var/log/razor-agent.log" obj=user_u:object_r:etc_mail_t:s0
spamd_t trying to write the razor log. I think this should be razor_t
doing this so we'll leave it for now.
> type=AVC msg=audit(1151774267.629:5312): avc: denied { read } for pid=18080
comm="dccproc" name=".fonts.cache-2" dev=hdc7 ino=427877
scontext=system_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:user_home_t:s0
tclass=file
> type=SYSCALL msg=audit(1151774267.629:5312): arch=40000003 syscall=11 success=yes
exit=0 a0=b0c96b8 a1=a432fd8 a2=b18feb8 a3=bfce606c items=2 pid=18080 auid=500 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(1151774267.629:5312):
path="/root/.rh-fontconfig/.fonts.cache-2"
> type=CWD msg=audit(1151774267.629:5312): cwd="/"
> type=PATH msg=audit(1151774267.629:5312): item=0
name="/usr/local/bin/dccproc" inode=3118478 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(1151774267.629:5312): 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
Any thoughts on why dccproc might be wanting to read
/root/.rh-fontconfig/.fonts.cache-2?
No definitive answer.
Checking the dcc source code tree using grep, the only references to
'font' are in the cgi-bin files (common and common.in) and then in the
HTML files (FAQ.HTML and INSTALL.HTML).
Thanks,
Marc
12:14 p.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz (via MN) wrote:
>>>> type=AVC msg=audit(1151620643.074:452): avc: denied
{ append } for pid=2312 comm="spamd" name="razor-agent.log" dev=hdc7
ino=1081 390 scontext=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:etc_mail_t:s0
tclass=file
>>>> type=SYSCALL msg=audit(1151620643.074:452): arch=40000003 syscall=5
success=no exit=-13 a0=b5c6ee0 a1=8441 a2=1b6 a3=8441 items=1 pi d=2312 auid=4294967295
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="spamd"
exe="/usr/bin/perl" subj=syst em_u:system_r:spamd_t:s0
>>>> type=CWD msg=audit(1151620643.074:452): cwd="/"
>>>> type=PATH msg=audit(1151620643.074:452): item=0
name="/etc/mail/spamassassin/razor//razor-agent.log" parent=1081385 dev=16:07
mode=0 40755 ouid=0 ogid=0 rdev=00:00 obj=user_u:object_r:etc_mail_t:s0
>>> Trying to append to /etc/mail/spamassassin/razor/razor-agent.log, which
>>> of course is etc_mail_t. Is there any way to persuade razor to put this
>>> log in /var/log instead?
>> Yep. Done. I made a change in:
>>
>> /etc/mail/spamassassin/razor/razor-agent.conf
>>
>> Now with a line:
>>
>> logfile = /var/log/razor-agent.log
>>
>> which was just
>>
>> logfile = razor-agent.log
>>
>> Specifying the full path overrides the normal home dir for razor files.
>>
>> After a spamassassin service restart, the log file is now:
>>
>> ls -lZ /var/log/razor-agent.log
>> -rw-r--r-- root root user_u:object_r:var_log_t /var/log/razor-agent.log
>>
>> Note the change in context below.
> Not sure what to do about this. I would like the file to be created with
> the right context really. Unfortunately it is a process in the spamd_t
> domain that is creating this file rather than one in the razor_t domain.
I think I've got to the bottom of this now. I actually installed
perl-Razor-Agent myself (I'm using sendmail but that doesn't really
matter) to figure out what was happening.
razor, like spamassassin, is written in perl. This allows spamassassin
to call razor directly by simply using the razor perl modules rather
than the razor client "binaries" in /usr/bin. Thus spamassassin runs a
razor client in its own domain, spamd_t. There is in fact no need for a
domain transition from spamd_t to razor_t.
Now to get rid of the AVCs. Please update to the policy modules included
below. Then:
# mkdir /var/log/spamassassin
# restorecon -v /var/log/spamassassin
Edit /etc/mail/spamassassin/razor/razor-agent.conf and set:
logfile = /var/log/spamassassin/razor-agent.log
Then restart spamassassin.
> Any thoughts on why dccproc might be wanting to read
> /root/.rh-fontconfig/.fonts.cache-2?
No definitive answer.
Checking the dcc source code tree using grep, the only references to
'font' are in the cgi-bin files (common and common.in) and then in the
HTML files (FAQ.HTML and INSTALL.HTML).
I think this is probably a leaked file descriptor. I don't know where
the leak is or what to do about it though.
::::::::::::::
mypostfix.te
::::::::::::::
policy_module(mypostfix, 0.1.1)
require {
type postfix_master_t;
};
# Postfix master process looking for its man pages so that it can refer
# to them in error messages
# (e.g. look at the documentation at X to help solve problem Y)
miscfiles_read_man_pages(postfix_master_t)
::::::::::::::
myspamassassin.fc (all one long line)
::::::::::::::
/var/log/spamassassin(/.*)?
gen_context(system_u:object_r:spamd_log_t,s0)
::::::::::::::
myspamassassin.te
::::::::::::::
policy_module(myspamassassin, 0.1.4)
require {
type spamd_t;
}
type spamd_log_t;
logging_log_file(spamd_log_t)
# THESE ALL APPEAR TO BE IN selinux-policy-2.2.47-3.fc5
#
# This will be included in FC5 policy when dcc module is included
#dcc_domtrans_client(spamd_t)
#
# This is already supposed to be included but doesn't seem to be working
#pyzor_domtrans(spamd_t)
# Signal the dcc client (SIGTERM is used?)
dcc_signal_client(spamd_t)
# Use log files
allow spamd_t spamd_log_t:file create_file_perms;
allow spamd_t spamd_log_t:dir rw_dir_perms;
logging_log_filetrans(spamd_t,spamd_log_t,{ file dir })
Paul.
8:58 a.m.
New subject: postfix, procmail and SELinux - No Go
On Fri, 2006-07-14 at 18:14 +0100, Paul Howarth wrote:
<snip>
I think I've got to the bottom of this now. I actually installed
perl-Razor-Agent myself (I'm using sendmail but that doesn't really
matter) to figure out what was happening.
razor, like spamassassin, is written in perl. This allows spamassassin
to call razor directly by simply using the razor perl modules rather
than the razor client "binaries" in /usr/bin. Thus spamassassin runs a
razor client in its own domain, spamd_t. There is in fact no need for a
domain transition from spamd_t to razor_t.
Now to get rid of the AVCs. Please update to the policy modules included
below. Then:
# mkdir /var/log/spamassassin
# restorecon -v /var/log/spamassassin
Edit /etc/mail/spamassassin/razor/razor-agent.conf and set:
logfile = /var/log/spamassassin/razor-agent.log
Then restart spamassassin.
Thanks Paul. I appreciate your persistence with this.
All done.
>> Any thoughts on why dccproc might be wanting to read
>> /root/.rh-fontconfig/.fonts.cache-2?
>
> No definitive answer.
>
> Checking the dcc source code tree using grep, the only references to
> 'font' are in the cgi-bin files (common and common.in) and then in the
> HTML files (FAQ.HTML and INSTALL.HTML).
I think this is probably a leaked file descriptor. I don't know where
the leak is or what to do about it though.
<snip of policies>
Latest avc's below, subsequent to the updates and reboots. I have tried
to remove a lot of the dups. If you need more info, let me know.
Marc
type=AVC msg=audit(1153023605.343:2448): avc: denied { getattr } for pid=11448
comm="spamd" name="dccproc" dev=hdc7 ino=1245188 s
context=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_exec_t:s0
tclass=file
type=SYSCALL msg=audit(1153023605.343:2448): arch=40000003 syscall=195 success=no exit=-13
a0=999da10 a1=95f30c8 a2=4891eff4 a3=999d a10 items=1 pid=11448 auid=500 uid=0 gid=0
euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd"
exe="/usr/bin /perl" subj=system_u:system_r:spamd_t:s0
type=AVC_PATH msg=audit(1153023605.343:2448): path="/usr/local/bin/dccproc"
type=CWD msg=audit(1153023605.343:2448): cwd="/"
type=PATH msg=audit(1153023605.343:2448): item=0 name="/usr/local/bin/dccproc"
inode=1245188 dev=16:07 mode=0104555 ouid=0 ogid=1 rd ev=00:00
obj=system_u:object_r:dcc_client_exec_t:s0
type=AVC msg=audit(1153023963.916:2467): avc: denied { getattr } for pid=11448
comm="spamd" name="dccproc" dev=hdc7 ino=1245188 s
context=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_exec_t:s0
tclass=file
type=SYSCALL msg=audit(1153023963.916:2467): arch=40000003 syscall=195 success=no exit=-13
a0=999da10 a1=95f30c8 a2=4891eff4 a3=999d a10 items=1 pid=11448 auid=500 uid=0 gid=0
euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd"
exe="/usr/bin /perl" subj=system_u:system_r:spamd_t:s0
type=AVC_PATH msg=audit(1153023963.916:2467): path="/usr/local/bin/dccproc"
type=CWD msg=audit(1153023963.916:2467): cwd="/"
type=PATH msg=audit(1153024204.542:2488): item=0 name="/usr/local/bin/dccproc"
inode=1245188 dev=16:07 mode=0104555 ouid=0 ogid=1 rd ev=00:00
obj=system_u:object_r:dcc_client_exec_t:s0
type=AVC msg=audit(1153024564.267:2507): avc: denied { name_bind } for pid=11448
comm="spamd" src=7002 scontext=system_u:system_r :spamd_t:s0
tcontext=system_u:object_r:afs_pt_port_t:s0 tclass=udp_socket
type=SYSCALL msg=audit(1153024564.267:2507): arch=40000003 syscall=102 success=no exit=-13
a0=2 a1=bfa7e6e0 a2=2b5b8c a3=10 items=0 pid=11448 auid=500 uid=0 gid=0 euid=500 suid=0
fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd"
exe="/usr/bin/perl" subj= system_u:system_r:spamd_t:s0
type=SOCKADDR msg=audit(1153024564.267:2507): saddr=02001B5A000000000000000000000000
type=SOCKETCALL msg=audit(1153024564.267:2507): nargs=3 a0=b a1=a238438 a2=10
type=PATH msg=audit(1153028525.987:2792): item=0 name="/usr/local/bin/dccproc"
inode=1245188 dev=16:07 mode=0104555 ouid=0 ogid=1 rd ev=00:00
obj=system_u:object_r:dcc_client_exec_t:s0
type=AVC msg=audit(1153029648.965:2883): avc: denied { search } for pid=9095
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(1153029648.965:2883): arch=40000003 syscall=12 success=no exit=-13
a0=bfd65a42 a1=0 a2=4891eff4 a3=37 items=1 pid=9095 auid=500 uid=500 gid=0 euid=500
suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 tty=(none) comm="dccproc"
exe="/usr/local/bin/dcc proc" subj=system_u:system_r:spamd_t:s0
type=CWD msg=audit(1153029648.965:2883): cwd="/"
type=PATH msg=audit(1153029648.965:2883): item=0 name="/var/dcc" inode=58510
dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=syst em_u:object_r:dcc_var_t:s0
type=AVC msg=audit(1153030201.398:2924): avc: denied { read } for pid=11167
comm="restorecon" name="[220111]" dev=pipefs ino=2201 11
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
type=AVC msg=audit(1153030201.398:2924): avc: denied { write } for pid=11167
comm="restorecon" name="[220112]" dev=pipefs ino=220 112
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
type=AVC msg=audit(1153030201.398:2924): avc: denied { write } for pid=11167
comm="restorecon" name="[220112]" dev=pipefs ino=220 112
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
type=SYSCALL msg=audit(1153030201.398:2924): arch=40000003 syscall=11 success=yes exit=0
a0=89ad188 a1=89ad320 a2=89ad258 a3=89acfc0 items=2 pid=11167 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="restorecon"
exe="/sbin/restorecon " subj=user_u:system_r:restorecon_t:s0
type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220112]"
type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220112]"
type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220111]"
type=CWD msg=audit(1153030201.398:2924): cwd="/"
type=PATH msg=audit(1153030201.398:2924): item=0 name="/sbin/restorecon"
inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00
obj=system_u:object_r:restorecon_exec_t:s0
type=PATH msg=audit(1153030201.398:2924): 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
type=AVC msg=audit(1153030201.414:2925): avc: denied { sigchld } for pid=11161
comm="crond" scontext=user_u:system_r:restorecon_t :s0
tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process
type=SYSCALL msg=audit(1153030201.414:2925): arch=40000003 syscall=114 success=no exit=-10
a0=ffffffff a1=bfbc27f0 a2=0 a3=0 items=0 pid=11161 auid=0 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="crond"
exe="/usr/sbin/crond" subj=system_ u:system_r:crond_t:s0-s0:c0.c255
type=AVC msg=audit(1153030261.495:2940): avc: denied { read } for pid=11202
comm="restorecon" name="[220497]" dev=pipefs ino=2204 97
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
type=AVC msg=audit(1153030261.495:2940): avc: denied { write } for pid=11202
comm="restorecon" name="[220498]" dev=pipefs ino=220 498
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
type=AVC msg=audit(1153030261.495:2940): avc: denied { write } for pid=11202
comm="restorecon" name="[220498]" dev=pipefs ino=220 498
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
type=AVC msg=audit(1153030261.515:2941): avc: denied { sigchld } for pid=11201
comm="crond" scontext=user_u:system_r:restorecon_t :s0
tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process
type=SYSCALL msg=audit(1153030261.515:2941): arch=40000003 syscall=114 success=no exit=-10
a0=ffffffff a1=bfbc27f0 a2=0 a3=0 items=0 pid=11201 auid=0 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="crond"
exe="/usr/sbin/crond" subj=system_ u:system_r:crond_t:s0-s0:c0.c255
type=SYSCALL msg=audit(1153030261.495:2940): arch=40000003 syscall=11 success=yes exit=0
a0=84d91a0 a1=84d9340 a2=84d9278 a3=84d8fb8 items=2 pid=11202 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="restorecon"
exe="/sbin/restorecon " subj=user_u:system_r:restorecon_t:s0
type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220498]"
type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220498]"
type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220497]"
type=CWD msg=audit(1153030261.495:2940): cwd="/"
type=PATH msg=audit(1153030261.495:2940): item=0 name="/sbin/restorecon"
inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00
obj=system_u:object_r:restorecon_exec_t:s0
type=PATH msg=audit(1153030261.495:2940): 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
type=AVC msg=audit(1153030444.617:2952): avc: denied { getattr } for pid=11448
comm="spamd" name="dccproc" dev=hdc7 ino=3135647 s
context=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_exec_t:s0
tclass=file
type=SYSCALL msg=audit(1153030444.617:2952): arch=40000003 syscall=195 success=no exit=-13
a0=999da10 a1=95f30c8 a2=4891eff4 a3=999d a10 items=1 pid=11448 auid=500 uid=0 gid=0
euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd"
exe="/usr/bin /perl" subj=system_u:system_r:spamd_t:s0
type=AVC_PATH msg=audit(1153030444.617:2952): path="/usr/local/bin/dccproc"
type=CWD msg=audit(1153030444.617:2952): cwd="/"
type=PATH msg=audit(1153052884.204:4562): item=0 name="/usr/local/bin/dccproc"
inode=3135647 dev=16:07 mode=0104555 ouid=0 ogid=1 rd ev=00:00
obj=system_u:object_r:dcc_client_exec_t:s0
type=AVC msg=audit(1153053408.030:4599): avc: denied { execmod } for pid=6019
comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" d ev=hdc7
ino=3116816 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1153053408.030:4599): arch=40000003 syscall=125 success=no exit=-13
a0=5c8000 a1=78e000 a2=5 a3=bf84c100 item s=0 pid=6019 auid=0 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2"
exe="/lib/ld-2.4.so" sub j=user_u:system_r:prelink_t:s0
type=AVC_PATH msg=audit(1153053408.030:4599):
path="/usr/lib/libGLcore.so.1.0.8762"
type=AVC msg=audit(1153053408.034:4600): avc: denied { execmod } for pid=6022
comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.876 2" dev=hdc7
ino=3117829 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1153053408.034:4600): arch=40000003 syscall=125 success=no exit=-13
a0=a3e000 a1=1000 a2=5 a3=bfc98d40 items= 0 pid=6022 auid=0 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2"
exe="/lib/ld-2.4.so" subj= user_u:system_r:prelink_t:s0
type=AVC_PATH msg=audit(1153053408.034:4600):
path="/usr/lib/tls/libnvidia-tls.so.1.0.8762"
type=AVC msg=audit(1153054263.049:4661): avc: denied { getattr } for pid=11448
comm="spamd" name="dccproc" dev=hdc7 ino=3135647 s
context=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_exec_t:s0
tclass=file
type=SYSCALL msg=audit(1153054263.049:4661): arch=40000003 syscall=195 success=no exit=-13
a0=999da10 a1=95f30c8 a2=4891eff4 a3=999d a10 items=1 pid=11448 auid=500 uid=0 gid=0
euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd"
exe="/usr/bin /perl" subj=system_u:system_r:spamd_t:s0
type=AVC_PATH msg=audit(1153054263.049:4661): path="/usr/local/bin/dccproc"
type=CWD msg=audit(1153054263.049:4661): cwd="/"
type=PATH msg=audit(1153116601.146:9086): item=0 name="/sbin/restorecon"
inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00
obj=system_u:object_r:restorecon_exec_t:s0
type=PATH msg=audit(1153116601.146:9086): 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
type=AVC msg=audit(1153116605.562:9094): avc: denied { create } for pid=25363
comm="dccproc" scontext=system_u:system_r:spamd_t:s 0
tcontext=system_u:system_r:spamd_t:s0 tclass=netlink_route_socket
type=SYSCALL msg=audit(1153116605.562:9094): arch=40000003 syscall=102 success=no exit=-13
a0=1 a1=bf9fbd58 a2=4891eff4 a3=806a0ff i tems=0 pid=25363 auid=500 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:spamd_t:s0
type=SOCKETCALL msg=audit(1153116605.562:9094): nargs=3 a0=10 a1=3 a2=0
type=AVC msg=audit(1153116605.562:9095): avc: denied { search } for pid=25363
comm="dccproc" name="dcc" dev=dm-1 ino=58510 sconte
xt=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_var_t:s0 tclass=dir
type=SYSCALL msg=audit(1153116605.562:9095): arch=40000003 syscall=12 success=no exit=-13
a0=bf9faec2 a1=0 a2=4891eff4 a3=806a0ff it ems=1 pid=25363 auid=500 uid=500 gid=0 euid=500
suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 tty=(none) comm="dccproc"
exe="/usr/local/b in/dccproc" subj=system_u:system_r:spamd_t:s0
type=CWD msg=audit(1153116605.562:9095): cwd="/"
type=PATH msg=audit(1153116605.562:9095): item=0 name="/var/dcc" inode=58510
dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=syst em_u:object_r:dcc_var_t:s0
type=PATH msg=audit(1153116661.743:9100): item=0 name="/sbin/restorecon"
inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00
obj=system_u:object_r:restorecon_exec_t:s0
type=PATH msg=audit(1153116661.743:9100): 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
type=AVC msg=audit(1153116661.751:9101): avc: denied { sigchld } for pid=25592
comm="crond" scontext=user_u:system_r:restorecon_t :s0
tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process
type=SYSCALL msg=audit(1153116661.751:9101): arch=40000003 syscall=114 success=no exit=-10
a0=ffffffff a1=bfbc27f0 a2=0 a3=0 items=0 pid=25592 auid=0 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="crond"
exe="/usr/sbin/crond" subj=system_ u:system_r:crond_t:s0-s0:c0.c255
type=AVC msg=audit(1153116905.512:9124): avc: denied { getattr } for pid=11448
comm="spamd" name="dccproc" dev=hdc7 ino=3135642 s
context=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_exec_t:s0
tclass=file
type=SYSCALL msg=audit(1153116905.512:9124): arch=40000003 syscall=195 success=no exit=-13
a0=999da10 a1=95f30c8 a2=4891eff4 a3=999d a10 items=1 pid=11448 auid=500 uid=0 gid=0
euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd"
exe="/usr/bin /perl" subj=system_u:system_r:spamd_t:s0
type=AVC_PATH msg=audit(1153116905.512:9124): path="/usr/local/bin/dccproc"
type=CWD msg=audit(1153116905.512:9124): cwd="/"
type=PATH msg=audit(1153138559.711:8): item=0 name="/var/run/utmp" inode=87750
dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj= system_u:object_r:init_var_run_t:s0
type=AVC msg=audit(1153138559.715:9): avc: denied { read } for pid=2374
comm="mingetty" name="utmp" dev=dm-1 ino=87750 scontext=s
ystem_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file
type=SYSCALL msg=audit(1153138559.715:9): arch=40000003 syscall=5 success=no exit=-13
a0=48909fd4 a1=0 a2=804a000 a3=48909fda items= 1 pid=2374 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty"
exe="/sbin/mingetty" s ubj=system_u:system_r:getty_t:s0
type=CWD msg=audit(1153138559.715:9): cwd="/"
type=PATH msg=audit(1153138559.715:9): item=0 name="/var/run/utmp" inode=87750
dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj= system_u:object_r:init_var_run_t:s0
type=AVC msg=audit(1153138559.715:10): avc: denied { read write } for pid=2374
comm="mingetty" name="utmp" dev=dm-1 ino=87750 sco
ntext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0
tclass=file
type=SYSCALL msg=audit(1153138559.715:10): arch=40000003 syscall=5 success=no exit=-13
a0=48909fd4 a1=2 a2=0 a3=48909fda items=1 pid =2374 auid=4294967295 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty"
exe="/sbin/mingetty" subj=s ystem_u:system_r:getty_t:s0
type=CWD msg=audit(1153138559.715:10): cwd="/"
8:11 a.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz (via MN) wrote:
Latest avc's below, subsequent to the updates and reboots. I have
tried
to remove a lot of the dups. If you need more info, let me know.
Marc
type=AVC msg=audit(1153023605.343:2448): avc: denied { getattr } for pid=11448
comm="spamd" name="dccproc" dev=hdc7 ino=1245188 s
context=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_exec_t:s0
tclass=file
type=SYSCALL msg=audit(1153023605.343:2448): arch=40000003 syscall=195 success=no
exit=-13 a0=999da10 a1=95f30c8 a2=4891eff4 a3=999d a10 items=1 pid=11448 auid=500 uid=0
gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none)
comm="spamd" exe="/usr/bin /perl" subj=system_u:system_r:spamd_t:s0
type=AVC_PATH msg=audit(1153023605.343:2448): path="/usr/local/bin/dccproc"
type=CWD msg=audit(1153023605.343:2448): cwd="/"
type=PATH msg=audit(1153023605.343:2448): item=0 name="/usr/local/bin/dccproc"
inode=1245188 dev=16:07 mode=0104555 ouid=0 ogid=1 rd ev=00:00
obj=system_u:object_r:dcc_client_exec_t:s0
type=AVC msg=audit(1153023963.916:2467): avc: denied { getattr } for pid=11448
comm="spamd" name="dccproc" dev=hdc7 ino=1245188 s
context=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_client_exec_t:s0
tclass=file
type=SYSCALL msg=audit(1153023963.916:2467): arch=40000003 syscall=195 success=no
exit=-13 a0=999da10 a1=95f30c8 a2=4891eff4 a3=999d a10 items=1 pid=11448 auid=500 uid=0
gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none)
comm="spamd" exe="/usr/bin /perl" subj=system_u:system_r:spamd_t:s0
type=AVC_PATH msg=audit(1153023963.916:2467): path="/usr/local/bin/dccproc"
type=CWD msg=audit(1153023963.916:2467): cwd="/"
type=PATH msg=audit(1153024204.542:2488): item=0 name="/usr/local/bin/dccproc"
inode=1245188 dev=16:07 mode=0104555 ouid=0 ogid=1 rd ev=00:00
obj=system_u:object_r:dcc_client_exec_t:s0
type=AVC msg=audit(1153024564.267:2507): avc: denied { name_bind } for pid=11448
comm="spamd" src=7002 scontext=system_u:system_r :spamd_t:s0
tcontext=system_u:object_r:afs_pt_port_t:s0 tclass=udp_socket
type=SYSCALL msg=audit(1153024564.267:2507): arch=40000003 syscall=102 success=no
exit=-13 a0=2 a1=bfa7e6e0 a2=2b5b8c a3=10 items=0 pid=11448 auid=500 uid=0 gid=0 euid=500
suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) comm="spamd"
exe="/usr/bin/perl" subj= system_u:system_r:spamd_t:s0
type=SOCKADDR msg=audit(1153024564.267:2507): saddr=02001B5A000000000000000000000000
type=SOCKETCALL msg=audit(1153024564.267:2507): nargs=3 a0=b a1=a238438 a2=10
type=PATH msg=audit(1153028525.987:2792): item=0 name="/usr/local/bin/dccproc"
inode=1245188 dev=16:07 mode=0104555 ouid=0 ogid=1 rd ev=00:00
obj=system_u:object_r:dcc_client_exec_t:s0
type=AVC msg=audit(1153029648.965:2883): avc: denied { search } for pid=9095
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(1153029648.965:2883): arch=40000003 syscall=12 success=no exit=-13
a0=bfd65a42 a1=0 a2=4891eff4 a3=37 items=1 pid=9095 auid=500 uid=500 gid=0 euid=500
suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 tty=(none) comm="dccproc"
exe="/usr/local/bin/dcc proc" subj=system_u:system_r:spamd_t:s0
type=CWD msg=audit(1153029648.965:2883): cwd="/"
type=PATH msg=audit(1153029648.965:2883): item=0 name="/var/dcc" inode=58510
dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=syst em_u:object_r:dcc_var_t:s0
I think you're getting these because I removed the transition from
spamd_t to dcc_client_t, since I thought that with the dcc policy now
being included in the selinux-policy-targeted package, would already be
included.
type=AVC msg=audit(1153030201.398:2924): avc: denied { read } for
pid=11167 comm="restorecon" name="[220111]" dev=pipefs ino=2201 11
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
type=AVC msg=audit(1153030201.398:2924): avc: denied { write } for pid=11167
comm="restorecon" name="[220112]" dev=pipefs ino=220 112
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
type=AVC msg=audit(1153030201.398:2924): avc: denied { write } for pid=11167
comm="restorecon" name="[220112]" dev=pipefs ino=220 112
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
type=SYSCALL msg=audit(1153030201.398:2924): arch=40000003 syscall=11 success=yes exit=0
a0=89ad188 a1=89ad320 a2=89ad258 a3=89acfc0 items=2 pid=11167 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="restorecon"
exe="/sbin/restorecon " subj=user_u:system_r:restorecon_t:s0
type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220112]"
type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220112]"
type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220111]"
type=CWD msg=audit(1153030201.398:2924): cwd="/"
type=PATH msg=audit(1153030201.398:2924): item=0 name="/sbin/restorecon"
inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00
obj=system_u:object_r:restorecon_exec_t:s0
type=PATH msg=audit(1153030201.398:2924): 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
type=AVC msg=audit(1153030201.414:2925): avc: denied { sigchld } for pid=11161
comm="crond" scontext=user_u:system_r:restorecon_t :s0
tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process
type=SYSCALL msg=audit(1153030201.414:2925): arch=40000003 syscall=114 success=no
exit=-10 a0=ffffffff a1=bfbc27f0 a2=0 a3=0 items=0 pid=11161 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="crond"
exe="/usr/sbin/crond" subj=system_ u:system_r:crond_t:s0-s0:c0.c255
type=AVC msg=audit(1153030261.495:2940): avc: denied { read } for pid=11202
comm="restorecon" name="[220497]" dev=pipefs ino=2204 97
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
type=AVC msg=audit(1153030261.495:2940): avc: denied { write } for pid=11202
comm="restorecon" name="[220498]" dev=pipefs ino=220 498
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
type=AVC msg=audit(1153030261.495:2940): avc: denied { write } for pid=11202
comm="restorecon" name="[220498]" dev=pipefs ino=220 498
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
type=AVC msg=audit(1153030261.515:2941): avc: denied { sigchld } for pid=11201
comm="crond" scontext=user_u:system_r:restorecon_t :s0
tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process
type=SYSCALL msg=audit(1153030261.515:2941): arch=40000003 syscall=114 success=no
exit=-10 a0=ffffffff a1=bfbc27f0 a2=0 a3=0 items=0 pid=11201 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="crond"
exe="/usr/sbin/crond" subj=system_ u:system_r:crond_t:s0-s0:c0.c255
type=SYSCALL msg=audit(1153030261.495:2940): arch=40000003 syscall=11 success=yes exit=0
a0=84d91a0 a1=84d9340 a2=84d9278 a3=84d8fb8 items=2 pid=11202 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="restorecon"
exe="/sbin/restorecon " subj=user_u:system_r:restorecon_t:s0
type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220498]"
type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220498]"
type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220497]"
type=CWD msg=audit(1153030261.495:2940): cwd="/"
type=PATH msg=audit(1153030261.495:2940): item=0 name="/sbin/restorecon"
inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00
obj=system_u:object_r:restorecon_exec_t:s0
type=PATH msg=audit(1153030261.495:2940): 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
These all appear to be due to running restorecon in a cron job. Probably
your dcc client building script.
I could add this to the dcc policy (or a separate local module for
restorecon):
cron_system_entry(restorecon_t)
However, I think that the "right" way to fix this would be to use
restorecond and add an entry to /etc/selinux/restorecond.conf (the
manpage for restorecond suggests
/etc/selinux/POLICYTYPE/restorconfiles.conf but that file doesn't seem
to exist, and the restorecond binary includes the string
/etc/selinux/restorecond.conf).
Maybe Dan could comment on that?
type=AVC msg=audit(1153053408.030:4599): avc: denied { execmod }
for pid=6019 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" d
ev=hdc7 ino=3116816 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1153053408.030:4599): arch=40000003 syscall=125 success=no
exit=-13 a0=5c8000 a1=78e000 a2=5 a3=bf84c100 item s=0 pid=6019 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2"
exe="/lib/ld-2.4.so" sub j=user_u:system_r:prelink_t:s0
type=AVC_PATH msg=audit(1153053408.030:4599):
path="/usr/lib/libGLcore.so.1.0.8762"
type=AVC msg=audit(1153053408.034:4600): avc: denied { execmod } for pid=6022
comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.876 2" dev=hdc7
ino=3117829 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1153053408.034:4600): arch=40000003 syscall=125 success=no
exit=-13 a0=a3e000 a1=1000 a2=5 a3=bfc98d40 items= 0 pid=6022 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2"
exe="/lib/ld-2.4.so" subj= user_u:system_r:prelink_t:s0
type=AVC_PATH msg=audit(1153053408.034:4600):
path="/usr/lib/tls/libnvidia-tls.so.1.0.8762"
Do you have nvidia video drivers installed using the nvidia installer
rather than an RPM package? If so, you should probably see:
http://www.city-fan.org/tips/ProprietaryVideoDriverWarning
type=PATH msg=audit(1153138559.711:8): item=0
name="/var/run/utmp" inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22
rdev=00:00 obj= system_u:object_r:init_var_run_t:s0
type=AVC msg=audit(1153138559.715:9): avc: denied { read } for pid=2374
comm="mingetty" name="utmp" dev=dm-1 ino=87750 scontext=s
ystem_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file
type=SYSCALL msg=audit(1153138559.715:9): arch=40000003 syscall=5 success=no exit=-13
a0=48909fd4 a1=0 a2=804a000 a3=48909fda items= 1 pid=2374 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty"
exe="/sbin/mingetty" s ubj=system_u:system_r:getty_t:s0
type=CWD msg=audit(1153138559.715:9): cwd="/"
type=PATH msg=audit(1153138559.715:9): item=0 name="/var/run/utmp" inode=87750
dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj= system_u:object_r:init_var_run_t:s0
type=AVC msg=audit(1153138559.715:10): avc: denied { read write } for pid=2374
comm="mingetty" name="utmp" dev=dm-1 ino=87750 sco
ntext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0
tclass=file
type=SYSCALL msg=audit(1153138559.715:10): arch=40000003 syscall=5 success=no exit=-13
a0=48909fd4 a1=2 a2=0 a3=48909fda items=1 pid =2374 auid=4294967295 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty"
exe="/sbin/mingetty" subj=s ystem_u:system_r:getty_t:s0
type=CWD msg=audit(1153138559.715:10): cwd="/"
Your /var/run/utmp appears to be labelled init_var_run_t rather than
initrc_var_run_t.
::::::::::::::
myspamassassin.te
::::::::::::::
policy_module(myspamassassin, 0.1.5)
require {
type spamd_t;
}
type spamd_log_t;
logging_log_file(spamd_log_t)
# These appear to be in selinux-policy-2.2.47-3.fc5
# but don't seem to be working. Perhaps they need to be
# included in the base policy rather than as separate modules?
dcc_domtrans_client(spamd_t)
pyzor_domtrans(spamd_t)
# Signal the dcc client (SIGTERM is used?)
dcc_signal_client(spamd_t)
# Use log files
allow spamd_t spamd_log_t:file create_file_perms;
allow spamd_t spamd_log_t:dir rw_dir_perms;
logging_log_filetrans(spamd_t,spamd_log_t,{ file dir })
Paul.
9:53 a.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-07-18 at 14:11 +0100, Paul Howarth wrote:
Marc Schwartz (via MN) wrote:
> Latest avc's below, subsequent to the updates and reboots. I have tried
> to remove a lot of the dups. If you need more info, let me know.
>
> Marc
<snip>
> type=AVC msg=audit(1153030201.398:2924): avc: denied { read }
for pid=11167 comm="restorecon" name="[220111]" dev=pipefs ino=2201
11 scontext=user_u:system_r:restorecon_t:s0
tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file
> type=AVC msg=audit(1153030201.398:2924): avc: denied { write } for pid=11167
comm="restorecon" name="[220112]" dev=pipefs ino=220 112
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
> type=AVC msg=audit(1153030201.398:2924): avc: denied { write } for pid=11167
comm="restorecon" name="[220112]" dev=pipefs ino=220 112
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
> type=SYSCALL msg=audit(1153030201.398:2924): arch=40000003 syscall=11 success=yes
exit=0 a0=89ad188 a1=89ad320 a2=89ad258 a3=89acfc0 items=2 pid=11167 auid=0 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="restorecon"
exe="/sbin/restorecon " subj=user_u:system_r:restorecon_t:s0
> type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220112]"
> type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220112]"
> type=AVC_PATH msg=audit(1153030201.398:2924): path="pipe:[220111]"
> type=CWD msg=audit(1153030201.398:2924): cwd="/"
> type=PATH msg=audit(1153030201.398:2924): item=0 name="/sbin/restorecon"
inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00
obj=system_u:object_r:restorecon_exec_t:s0
> type=PATH msg=audit(1153030201.398:2924): 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
> type=AVC msg=audit(1153030201.414:2925): avc: denied { sigchld } for pid=11161
comm="crond" scontext=user_u:system_r:restorecon_t :s0
tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process
> type=SYSCALL msg=audit(1153030201.414:2925): arch=40000003 syscall=114 success=no
exit=-10 a0=ffffffff a1=bfbc27f0 a2=0 a3=0 items=0 pid=11161 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="crond"
exe="/usr/sbin/crond" subj=system_ u:system_r:crond_t:s0-s0:c0.c255
> type=AVC msg=audit(1153030261.495:2940): avc: denied { read } for pid=11202
comm="restorecon" name="[220497]" dev=pipefs ino=2204 97
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
> type=AVC msg=audit(1153030261.495:2940): avc: denied { write } for pid=11202
comm="restorecon" name="[220498]" dev=pipefs ino=220 498
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
> type=AVC msg=audit(1153030261.495:2940): avc: denied { write } for pid=11202
comm="restorecon" name="[220498]" dev=pipefs ino=220 498
scontext=user_u:system_r:restorecon_t:s0 tcontext=system_u:system_r:crond_t:s0-s0:c0.c255
tclass=fifo_file
> type=AVC msg=audit(1153030261.515:2941): avc: denied { sigchld } for pid=11201
comm="crond" scontext=user_u:system_r:restorecon_t :s0
tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=process
> type=SYSCALL msg=audit(1153030261.515:2941): arch=40000003 syscall=114 success=no
exit=-10 a0=ffffffff a1=bfbc27f0 a2=0 a3=0 items=0 pid=11201 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="crond"
exe="/usr/sbin/crond" subj=system_ u:system_r:crond_t:s0-s0:c0.c255
> type=SYSCALL msg=audit(1153030261.495:2940): arch=40000003 syscall=11 success=yes
exit=0 a0=84d91a0 a1=84d9340 a2=84d9278 a3=84d8fb8 items=2 pid=11202 auid=0 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="restorecon"
exe="/sbin/restorecon " subj=user_u:system_r:restorecon_t:s0
> type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220498]"
> type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220498]"
> type=AVC_PATH msg=audit(1153030261.495:2940): path="pipe:[220497]"
> type=CWD msg=audit(1153030261.495:2940): cwd="/"
> type=PATH msg=audit(1153030261.495:2940): item=0 name="/sbin/restorecon"
inode=3542952 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00: 00
obj=system_u:object_r:restorecon_exec_t:s0
> type=PATH msg=audit(1153030261.495:2940): 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
These all appear to be due to running restorecon in a cron job. Probably
your dcc client building script.
Yep:
# Run restorecon to restore the SELinux context after re-building
10 01 * * * root /sbin/restorecon -rv /var/dcc
11 01 * * * root /sbin/restorecon -v /usr/local/bin/dccproc
I could add this to the dcc policy (or a separate local module for
restorecon):
cron_system_entry(restorecon_t)
However, I think that the "right" way to fix this would be to use
restorecond and add an entry to /etc/selinux/restorecond.conf (the
manpage for restorecond suggests
/etc/selinux/POLICYTYPE/restorconfiles.conf but that file doesn't seem
to exist, and the restorecond binary includes the string
/etc/selinux/restorecond.conf).
Maybe Dan could comment on that?
> type=AVC msg=audit(1153053408.030:4599): avc: denied { execmod } for pid=6019
comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" d ev=hdc7
ino=3116816 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0
tclass=file
> type=SYSCALL msg=audit(1153053408.030:4599): arch=40000003 syscall=125 success=no
exit=-13 a0=5c8000 a1=78e000 a2=5 a3=bf84c100 item s=0 pid=6019 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2"
exe="/lib/ld-2.4.so" sub j=user_u:system_r:prelink_t:s0
> type=AVC_PATH msg=audit(1153053408.030:4599):
path="/usr/lib/libGLcore.so.1.0.8762"
> type=AVC msg=audit(1153053408.034:4600): avc: denied { execmod } for pid=6022
comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.876 2" dev=hdc7
ino=3117829 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0
tclass=file
> type=SYSCALL msg=audit(1153053408.034:4600): arch=40000003 syscall=125 success=no
exit=-13 a0=a3e000 a1=1000 a2=5 a3=bfc98d40 items= 0 pid=6022 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2"
exe="/lib/ld-2.4.so" subj= user_u:system_r:prelink_t:s0
> type=AVC_PATH msg=audit(1153053408.034:4600):
path="/usr/lib/tls/libnvidia-tls.so.1.0.8762"
Do you have nvidia video drivers installed using the nvidia installer
rather than an RPM package? If so, you should probably see:
http://www.city-fan.org/tips/ProprietaryVideoDriverWarning
Yep. I have never had a problem with them (dating back to RH 8.0, all
on Dell laptops) and this is the first time that I had noted any avc's
related to them.
I have a script that I ran when I first moved to FC5 to set the
following:
/usr/sbin/setsebool -P allow_execstack=1
/usr/sbin/setsebool -P allow_execmod=1
based upon documents that I had found elsewhere.
I re-ran it just in case something changed after I re-built the driver
with the latest kernel install (2157). I'll keep an eye out for any
further avc's.
I appreciate the caveats noted on the page you reference.
> type=PATH msg=audit(1153138559.711:8): item=0
name="/var/run/utmp" inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22
rdev=00:00 obj= system_u:object_r:init_var_run_t:s0
> type=AVC msg=audit(1153138559.715:9): avc: denied { read } for pid=2374
comm="mingetty" name="utmp" dev=dm-1 ino=87750 scontext=s
ystem_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file
> type=SYSCALL msg=audit(1153138559.715:9): arch=40000003 syscall=5 success=no
exit=-13 a0=48909fd4 a1=0 a2=804a000 a3=48909fda items= 1 pid=2374 auid=4294967295 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty"
exe="/sbin/mingetty" s ubj=system_u:system_r:getty_t:s0
> type=CWD msg=audit(1153138559.715:9): cwd="/"
> type=PATH msg=audit(1153138559.715:9): item=0 name="/var/run/utmp"
inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj=
system_u:object_r:init_var_run_t:s0
> type=AVC msg=audit(1153138559.715:10): avc: denied { read write } for pid=2374
comm="mingetty" name="utmp" dev=dm-1 ino=87750 sco
ntext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0
tclass=file
> type=SYSCALL msg=audit(1153138559.715:10): arch=40000003 syscall=5 success=no
exit=-13 a0=48909fd4 a1=2 a2=0 a3=48909fda items=1 pid =2374 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty"
exe="/sbin/mingetty" subj=s ystem_u:system_r:getty_t:s0
> type=CWD msg=audit(1153138559.715:10): cwd="/"
Your /var/run/utmp appears to be labelled init_var_run_t rather than
initrc_var_run_t.
Yep:
# ls -lZ /var/run/utmp
-rw-rw-r-- root utmp system_u:object_r:init_var_run_t /var/run/utmp
# restorecon /var/run/utmp
# ls -lZ /var/run/utmp
-rw-rw-r-- root utmp system_u:object_r:initrc_var_run_t /var/run/utmp
::::::::::::::
myspamassassin.te
::::::::::::::
policy_module(myspamassassin, 0.1.5)
require {
type spamd_t;
}
type spamd_log_t;
logging_log_file(spamd_log_t)
# These appear to be in selinux-policy-2.2.47-3.fc5
# but don't seem to be working. Perhaps they need to be
# included in the base policy rather than as separate modules?
dcc_domtrans_client(spamd_t)
pyzor_domtrans(spamd_t)
# Signal the dcc client (SIGTERM is used?)
dcc_signal_client(spamd_t)
# Use log files
allow spamd_t spamd_log_t:file create_file_perms;
allow spamd_t spamd_log_t:dir rw_dir_perms;
logging_log_filetrans(spamd_t,spamd_log_t,{ file dir })
All changed.
I'll post back with any new avc's after a bit and a re-boot or two.
Thanks,
Marc
10:15 a.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz (via MN) wrote:
On Tue, 2006-07-18 at 14:11 +0100, Paul Howarth wrote:
# Run restorecon to restore the SELinux context after re-building
10 01 * * * root /sbin/restorecon -rv /var/dcc
11 01 * * * root /sbin/restorecon -v /usr/local/bin/dccproc
> I could add this to the dcc policy (or a separate local module for
> restorecon):
> cron_system_entry(restorecon_t)
>
> However, I think that the "right" way to fix this would be to use
> restorecond and add an entry to /etc/selinux/restorecond.conf (the
> manpage for restorecond suggests
> /etc/selinux/POLICYTYPE/restorconfiles.conf but that file doesn't seem
> to exist, and the restorecond binary includes the string
> /etc/selinux/restorecond.conf).
>
> Maybe Dan could comment on that?
Try this instead of your cron jobs and see what happens:
# chkconfig --add restorecond
# chkconfig restorecond on
Edit /etc/selinux/restorecond.conf and add a line:
/usr/local/bin/dccproc
(is the restorecon of /var/dcc actually needed?)
If you have network-mounted home directories, you may want to remove the
lines starting with "~"
Then:
# service restorecond start
>> type=AVC msg=audit(1153053408.030:4599): avc: denied {
execmod } for pid=6019 comm="ld-linux.so.2"
name="libGLcore.so.1.0.8762" d ev=hdc7 ino=3116816
scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file
>> type=SYSCALL msg=audit(1153053408.030:4599): arch=40000003 syscall=125 success=no
exit=-13 a0=5c8000 a1=78e000 a2=5 a3=bf84c100 item s=0 pid=6019 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2"
exe="/lib/ld-2.4.so" sub j=user_u:system_r:prelink_t:s0
>> type=AVC_PATH msg=audit(1153053408.030:4599):
path="/usr/lib/libGLcore.so.1.0.8762"
>> type=AVC msg=audit(1153053408.034:4600): avc: denied { execmod } for pid=6022
comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.876 2" dev=hdc7
ino=3117829 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0
tclass=file
>> type=SYSCALL msg=audit(1153053408.034:4600): arch=40000003 syscall=125 success=no
exit=-13 a0=a3e000 a1=1000 a2=5 a3=bfc98d40 items= 0 pid=6022 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ld-linux.so.2"
exe="/lib/ld-2.4.so" subj= user_u:system_r:prelink_t:s0
>> type=AVC_PATH msg=audit(1153053408.034:4600):
path="/usr/lib/tls/libnvidia-tls.so.1.0.8762"
> Do you have nvidia video drivers installed using the nvidia installer
> rather than an RPM package? If so, you should probably see:
> http://www.city-fan.org/tips/ProprietaryVideoDriverWarning
Yep. I have never had a problem with them (dating back to RH 8.0, all
on Dell laptops) and this is the first time that I had noted any avc's
related to them.
I have a script that I ran when I first moved to FC5 to set the
following:
/usr/sbin/setsebool -P allow_execstack=1
/usr/sbin/setsebool -P allow_execmod=1
based upon documents that I had found elsewhere.
That's somewhat overkill and I wouldn't want to do that.
Undo it with:
# setsebool -P allow_execstack 0
# setsebool -P allow_execmod 0
Then fix the file contexts instead:
# semanage fcontext -a -f -- -t textrel_shlib_t
'/usr/lib/libGL(core)?\.so(\.[^/]*)*'
# semanage fcontext -a -f -- -t textrel_shlib_t
'/usr/lib/libnvidia.*\.so(\.[^/]*)*'
# restorecon -v /usr/lib/libGL* /usr/lib/libnvidia*
Please check that these files have context type textrel_shlib_t after
doing this.
The upstream policy has file contexts set for this but I fear they're
falling foul of the file contexts ordering rules.
>> type=PATH msg=audit(1153138559.711:8): item=0
name="/var/run/utmp" inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22
rdev=00:00 obj= system_u:object_r:init_var_run_t:s0
>> type=AVC msg=audit(1153138559.715:9): avc: denied { read } for pid=2374
comm="mingetty" name="utmp" dev=dm-1 ino=87750 scontext=s
ystem_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file
>> type=SYSCALL msg=audit(1153138559.715:9): arch=40000003 syscall=5 success=no
exit=-13 a0=48909fd4 a1=0 a2=804a000 a3=48909fda items= 1 pid=2374 auid=4294967295 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty"
exe="/sbin/mingetty" s ubj=system_u:system_r:getty_t:s0
>> type=CWD msg=audit(1153138559.715:9): cwd="/"
>> type=PATH msg=audit(1153138559.715:9): item=0 name="/var/run/utmp"
inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj=
system_u:object_r:init_var_run_t:s0
>> type=AVC msg=audit(1153138559.715:10): avc: denied { read write } for pid=2374
comm="mingetty" name="utmp" dev=dm-1 ino=87750 sco
ntext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0
tclass=file
>> type=SYSCALL msg=audit(1153138559.715:10): arch=40000003 syscall=5 success=no
exit=-13 a0=48909fd4 a1=2 a2=0 a3=48909fda items=1 pid =2374 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty"
exe="/sbin/mingetty" subj=s ystem_u:system_r:getty_t:s0
>> type=CWD msg=audit(1153138559.715:10): cwd="/"
> Your /var/run/utmp appears to be labelled init_var_run_t rather than
> initrc_var_run_t.
Yep:
# ls -lZ /var/run/utmp
-rw-rw-r-- root utmp system_u:object_r:init_var_run_t /var/run/utmp
# restorecon /var/run/utmp
# ls -lZ /var/run/utmp
-rw-rw-r-- root utmp system_u:object_r:initrc_var_run_t /var/run/utmp
Running restorecond should stop this happening again.
Paul.
7:37 p.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-07-18 at 16:15 +0100, Paul Howarth wrote:
Marc Schwartz (via MN) wrote:
> On Tue, 2006-07-18 at 14:11 +0100, Paul Howarth wrote:
> # Run restorecon to restore the SELinux context after re-building
> 10 01 * * * root /sbin/restorecon -rv /var/dcc
> 11 01 * * * root /sbin/restorecon -v /usr/local/bin/dccproc
>
>
>> I could add this to the dcc policy (or a separate local module for
>> restorecon):
>> cron_system_entry(restorecon_t)
>>
>> However, I think that the "right" way to fix this would be to use
>> restorecond and add an entry to /etc/selinux/restorecond.conf (the
>> manpage for restorecond suggests
>> /etc/selinux/POLICYTYPE/restorconfiles.conf but that file doesn't seem
>> to exist, and the restorecond binary includes the string
>> /etc/selinux/restorecond.conf).
>>
>> Maybe Dan could comment on that?
Try this instead of your cron jobs and see what happens:
# chkconfig --add restorecond
# chkconfig restorecond on
Edit /etc/selinux/restorecond.conf and add a line:
/usr/local/bin/dccproc
All the above done.
(is the restorecon of /var/dcc actually needed?)
Hopefully not. We did that as a temp fix b/c the context would change
after each nightly build.
If you have network-mounted home directories, you may want to remove
the
lines starting with "~"
Then:
# service restorecond start
Done.
>>> type=AVC msg=audit(1153053408.030:4599): avc: denied {
execmod } for pid=6019 comm="ld-linux.so.2"
name="libGLcore.so.1.0.8762" d ev=hdc7 ino=3116816
scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0 tclass=file
>>> type=SYSCALL msg=audit(1153053408.030:4599): arch=40000003 syscall=125
success=no exit=-13 a0=5c8000 a1=78e000 a2=5 a3=bf84c100 item s=0 pid=6019 auid=0 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
comm="ld-linux.so.2" exe="/lib/ld-2.4.so" sub
j=user_u:system_r:prelink_t:s0
>>> type=AVC_PATH msg=audit(1153053408.030:4599):
path="/usr/lib/libGLcore.so.1.0.8762"
>>> type=AVC msg=audit(1153053408.034:4600): avc: denied { execmod } for
pid=6022 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.876 2"
dev=hdc7 ino=3117829 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0
tclass=file
>>> type=SYSCALL msg=audit(1153053408.034:4600): arch=40000003 syscall=125
success=no exit=-13 a0=a3e000 a1=1000 a2=5 a3=bfc98d40 items= 0 pid=6022 auid=0 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
comm="ld-linux.so.2" exe="/lib/ld-2.4.so" subj=
user_u:system_r:prelink_t:s0
>>> type=AVC_PATH msg=audit(1153053408.034:4600):
path="/usr/lib/tls/libnvidia-tls.so.1.0.8762"
>> Do you have nvidia video drivers installed using the nvidia installer
>> rather than an RPM package? If so, you should probably see:
>> http://www.city-fan.org/tips/ProprietaryVideoDriverWarning
>
> Yep. I have never had a problem with them (dating back to RH 8.0, all
> on Dell laptops) and this is the first time that I had noted any avc's
> related to them.
>
> I have a script that I ran when I first moved to FC5 to set the
> following:
>
> /usr/sbin/setsebool -P allow_execstack=1
> /usr/sbin/setsebool -P allow_execmod=1
>
> based upon documents that I had found elsewhere.
That's somewhat overkill and I wouldn't want to do that.
Curiously, that approach is still noted in a variety of places,
including FedoraFaq.org:
http://www.fedorafaq.org/#nvidia
and others:
http://www.mjmwired.net/resources/mjm-fedora-fc5.html#nvidia
http://stanton-finley.net/fedora_core_5_installation_notes.html#nVidia
Though I noted that it has been updated similar to your recommendation
in other places now, including the nVidia forums:
http://www.nvnews.net/vbulletin/showthread.php?t=68681
Undo it with:
# setsebool -P allow_execstack 0
# setsebool -P allow_execmod 0
Then fix the file contexts instead:
# semanage fcontext -a -f -- -t textrel_shlib_t
'/usr/lib/libGL(core)?\.so(\.[^/]*)*'
# semanage fcontext -a -f -- -t textrel_shlib_t
'/usr/lib/libnvidia.*\.so(\.[^/]*)*'
# restorecon -v /usr/lib/libGL* /usr/lib/libnvidia*
Please check that these files have context type textrel_shlib_t after
doing this.
# ls -lZ /usr/lib/libGL*
lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libGLcore.so.1 ->
libGLcore.so.1.0.8762
-rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/libGLcore.so.1.0.8762
-rw-r--r-- root root root:object_r:lib_t /usr/lib/libGL.la
lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libGL.so -> libGL.so.1
lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libGL.so.1 ->
libGL.so.1.0.8762
-rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/libGL.so.1.0.8762
lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libGLU.so ->
libGLU.so.1
lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libGLU.so.1 ->
libGLU.so.1.3.060402
-rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/libGLU.so.1.3.060402
lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libGLw.so ->
libGLw.so.1
lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libGLw.so.1 ->
libGLw.so.1.0.0
-rwxr-xr-x root root system_u:object_r:lib_t /usr/lib/libGLw.so.1.0.0
# ls -lZ /usr/lib/libnvidia*
lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libnvidia-cfg.so ->
libnvidia-cfg.so.1
lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libnvidia-cfg.so.1 ->
libnvidia-cfg.so.1.0.8762
-rwxr-xr-x root root system_u:object_r:textrel_shlib_t
/usr/lib/libnvidia-cfg.so.1.0.8762
lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libnvidia-tls.so.1 ->
libnvidia-tls.so.1.0.8762
-rwxr-xr-x root root system_u:object_r:textrel_shlib_t
/usr/lib/libnvidia-tls.so.1.0.8762
The upstream policy has file contexts set for this but I fear
they're
falling foul of the file contexts ordering rules.
>>> type=PATH msg=audit(1153138559.711:8): item=0 name="/var/run/utmp"
inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj=
system_u:object_r:init_var_run_t:s0
>>> type=AVC msg=audit(1153138559.715:9): avc: denied { read } for pid=2374
comm="mingetty" name="utmp" dev=dm-1 ino=87750 scontext=s
ystem_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file
>>> type=SYSCALL msg=audit(1153138559.715:9): arch=40000003 syscall=5 success=no
exit=-13 a0=48909fd4 a1=0 a2=804a000 a3=48909fda items= 1 pid=2374 auid=4294967295 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mingetty"
exe="/sbin/mingetty" s ubj=system_u:system_r:getty_t:s0
>>> type=CWD msg=audit(1153138559.715:9): cwd="/"
>>> type=PATH msg=audit(1153138559.715:9): item=0 name="/var/run/utmp"
inode=87750 dev=fd:01 mode=0100664 ouid=0 ogid=22 rdev=00:00 obj=
system_u:object_r:init_var_run_t:s0
>>> type=AVC msg=audit(1153138559.715:10): avc: denied { read write } for
pid=2374 comm="mingetty" name="utmp" dev=dm-1 ino=87750 sco
ntext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0
tclass=file
>>> type=SYSCALL msg=audit(1153138559.715:10): arch=40000003 syscall=5
success=no exit=-13 a0=48909fd4 a1=2 a2=0 a3=48909fda items=1 pid =2374 auid=4294967295
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
comm="mingetty" exe="/sbin/mingetty" subj=s
ystem_u:system_r:getty_t:s0
>>> type=CWD msg=audit(1153138559.715:10): cwd="/"
>> Your /var/run/utmp appears to be labelled init_var_run_t rather than
>> initrc_var_run_t.
>
> Yep:
>
> # ls -lZ /var/run/utmp
> -rw-rw-r-- root utmp system_u:object_r:init_var_run_t /var/run/utmp
>
> # restorecon /var/run/utmp
>
> # ls -lZ /var/run/utmp
> -rw-rw-r-- root utmp system_u:object_r:initrc_var_run_t /var/run/utmp
Running restorecond should stop this happening again.
Paul.
OK. All done.
So far, no more avc's, but I'll keep track overnight and through a
couple of re-boots tomorrow.
Thanks,
Marc
6:05 a.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz wrote:
On Tue, 2006-07-18 at 16:15 +0100, Paul Howarth wrote:
>>>> type=AVC msg=audit(1153053408.030:4599): avc: denied { execmod } for
pid=6019 comm="ld-linux.so.2" name="libGLcore.so.1.0.8762" d ev=hdc7
ino=3116816 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0
tclass=file
>>>> type=SYSCALL msg=audit(1153053408.030:4599): arch=40000003 syscall=125
success=no exit=-13 a0=5c8000 a1=78e000 a2=5 a3=bf84c100 item s=0 pid=6019 auid=0 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
comm="ld-linux.so.2" exe="/lib/ld-2.4.so" sub
j=user_u:system_r:prelink_t:s0
>>>> type=AVC_PATH msg=audit(1153053408.030:4599):
path="/usr/lib/libGLcore.so.1.0.8762"
>>>> type=AVC msg=audit(1153053408.034:4600): avc: denied { execmod } for
pid=6022 comm="ld-linux.so.2" name="libnvidia-tls.so.1.0.876 2"
dev=hdc7 ino=3117829 scontext=user_u:system_r:prelink_t:s0 tcontext=root:object_r:lib_t:s0
tclass=file
>>>> type=SYSCALL msg=audit(1153053408.034:4600): arch=40000003 syscall=125
success=no exit=-13 a0=a3e000 a1=1000 a2=5 a3=bfc98d40 items= 0 pid=6022 auid=0 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
comm="ld-linux.so.2" exe="/lib/ld-2.4.so" subj=
user_u:system_r:prelink_t:s0
>>>> type=AVC_PATH msg=audit(1153053408.034:4600):
path="/usr/lib/tls/libnvidia-tls.so.1.0.8762"
>>> Do you have nvidia video drivers installed using the nvidia installer
>>> rather than an RPM package? If so, you should probably see:
>>> http://www.city-fan.org/tips/ProprietaryVideoDriverWarning
>> Yep. I have never had a problem with them (dating back to RH 8.0, all
>> on Dell laptops) and this is the first time that I had noted any avc's
>> related to them.
>>
>> I have a script that I ran when I first moved to FC5 to set the
>> following:
>>
>> /usr/sbin/setsebool -P allow_execstack=1
>> /usr/sbin/setsebool -P allow_execmod=1
>>
>> based upon documents that I had found elsewhere.
> That's somewhat overkill and I wouldn't want to do that.
Curiously, that approach is still noted in a variety of places,
including FedoraFaq.org:
http://www.fedorafaq.org/#nvidia
and others:
http://www.mjmwired.net/resources/mjm-fedora-fc5.html#nvidia
http://stanton-finley.net/fedora_core_5_installation_notes.html#nVidia
Though I noted that it has been updated similar to your recommendation
in other places now, including the nVidia forums:
http://www.nvnews.net/vbulletin/showthread.php?t=68681
I did discuss this with Max at fedorafaq and I thought he was going to
update it after he tried it himself. I believe there's a similar issue
with ATI drivers but neither of us have these so we can't test things
for ourselves.
Unfortunately the advice on the nvidia forum suggests using just "chcon"
to change the contexts, so the fix might not survive a relabel (I'm not
sure if customizable types get changed during a relabel). Using semanage
and restorecon should certainly be robust though.
> Undo it with:
> # setsebool -P allow_execstack 0
> # setsebool -P allow_execmod 0
>
> Then fix the file contexts instead:
>
> # semanage fcontext -a -f -- -t textrel_shlib_t
> '/usr/lib/libGL(core)?\.so(\.[^/]*)*'
> # semanage fcontext -a -f -- -t textrel_shlib_t
> '/usr/lib/libnvidia.*\.so(\.[^/]*)*'
> # restorecon -v /usr/lib/libGL* /usr/lib/libnvidia*
>
> Please check that these files have context type textrel_shlib_t after
> doing this.
# ls -lZ /usr/lib/libGL*
lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libGLcore.so.1 ->
libGLcore.so.1.0.8762
-rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/libGLcore.so.1.0.8762
-rw-r--r-- root root root:object_r:lib_t /usr/lib/libGL.la
lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libGL.so ->
libGL.so.1
lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libGL.so.1 ->
libGL.so.1.0.8762
-rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/libGL.so.1.0.8762
lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libGLU.so ->
libGLU.so.1
lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libGLU.so.1 ->
libGLU.so.1.3.060402
-rwxr-xr-x root root system_u:object_r:textrel_shlib_t /usr/lib/libGLU.so.1.3.060402
lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libGLw.so ->
libGLw.so.1
lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libGLw.so.1 ->
libGLw.so.1.0.0
-rwxr-xr-x root root system_u:object_r:lib_t /usr/lib/libGLw.so.1.0.0
# ls -lZ /usr/lib/libnvidia*
lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libnvidia-cfg.so ->
libnvidia-cfg.so.1
lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libnvidia-cfg.so.1 ->
libnvidia-cfg.so.1.0.8762
-rwxr-xr-x root root system_u:object_r:textrel_shlib_t
/usr/lib/libnvidia-cfg.so.1.0.8762
lrwxrwxrwx root root root:object_r:lib_t /usr/lib/libnvidia-tls.so.1 ->
libnvidia-tls.so.1.0.8762
-rwxr-xr-x root root system_u:object_r:textrel_shlib_t
/usr/lib/libnvidia-tls.so.1.0.8762
That looks OK then.
So far, no more avc's, but I'll keep track overnight and
through a
couple of re-boots tomorrow.
Looks like it'll be time to switch back to enforcing mode soon then.
Paul.
11:57 a.m.
New subject: postfix, procmail and SELinux - No Go
Well, after a couple of days and several re-boots, the following is the
only avc so far:
type=AVC msg=audit(1153435170.422:48): avc: denied { search } for pid=15586
comm="clamscan" name="marcs" dev=dm-0 ino=425153
scontext=system_u:system_r:clamscan_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0
tclass=dir
type=SYSCALL msg=audit(1153435170.422:48): arch=40000003 syscall=10 success=no exit=-13
a0=9730020 a1=1 a2=448ce93c a3=972f7e0 items=1 pid=15586 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamscan" exe="/usr/bin/clamscan"
subj=system_u:system_r:clamscan_t:s0
type=CWD msg=audit(1153435170.422:48): cwd="/home/marcs"
type=PATH msg=audit(1153435170.422:48): item=0 name="tnef" parent=58512
dev=fd:02 mode=0100600 ouid=500 ogid=500 rdev=00:00
obj=system_u:object_r:clamscan_tmp_t:s0
I am running in Enforcing mode.
Current policies:
selinux-policy-2.3.2-1.fc5
selinux-policy-targeted-2.3.2-1.fc5
amavis 1.0.5
clamav 1.0.4
dcc 1.0.1
myclamav 0.1.5
mydcc 0.1.9
mypostfix 0.1.1
mypyzor 0.2.3
myspamassassin 0.1.5
procmail 0.5.4
pyzor 1.0.4
razor 1.0.1
Regards,
Marc
12:06 p.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz (via MN) wrote:
Well, after a couple of days and several re-boots, the following is
the
only avc so far:
type=AVC msg=audit(1153435170.422:48): avc: denied { search } for pid=15586
comm="clamscan" name="marcs" dev=dm-0 ino=425153
scontext=system_u:system_r:clamscan_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0
tclass=dir
type=SYSCALL msg=audit(1153435170.422:48): arch=40000003 syscall=10 success=no exit=-13
a0=9730020 a1=1 a2=448ce93c a3=972f7e0 items=1 pid=15586 auid=4294967295 uid=500 gid=500
euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamscan" exe="/usr/bin/clamscan"
subj=system_u:system_r:clamscan_t:s0
type=CWD msg=audit(1153435170.422:48): cwd="/home/marcs"
type=PATH msg=audit(1153435170.422:48): item=0 name="tnef" parent=58512
dev=fd:02 mode=0100600 ouid=500 ogid=500 rdev=00:00
obj=system_u:object_r:clamscan_tmp_t:s0
I am running in Enforcing mode.
It appears to be trying to look in your home directory whilst scanning a
temporary file called "tnef".
The program appears to be running in your home directory, probably since
it's running from your .procmailrc and clamassassin. I wonder if this
can be dontaudited? Any idea whether the scan of this file worked or not?
Paul.
12:22 p.m.
New subject: postfix, procmail and SELinux - No Go
On Fri, 2006-07-21 at 18:06 +0100, Paul Howarth wrote:
Marc Schwartz (via MN) wrote:
> Well, after a couple of days and several re-boots, the following is the
> only avc so far:
>
> type=AVC msg=audit(1153435170.422:48): avc: denied { search } for pid=15586
comm="clamscan" name="marcs" dev=dm-0 ino=425153
scontext=system_u:system_r:clamscan_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0
tclass=dir
> type=SYSCALL msg=audit(1153435170.422:48): arch=40000003 syscall=10 success=no
exit=-13 a0=9730020 a1=1 a2=448ce93c a3=972f7e0 items=1 pid=15586 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamscan" exe="/usr/bin/clamscan"
subj=system_u:system_r:clamscan_t:s0
> type=CWD msg=audit(1153435170.422:48): cwd="/home/marcs"
> type=PATH msg=audit(1153435170.422:48): item=0 name="tnef" parent=58512
dev=fd:02 mode=0100600 ouid=500 ogid=500 rdev=00:00
obj=system_u:object_r:clamscan_tmp_t:s0
>
> I am running in Enforcing mode.
It appears to be trying to look in your home directory whilst scanning a
temporary file called "tnef".
'tnef' files (Transport Neutral Encapsulation Format) are a MIME type
coming from Winders Outlook users. They tend to show up in Evolution as
'winmail.dat' attachments, which then require a tnef viewer such as tnef
or KTnef or similar to open and view:
http://sourceforge.net/projects/tnef
I do occasionally get this from co-workers and others who are on
Windows.
The program appears to be running in your home directory, probably
since
it's running from your .procmailrc and clamassassin. I wonder if this
can be dontaudited? Any idea whether the scan of this file worked or not?
I can confirm that I have received at least one 'tnef' type attachment
in the past 48 hours, which came through to Evo without problem. These
would not normally be picked up as a virus/worm, etc. via scanners.
Marc
12:26 p.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz (via MN) wrote:
On Fri, 2006-07-21 at 18:06 +0100, Paul Howarth wrote:
> Marc Schwartz (via MN) wrote:
>> Well, after a couple of days and several re-boots, the following is the
>> only avc so far:
>>
>> type=AVC msg=audit(1153435170.422:48): avc: denied { search } for pid=15586
comm="clamscan" name="marcs" dev=dm-0 ino=425153
scontext=system_u:system_r:clamscan_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0
tclass=dir
>> type=SYSCALL msg=audit(1153435170.422:48): arch=40000003 syscall=10 success=no
exit=-13 a0=9730020 a1=1 a2=448ce93c a3=972f7e0 items=1 pid=15586 auid=4294967295 uid=500
gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none)
comm="clamscan" exe="/usr/bin/clamscan"
subj=system_u:system_r:clamscan_t:s0
>> type=CWD msg=audit(1153435170.422:48): cwd="/home/marcs"
>> type=PATH msg=audit(1153435170.422:48): item=0 name="tnef" parent=58512
dev=fd:02 mode=0100600 ouid=500 ogid=500 rdev=00:00
obj=system_u:object_r:clamscan_tmp_t:s0
>>
>> I am running in Enforcing mode.
> It appears to be trying to look in your home directory whilst scanning a
> temporary file called "tnef".
'tnef' files (Transport Neutral Encapsulation Format) are a MIME type
coming from Winders Outlook users. They tend to show up in Evolution as
'winmail.dat' attachments, which then require a tnef viewer such as tnef
or KTnef or similar to open and view:
http://sourceforge.net/projects/tnef
I do occasionally get this from co-workers and others who are on
Windows.
> The program appears to be running in your home directory, probably since
> it's running from your .procmailrc and clamassassin. I wonder if this
> can be dontaudited? Any idea whether the scan of this file worked or not?
I can confirm that I have received at least one 'tnef' type attachment
in the past 48 hours, which came through to Evo without problem. These
would not normally be picked up as a virus/worm, etc. via scanners.
I'd expect you to get one of these AVCs for each scanned attachment;
have you only seen the one instance?
Could you try getting it to scan something that should be detected as
"bad" and make sure it works?
Paul.
1:19 p.m.
New subject: postfix, procmail and SELinux - No Go
On Fri, 2006-07-21 at 18:26 +0100, Paul Howarth wrote:
Marc Schwartz (via MN) wrote:
> On Fri, 2006-07-21 at 18:06 +0100, Paul Howarth wrote:
>> Marc Schwartz (via MN) wrote:
>>> Well, after a couple of days and several re-boots, the following is the
>>> only avc so far:
>>>
>>> type=AVC msg=audit(1153435170.422:48): avc: denied { search } for
pid=15586 comm="clamscan" name="marcs" dev=dm-0 ino=425153
scontext=system_u:system_r:clamscan_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0
tclass=dir
>>> type=SYSCALL msg=audit(1153435170.422:48): arch=40000003 syscall=10
success=no exit=-13 a0=9730020 a1=1 a2=448ce93c a3=972f7e0 items=1 pid=15586
auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500
tty=(none) comm="clamscan" exe="/usr/bin/clamscan"
subj=system_u:system_r:clamscan_t:s0
>>> type=CWD msg=audit(1153435170.422:48): cwd="/home/marcs"
>>> type=PATH msg=audit(1153435170.422:48): item=0 name="tnef"
parent=58512 dev=fd:02 mode=0100600 ouid=500 ogid=500 rdev=00:00
obj=system_u:object_r:clamscan_tmp_t:s0
>>>
>>> I am running in Enforcing mode.
>> It appears to be trying to look in your home directory whilst scanning a
>> temporary file called "tnef".
>
> 'tnef' files (Transport Neutral Encapsulation Format) are a MIME type
> coming from Winders Outlook users. They tend to show up in Evolution as
> 'winmail.dat' attachments, which then require a tnef viewer such as tnef
> or KTnef or similar to open and view:
>
> http://sourceforge.net/projects/tnef
>
> I do occasionally get this from co-workers and others who are on
> Windows.
>
>> The program appears to be running in your home directory, probably since
>> it's running from your .procmailrc and clamassassin. I wonder if this
>> can be dontaudited? Any idea whether the scan of this file worked or not?
>
> I can confirm that I have received at least one 'tnef' type attachment
> in the past 48 hours, which came through to Evo without problem. These
> would not normally be picked up as a virus/worm, etc. via scanners.
I'd expect you to get one of these AVCs for each scanned attachment;
have you only seen the one instance?
There has only been one in the past day or two that I can recall.
Could you try getting it to scan something that should be detected as
"bad" and make sure it works?
An incoming external e-mail will be hard. Between the virus filters now
on my personal ISP and those that my company has installed on the
corporate mail server, it is virtually impossible to get one to get in
the pipeline on my system to be scanned by clamav.
Oh wait a minute, presuming that this works properly, mail path wise, I
can use mutt to attach an EICAR signature file and then send that e-mail
to my local user account (ie. marcs@localhost) via the CLI.
OK. That appears to work. I do get the e-mails, with the subject
header re-write "[***** VIRUS *****]" via clamassassin. So if the mail
path of a locally sent e-mail (versus an incoming POP3 msg) is OK, we
are good to go.
OK on the avc's also. The only avc still output is the one that I sent
earlier.
HTH,
Marc
12:23 p.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz (via MN) wrote:
On Fri, 2006-07-21 at 18:26 +0100, Paul Howarth wrote:
> Marc Schwartz (via MN) wrote:
>> On Fri, 2006-07-21 at 18:06 +0100, Paul Howarth wrote:
>>> Marc Schwartz (via MN) wrote:
>>>> Well, after a couple of days and several re-boots, the following is the
>>>> only avc so far:
>>>>
>>>> type=AVC msg=audit(1153435170.422:48): avc: denied { search } for
pid=15586 comm="clamscan" name="marcs" dev=dm-0 ino=425153
scontext=system_u:system_r:clamscan_t:s0 tcontext=user_u:object_r:user_home_dir_t:s0
tclass=dir
>>>> type=SYSCALL msg=audit(1153435170.422:48): arch=40000003 syscall=10
success=no exit=-13 a0=9730020 a1=1 a2=448ce93c a3=972f7e0 items=1 pid=15586
auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500
tty=(none) comm="clamscan" exe="/usr/bin/clamscan"
subj=system_u:system_r:clamscan_t:s0
>>>> type=CWD msg=audit(1153435170.422:48): cwd="/home/marcs"
>>>> type=PATH msg=audit(1153435170.422:48): item=0 name="tnef"
parent=58512 dev=fd:02 mode=0100600 ouid=500 ogid=500 rdev=00:00
obj=system_u:object_r:clamscan_tmp_t:s0
>>>>
>>>> I am running in Enforcing mode.
>>> It appears to be trying to look in your home directory whilst scanning a
>>> temporary file called "tnef".
>> 'tnef' files (Transport Neutral Encapsulation Format) are a MIME type
>> coming from Winders Outlook users. They tend to show up in Evolution as
>> 'winmail.dat' attachments, which then require a tnef viewer such as tnef
>> or KTnef or similar to open and view:
>>
>> http://sourceforge.net/projects/tnef
>>
>> I do occasionally get this from co-workers and others who are on
>> Windows.
>>
>>> The program appears to be running in your home directory, probably since
>>> it's running from your .procmailrc and clamassassin. I wonder if this
>>> can be dontaudited? Any idea whether the scan of this file worked or not?
>> I can confirm that I have received at least one 'tnef' type attachment
>> in the past 48 hours, which came through to Evo without problem. These
>> would not normally be picked up as a virus/worm, etc. via scanners.
> I'd expect you to get one of these AVCs for each scanned attachment;
> have you only seen the one instance?
There has only been one in the past day or two that I can recall.
> Could you try getting it to scan something that should be detected as
> "bad" and make sure it works?
An incoming external e-mail will be hard. Between the virus filters now
on my personal ISP and those that my company has installed on the
corporate mail server, it is virtually impossible to get one to get in
the pipeline on my system to be scanned by clamav.
Oh wait a minute, presuming that this works properly, mail path wise, I
can use mutt to attach an EICAR signature file and then send that e-mail
to my local user account (ie. marcs@localhost) via the CLI.
OK. That appears to work. I do get the e-mails, with the subject
header re-write "[***** VIRUS *****]" via clamassassin. So if the mail
path of a locally sent e-mail (versus an incoming POP3 msg) is OK, we
are good to go.
OK on the avc's also. The only avc still output is the one that I sent
earlier.
Sorry about the delay. Assuming you're getting no further AVCs, we
should now look at cleaning up the custom policy changes and submitting
them to Dan. Is that OK?
Paul.
2:53 p.m.
New subject: postfix, procmail and SELinux - No Go
On Mon, 2006-08-14 at 18:23 +0100, Paul Howarth wrote:
<snip>
Sorry about the delay. Assuming you're getting no further AVCs,
we
should now look at cleaning up the custom policy changes and submitting
them to Dan. Is that OK?
Paul.
Paul,
No problem on timing. I appreciate all of the time that you have spent
with this to date.
At the present time, there are still no further avc's related to this
discussion.
For the sake of re-verifying current status:
# /usr/sbin/semodule -l
amavis 1.0.5
clamav 1.0.4
dcc 1.0.1
myclamav 0.1.5
mydcc 0.1.9
mypostfix 0.1.1
mypyzor 0.2.3
myspamassassin 0.1.5
procmail 0.5.4
pyzor 1.0.4
razor 1.0.1
and
# rpm -qa | grep selinux
libselinux-1.30.3-4.fc5
libselinux-python-1.30.3-4.fc5
selinux-policy-targeted-2.3.3-8.fc5
libselinux-devel-1.30.3-4.fc5
selinux-policy-2.3.3-8.fc5
Best regards,
Marc
4:04 p.m.
New subject: postfix, procmail and SELinux - No Go
On Sun, 2006-06-25 at 09:40 +0100, Paul Howarth wrote:
On Sat, 2006-06-24 at 17:40 -0500, Marc Schwartz wrote:
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?
See my other reply to you and Nicolas.
> 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.
Yep. :-)
<Lot's of snippage>
After loading the updated modules, you'll need to do:
# restorecon -rv /var/dcc
Done and new mydcc policy installed:
# semodule -l
amavis 1.0.4
clamav 1.0.1
dcc 1.0.0
myclamav 0.1.1
mydcc 0.1.6
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 avc's:
type=AVC msg=audit(1151269000.770:5837): avc: denied { search } for pid=23000
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(1151269000.770:5837): arch=40000003 syscall=12 success=yes exit=0
a0=bfdb1202 a1=0 a2=4891eff4 a3=37 items=1 pid=23000 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:spamd_t:s0
type=CWD msg=audit(1151269000.770:5837): cwd="/"
type=PATH msg=audit(1151269000.770:5837): item=0 name="/var/dcc" inode=58510
dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:dcc_var_t:s0
type=AVC msg=audit(1151269000.770:5838): avc: denied { read write } for pid=23000
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(1151269000.770:5838): arch=40000003 syscall=5 success=yes exit=3
a0=80ba6e0 a1=2 a2=180 a3=37 items=1 pid=23000 auid=4294967295 uid=500 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=500 fsgid=0 tty=(none) comm="dccproc"
exe="/usr/local/bin/dccproc" subj=system_u:system_r:spamd_t:s0
type=CWD msg=audit(1151269000.770:5838): cwd="/var/dcc"
type=PATH msg=audit(1151269000.770:5838): item=0 name="/var/dcc/map" inode=59007
dev=fd:01 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:dcc_client_map_t:s0
type=AVC msg=audit(1151269000.770:5839): avc: denied { getattr } for pid=23000
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(1151269000.770:5839): arch=40000003 syscall=197 success=yes exit=0
a0=3 a1=bfdb1018 a2=4891eff4 a3=3 items=0 pid=23000 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:spamd_t:s0
type=AVC_PATH msg=audit(1151269000.770:5839): path="/var/dcc/map"
type=AVC msg=audit(1151269000.770:5840): avc: denied { lock } for pid=23000
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(1151269000.770:5840): arch=40000003 syscall=221 success=yes exit=0
a0=3 a1=7 a2=bfdb2194 a3=bfdb2194 items=0 pid=23000 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:spamd_t:s0
type=AVC_PATH msg=audit(1151269000.770:5840): path="/var/dcc/map"
Thanks,
Marc
6:31 a.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz wrote:
After loading the updated modules, you'll need to do:
>
> # restorecon -rv /var/dcc
Done and new mydcc policy installed:
# semodule -l
amavis 1.0.4
clamav 1.0.1
dcc 1.0.0
myclamav 0.1.1
mydcc 0.1.6
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 avc's:
type=AVC msg=audit(1151269000.770:5837): avc: denied { search } for pid=23000
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(1151269000.770:5837): arch=40000003 syscall=12 success=yes exit=0
a0=bfdb1202 a1=0 a2=4891eff4 a3=37 items=1 pid=23000 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:spamd_t:s0
type=CWD msg=audit(1151269000.770:5837): cwd="/"
type=PATH msg=audit(1151269000.770:5837): item=0 name="/var/dcc" inode=58510
dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:dcc_var_t:s0
dccproc is still running in the spamd_t domain; for some reason the
domain transition hasn't happened.
Can you check that the dccproc being invoked by spamassassin is the one
in /usr/local/bin and that its context type is dcc_client_exec_t?
Paul.
12:47 p.m.
New subject: postfix, procmail and SELinux - No Go
On Mon, 2006-06-26 at 12:31 +0100, Paul Howarth wrote:
Marc Schwartz wrote:
> After loading the updated modules, you'll need to do:
>>
>> # restorecon -rv /var/dcc
>
> Done and new mydcc policy installed:
>
> # semodule -l
> amavis 1.0.4
> clamav 1.0.1
> dcc 1.0.0
> myclamav 0.1.1
> mydcc 0.1.6
> 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 avc's:
>
> type=AVC msg=audit(1151269000.770:5837): avc: denied { search } for pid=23000
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(1151269000.770:5837): arch=40000003 syscall=12 success=yes
exit=0 a0=bfdb1202 a1=0 a2=4891eff4 a3=37 items=1 pid=23000 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:spamd_t:s0
> type=CWD msg=audit(1151269000.770:5837): cwd="/"
> type=PATH msg=audit(1151269000.770:5837): item=0 name="/var/dcc"
inode=58510 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:dcc_var_t:s0
dccproc is still running in the spamd_t domain; for some reason the
domain transition hasn't happened.
Can you check that the dccproc being invoked by spamassassin is the one
in /usr/local/bin and that its context type is dcc_client_exec_t?
dccproc only exists in two locations:
/var/dcc/build/dcc/dccproc/dccproc
and
/usr/local/bin/dccproc
The former is where dcc does it's build each night.
It was:
user_u:object_r:bin_t
I ran restorecon on it and now:
system_u:object_r:dcc_client_exec_t
However, thinking that the build process might change the context, I
manually ran updatedcc via sudo from the CLI. Sure enough, the context
is back to:
user_u:object_r:bin_t
So the change in context will occur every night. :-(
Should I add a restorecon to crontab after updatedcc runs?
Also, there is some configuration info here:
http://www.rhyolite.com/anti-spam/dcc/dcc-tree/INSTALL.html
where some settings (ie. UID) might be apropos here. If something makes
sense to change, let me know.
I will reply to your other mail shortly. I made some changes to the
razor and pyzor configs that will take a bit to write up, but appear to
address the multiple user folder locations.
Thanks,
Marc
4:56 p.m.
New subject: postfix, procmail and SELinux - No Go
On Mon, 2006-06-26 at 12:47 -0500, Marc Schwartz (via MN) wrote:
On Mon, 2006-06-26 at 12:31 +0100, Paul Howarth wrote:
> Marc Schwartz wrote:
> > After loading the updated modules, you'll need to do:
> >>
> >> # restorecon -rv /var/dcc
> >
> > Done and new mydcc policy installed:
> >
> > # semodule -l
> > amavis 1.0.4
> > clamav 1.0.1
> > dcc 1.0.0
> > myclamav 0.1.1
> > mydcc 0.1.6
> > 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 avc's:
> >
> > type=AVC msg=audit(1151269000.770:5837): avc: denied { search } for
pid=23000 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(1151269000.770:5837): arch=40000003 syscall=12
success=yes exit=0 a0=bfdb1202 a1=0 a2=4891eff4 a3=37 items=1 pid=23000 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:spamd_t:s0
> > type=CWD msg=audit(1151269000.770:5837): cwd="/"
> > type=PATH msg=audit(1151269000.770:5837): item=0 name="/var/dcc"
inode=58510 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:dcc_var_t:s0
>
> dccproc is still running in the spamd_t domain; for some reason the
> domain transition hasn't happened.
>
> Can you check that the dccproc being invoked by spamassassin is the one
> in /usr/local/bin and that its context type is dcc_client_exec_t?
dccproc only exists in two locations:
/var/dcc/build/dcc/dccproc/dccproc
and
/usr/local/bin/dccproc
The former is where dcc does it's build each night.
It was:
user_u:object_r:bin_t
I ran restorecon on it and now:
system_u:object_r:dcc_client_exec_t
However, thinking that the build process might change the context, I
manually ran updatedcc via sudo from the CLI. Sure enough, the context
is back to:
user_u:object_r:bin_t
So the change in context will occur every night. :-(
Should I add a restorecon to crontab after updatedcc runs?
Yes.
Also, there is some configuration info here:
http://www.rhyolite.com/anti-spam/dcc/dcc-tree/INSTALL.html
where some settings (ie. UID) might be apropos here. If something makes
sense to change, let me know.
It looks tricky. There's one script that both compiles and then installs
the updated version. It only needs to be root to do the install, and
would need changing to split the functionality.
Paul.
10:06 p.m.
New subject: postfix, procmail and SELinux - No Go
On Mon, 2006-06-26 at 22:56 +0100, Paul Howarth wrote:
On Mon, 2006-06-26 at 12:47 -0500, Marc Schwartz (via MN) wrote:
>
<snip>
> > Can you check that the dccproc being invoked by
spamassassin is the one
> > in /usr/local/bin and that its context type is dcc_client_exec_t?
>
> dccproc only exists in two locations:
>
> /var/dcc/build/dcc/dccproc/dccproc
>
> and
>
> /usr/local/bin/dccproc
>
> The former is where dcc does it's build each night.
>
>
> It was:
>
> user_u:object_r:bin_t
>
> I ran restorecon on it and now:
>
> system_u:object_r:dcc_client_exec_t
>
>
> However, thinking that the build process might change the context, I
> manually ran updatedcc via sudo from the CLI. Sure enough, the context
> is back to:
>
> user_u:object_r:bin_t
>
> So the change in context will occur every night. :-(
>
> Should I add a restorecon to crontab after updatedcc runs?
Yes.
Done. This takes place 10 minutes after updatedcc runs, in case there is
some delay in the download. I moved the pyzor update to 1:15 am and the
razor update stays at 1:20 am.
> Also, there is some configuration info here:
>
> http://www.rhyolite.com/anti-spam/dcc/dcc-tree/INSTALL.html
>
> where some settings (ie. UID) might be apropos here. If something makes
> sense to change, let me know.
It looks tricky. There's one script that both compiles and then installs
the updated version. It only needs to be root to do the install, and
would need changing to split the functionality.
Agreed. Without fundamentally changing the script, this would be
problematic.
Thanks,
Marc
10:39 a.m.
New subject: postfix, procmail and SELinux - No Go
Marc Schwartz wrote:
On Mon, 2006-06-26 at 22:56 +0100, Paul Howarth wrote:
> On Mon, 2006-06-26 at 12:47 -0500, Marc Schwartz (via MN) wrote:
<snip>
>>> Can you check that the dccproc being invoked by spamassassin is the one
>>> in /usr/local/bin and that its context type is dcc_client_exec_t?
>> dccproc only exists in two locations:
>>
>> /var/dcc/build/dcc/dccproc/dccproc
>>
>> and
>>
>> /usr/local/bin/dccproc
>>
>> The former is where dcc does it's build each night.
>>
>>
>> It was:
>>
>> user_u:object_r:bin_t
>>
>> I ran restorecon on it and now:
>>
>> system_u:object_r:dcc_client_exec_t
>>
>>
>> However, thinking that the build process might change the context, I
>> manually ran updatedcc via sudo from the CLI. Sure enough, the context
>> is back to:
>>
>> user_u:object_r:bin_t
>>
>> So the change in context will occur every night. :-(
>>
>> Should I add a restorecon to crontab after updatedcc runs?
> Yes.
Done. This takes place 10 minutes after updatedcc runs, in case there is
some delay in the download. I moved the pyzor update to 1:15 am and the
razor update stays at 1:20 am.
>> Also, there is some configuration info here:
>>
>> http://www.rhyolite.com/anti-spam/dcc/dcc-tree/INSTALL.html
>>
>> where some settings (ie. UID) might be apropos here. If something makes
>> sense to change, let me know.
> It looks tricky. There's one script that both compiles and then installs
> the updated version. It only needs to be root to do the install, and
> would need changing to split the functionality.
Agreed. Without fundamentally changing the script, this would be
problematic.
I think a better updating option would be to get dcc into a third-party
repository and use the usual yum method to update the software.
Whilst it's not free software and hence unsuitable for Extras, I don't
think the license would prevent it being packaged somewhere else.
Paul.
4:35 p.m.
New subject: postfix, procmail and SELinux - No Go
Ok if you guys have this all working, I would like to grab your policy
modules and merge them so upstream can get them.
2:27 a.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-06-20 at 17:35 -0400, Daniel J Walsh wrote:
Ok if you guys have this all working, I would like to grab your
policy
modules and merge them so upstream can get them.
It's not ready yet.
Firstly, there are a bunch of things currently allowed by the policy
that we don't yet understand (such as why the postfix master program
wants to read the attributes of one of its own manpages). I'd like to
know what, if anything, breaks if these curious things are not allowed.
Secondly, I think that clamassassin needs its own domain. Currently it
starts running in the procmail domain, makes a temp file of the message
to be scanned (which will be procmail_tmp_t) and then has clamscan scan
the file (so clamscan needs to be able to read procmail_tmp_t files). If
clamassassin had its own domain, the temp file could be written as
clamscan_tmp_t, which would be much better.
Paul.
9:23 a.m.
New subject: postfix, procmail and SELinux - No Go
Paul Howarth wrote:
On Tue, 2006-06-20 at 17:35 -0400, Daniel J Walsh wrote:
> Ok if you guys have this all working, I would like to grab your policy
> modules and merge them so upstream can get them.
>
It's not ready yet.
Firstly, there are a bunch of things currently allowed by the policy
that we don't yet understand (such as why the postfix master program
wants to read the attributes of one of its own manpages). I'd like to
know what, if anything, breaks if these curious things are not allowed.
Secondly, I think that clamassassin needs its own domain. Currently it
starts running in the procmail domain, makes a temp file of the message
to be scanned (which will be procmail_tmp_t) and then has clamscan scan
the file (so clamscan needs to be able to read procmail_tmp_t files). If
clamassassin had its own domain, the temp file could be written as
clamscan_tmp_t, which would be much better.
Paul.
OK when you have it working the way you want we can merge it in.
8:06 a.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-06-20 at 07:54 -0500, Marc Schwartz wrote:
What is interesting, is if I try to remove any of the existing
modules,
I get this:
# semodule -r myclam.pp
libsemanage.semanage_direct_remove: Module myclam.pp was not found.
semodule: Failed on myclam.pp!
semodule -r myclam
-r operates on the module name, as declared within the module, since the
module is already installed and known to the system.
-i operates on the file name, since it has to read in the module
contents from the file and install it.
Thus, -r wouldn't use the .pp suffix, whereas -i would.
If you would like me to attach the *.pp files in an offlist e-mail
so
that you can review them, let me know.
Yes, along with the {.te,.fc,.if} files too.
--
Stephen Smalley
National Security Agency
8:20 a.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-06-20 at 09:06 -0400, Stephen Smalley wrote:
On Tue, 2006-06-20 at 07:54 -0500, Marc Schwartz wrote:
> What is interesting, is if I try to remove any of the existing modules,
> I get this:
>
> # semodule -r myclam.pp
> libsemanage.semanage_direct_remove: Module myclam.pp was not found.
> semodule: Failed on myclam.pp!
semodule -r myclam
-r operates on the module name, as declared within the module, since the
module is already installed and known to the system.
-i operates on the file name, since it has to read in the module
contents from the file and install it.
Thus, -r wouldn't use the .pp suffix, whereas -i would.
I'm an idiot. Should have figured that.
> If you would like me to attach the *.pp files in an offlist
e-mail so
> that you can review them, let me know.
Yes, along with the {.te,.fc,.if} files too.
I'm going to reply to Paul's follow up here, as I think we may have
solved at least a core part of the problem with the re-load of the RPMS.
I'll hold on sending the files pending further discussion on that.
Thanks,
Marc
8:02 a.m.
New subject: postfix, procmail and SELinux - No Go
On Tue, 2006-06-20 at 13:26 +0100, Paul Howarth wrote:
Stephen Smalley wrote:
> On Tue, 2006-06-20 at 08:08 +0100, Paul Howarth wrote:
>> On Mon, 2006-06-19 at 15:34 -0500, Marc Schwartz (via MN) wrote:
>>> Thanks Paul!
>>>
>>> OK, so the building goes OK, but now when I try to install the modules,
>>> I get the following error:
>>>
>>> # /usr/sbin/semodule -i procmail.pp
>>> libsepol.class_copy_callback: procmail: Modules may not yet declare new
classes.
>>> libsemanage.semanage_link_sandbox: Link packages failed
>>> /usr/sbin/semodule: Failed!
>>>
>>>
>>> This occurs with each of the 5 modules.
>>>
>>> Due to the recent change as well or is there something else that I need
>>> to do before installing the new module(s)?
>> Not sure what that is. Can you try rebuilding all of the modules?
>>
>> # rm *.pp
>> # make
>>
>> Paul.
>
> Also make sure that your selinux-policy package is fully up-to-date.
> The error message suggests that your modules are bringing in newer class
> definitions (via policy_module) that aren't defined in your base.pp,
> which means your base.pp is out of date.
How could this happen if the modules are being built on the same system
as they are being used on?
Good question - you are correct, that should only happen in the case
where they are built on a different system (with more up-to-date policy)
than the destination system.
--
Stephen Smalley
National Security Agency
3:16 p.m.
New subject: postfix, procmail and SELinux - No Go
On Wed, 2006-06-07 at 12:20 -0400, Daniel J Walsh wrote:
I will be turning on dcc and razor policy in next rawhide update.
This
should cover some of the problems you are having. Please send
me all of your policy so that I can get it in the upstream pool.
Are the policies due to be enabled the same ones that are in
selinux-policy-2.2.40-1.fc5 but not enabled? If not, can you post a URL
to the policies that are going to be added so that Mark can try them
out?
Paul.
6465
days inactive
6533
days old
selinux@lists.fedoraproject.org
104 comments
8 participants
participants (8)
-
Daniel J Walsh -
lonely wolf -
Marc Schwartz -
Marc Schwartz (via MN)
-
Nicolas Mailhot -
Nicolas Mailhot
-
Paul Howarth -
Stephen Smalley