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.
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
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.
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
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.
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... :-) >
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 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
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 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
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
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
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
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
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.
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
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.
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
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.
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 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.
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
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.
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
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
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
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.
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
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.
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
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 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
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
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.
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
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.
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
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.
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
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) ')
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
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
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.
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
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.
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
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
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
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.
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
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.
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
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.
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 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 ?
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.
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:
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
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,
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:
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:
- 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
- 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.
- 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.
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:
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:
- 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
- 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.
- 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
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.
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
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
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.
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
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.
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
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.
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
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.
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
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.
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
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
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.
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
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.
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
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.
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="/"
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.
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
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.
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
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:
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.
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
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.
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
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.
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
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.
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
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
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.
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
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.
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
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.
Ok if you guys have this all working, I would like to grab your policy modules and merge them so upstream can get them.
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.
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.
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.
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
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.
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.
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
lonely wolf -
Marc Schwartz -
Marc Schwartz (via MN)
-
Nicolas Mailhot -
Nicolas Mailhot
-
Paul Howarth -
Stephen Smalley