postfix, procmail and SELinux - No Go

Wed Jul 5 18:58:39 UTC 2006

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