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.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
