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