Bug 504260

Summary: selinux warnings for "/" from dccproc, pyzor, file under amavisd/postfix
Product: [Fedora] Fedora Reporter: Ian Donaldson <iand>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 10CC: dwalsh, eparis, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-18 13:00:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ian Donaldson 2009-06-05 07:54:22 UTC
Description of problem:

Running amavisd with razor, pyzor, dcc, spamassassin, clamav, postfix, sqlgrey...

See these in kernel log for each message processed

Jun  5 07:25:36 SYSTEM kernel: type=1400 audit(1244186736.424:58): avc:  denied  { getattr } for  pid=18985 comm="pyzor" name="/" dev=dm-0 ino=2 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem

Jun  5 07:25:36 SYSTEM kernel: type=1400 audit(1244186736.802:59): avc:  denied  { getattr } for  pid=18986 comm="dccproc" name="/" dev=dm-0 ino=2 scontext=system_u:system_r:amavis_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem

Jun  5 07:33:48 SYSTEM kernel: type=1400 audit(1244187228.214:60): avc:  denied  { getattr } for  pid=19131 comm="file" name="/" dev=dm-0 ino=2 scontext=system_u:system_r:amavis_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem


however inbound email _appears_ to be processed ok.


Version-Release number of selected component (if applicable):

These from very up-to-date FC10:

	selinux-policy-3.5.13-59.fc10.noarch
	pyzor-0.4.0-11.fc7.noarch
	amavisd-new-2.5.2-3.fc10.noarch
	perl-Razor-Agent-2.85-1.fc10.i386
	postfix-2.5.6-1.fc10.i386
	sqlgrey-1.7.6-1.fc10.noarch

and locally installed dcc-1.3.105

How reproducible:

100%


Steps to Reproduce:
1. inspection of kernel log
2.
3.
  
Actual results:


Expected results:


Additional info:

Tried making selinux exceptions for these rules; though an exception 
for "/" seems unsafe, but these failed to install...

# cat amavis.te 

module amavis 1.0;

require {
        type spamc_t;
        type amavis_t;
        type fs_t;
        class filesystem getattr;
}

#============= amavis_t ==============
allow amavis_t fs_t:filesystem getattr;

#============= spamc_t ==============
allow spamc_t fs_t:filesystem getattr;

# semodule -i amavis.pp
libsepol.print_missing_requirements: amavis's global requirements were not met: type/attribute amavis_t
libsemanage.semanage_link_sandbox: Link packages failed
semodule:  Failed!

# ps -Zef |grep amav
system_u:system_r:clamd_t:s0    amavis    2487     1  0 Jun01 ?        00:00:42 clamd.amavisd -c /etc/clamd.d/amavisd.conf
system_u:system_r:amavis_t:s0   amavis    2538     1  0 Jun01 ?        00:00:05 amavisd (master)                                               
system_u:system_r:amavis_t:s0   amavis    2632  2538  0 Jun01 ?        00:00:09 amavisd (ch13-avail)                                           
system_u:system_r:amavis_t:s0   amavis   18855  2538  0 07:17 ?        00:00:07 amavisd (ch11-avail)                                           
system_u:system_r:amavis_t:s0   amavis   19168  2538  0 07:35 ?        00:00:01 amavisd (ch3-avail)

Comment 1 Daniel Walsh 2009-06-05 15:23:21 UTC
If you make a modified policy you must not name it with the existing name.  So name the policy myamavis.te and myamavis.pp

The failure is because you are replacing the existing amavis.pp


The real question is why are the tools suddenly trying to getattr on the filesystem?  

Any chance you are running out of space on /?  

Can you grab the full output of ausearch -m avc, so we can see the other parts of the AVC message.

Comment 2 Ian Donaldson 2009-06-08 09:58:24 UTC
Ok, thanks.  Wasn't aware of the duplicate policy names; the error
message didn't really give direct hints about that...


As to whether there is a space issue on /, no.  17G free there.


There is however a mismatch with the FC10 supplied policy and my dcc install.
I compiled dcc-1.3.105 with no args to 'configure'.

Policy before...

# semanage fcontext -l | grep dcc
/etc/dcc(/.*)?                                     all files          system_u:object_r:dcc_var_t:s0
/etc/dcc/dccifd                                    socket             system_u:object_r:dccifd_var_run_t:s0
/etc/dcc/map                                       regular file       system_u:object_r:dcc_client_map_t:s0
/usr/bin/cdcc                                      regular file       system_u:object_r:cdcc_exec_t:s0
/usr/bin/dccproc                                   regular file       system_u:object_r:dcc_client_exec_t:s0
/usr/libexec/dcc/dbclean                           regular file       system_u:object_r:dcc_dbclean_exec_t:s0
/usr/libexec/dcc/dccd                              regular file       system_u:object_r:dccd_exec_t:s0
/usr/libexec/dcc/dccifd                            regular file       system_u:object_r:dccifd_exec_t:s0
/usr/libexec/dcc/dccm                              regular file       system_u:object_r:dccm_exec_t:s0
/usr/libexec/dcc/start-.*                          regular file       system_u:object_r:initrc_exec_t:s0
/usr/libexec/dcc/stop-.*                           regular file       system_u:object_r:initrc_exec_t:s0
/usr/libexec/hal-dccm                              regular file       system_u:object_r:hald_dccm_exec_t:s0
/var/dcc(/.*)?                                     all files          system_u:object_r:dcc_var_t:s0
/var/dcc/map                                       regular file       system_u:object_r:dcc_client_map_t:s0
/var/lib/dcc(/.*)?                                 all files          system_u:object_r:dcc_var_t:s0
/var/lib/dcc/map                                   regular file       system_u:object_r:dcc_client_map_t:s0
/var/run/dcc(/.*)?                                 all files          system_u:object_r:dcc_var_run_t:s0
/var/run/dcc/dccifd                                socket             system_u:object_r:dccifd_var_run_t:s0
/var/run/dcc/map                                   regular file       system_u:object_r:dcc_client_map_t:s0


# ll /usr/bin/dccproc
/bin/ls: cannot access /usr/bin/dccproc: No such file or directory
# ll /usr/local/bin/dccproc 
-r-sr-xr-x 1 root bin 490312 May 31 11:12 /usr/local/bin/dccproc
# ll -Z /usr/local/bin/dccproc
-r-sr-xr-x  root bin unconfined_u:object_r:bin_t:s0   /usr/local/bin/dccproc


So I've modified my policy, to emulate the FC10 dcc related policy
using my dcc's default paths:

semanage fcontext -a -t dcc_client_exec_t /usr/local/bin/dccproc 
restorecon /usr/local/bin/dccproc

semanage fcontext -a -t amavis_spool_t /var/dcc
semanage fcontext -a -t amavis_spool_t '/var/dcc(/.*)?'

semanage fcontext -a -t cdcc_exec_t  /usr/local/bin/cdcc
restorecon /usr/local/bin/cdcc

semanage fcontext -a -t dcc_dbclean_exec_t /var/dcc/libexec/dbclean
semanage fcontext -a -t dccd_exec_t        /var/dcc/libexec/dccd
semanage fcontext -a -t dccifd_exec_t      /var/dcc/libexec/dccifd
semanage fcontext -a -t dccm_exec_t        /var/dcc/libexec/dccm
semanage fcontext -a -t initrc_exec_t     '/var/dcc/libexec/start-.*'
semanage fcontext -a -t initrc_exec_t     '/var/dcc/libexec/stop-.*'                     
restorecon -R /var/dcc/libexec

and added a module to fix up the startup issues.

# cat dcc2.te

module dcc2 1.0;

require {
        type amavis_spool_t;
        type dcc_var_t;
        type dcc_client_t;
        class dir { write add_name };
        class file { write read create getattr };
}

#============= dcc_client_t ==============
allow dcc_client_t amavis_spool_t:file { read getattr };
allow dcc_client_t dcc_var_t:dir { write add_name };
allow dcc_client_t dcc_var_t:file { write create };


based on this:

	type=SYSCALL msg=audit(1244452113.405:267): arch=40000003 syscall=11 success=yes exit=0 a0=bb797fc a1=a39e39c a2=bc93e90 a3=b368fac items=0 ppid=3984 pid=4332 auid=143 uid=493 gid=492 euid=0 suid=0 fsuid=0 egid=492 sgid=492 fsgid=492 tty=(none) ses=1 comm="dccproc" exe="/usr/local/bin/dccproc" subj=unconfined_u:system_r:dcc_client_t:s0 key=(null)

	type=AVC msg=audit(1244452113.405:267): avc:  denied  { read } for  pid=4332 comm="dccproc" path="/var/spool/amavisd/tmp/.spamassassin3984yERxILtmp" dev=dm-0 ino=156072 scontext=unconfined_u:system_r:dcc_client_t:s0 tcontext=unconfined_u:object_r:amavis_spool_t:s0 tclass=file

	type=SYSCALL msg=audit(1244452113.411:268): arch=40000003 syscall=5 success=no exit=-13 a0=80bd524 a1=8002 a2=0 a3=8002 items=0 ppid=3984 pid=4332 auid=143 uid=493 gid=492 euid=0 suid=0 fsuid=0 egid=492 sgid=492 fsgid=492 tty=(none) ses=1 comm="dccproc" exe="/usr/local/bin/dccproc" subj=unconfined_u:system_r:dcc_client_t:s0 key=(null)

	type=AVC msg=audit(1244452113.411:275): avc:  denied  { write } for  pid=4332 comm="dccproc" name="dcc" dev=dm-0 ino=139280 scontext=unconfined_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:dcc_var_t:s0 tclass=dir


	type=SYSCALL msg=audit(1244452399.324:448): arch=40000003 syscall=5 success=no exit=-13 a0=80bdbc4 a1=8042 a2=1b6 a3=8042 items=0 ppid=4432 pid=4435 auid=143 uid=493 gid=492 euid=0 suid=0 fsuid=0 egid=492 sgid=492 fsgid=492 tty=(none) ses=1 comm="dccproc" exe="/usr/local/bin/dccproc" subj=unconfined_u:system_r:dcc_client_t:s0 key=(null)

	type=AVC msg=audit(1244452399.324:448): avc:  denied  { add_name } for  pid=4435 comm="dccproc" name="whitelist.dccx" scontext=unconfined_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:dcc_var_t:s0 tclass=dir

	type=SYSCALL msg=audit(1244452399.327:449): arch=40000003 syscall=197 success=no exit=-13 a0=0 a1=bfe40558 a2=27fff4 a3=280420 items=0 ppid=4432 pid=4435 auid=143 uid=493 gid=492 euid=493 suid=0 fsuid=493 egid=492 sgid=492 fsgid=492 tty=(none) ses=1 comm="dccproc" exe="/usr/local/bin/dccproc" subj=unconfined_u:system_r:dcc_client_t:s0 key=(null)

	type=AVC msg=audit(1244452399.327:449): avc:  denied  { getattr } for  pid=4435 comm="dccproc" path="/var/spool/amavisd/tmp/.spamassassin4432uT2xTOtmp" dev=dm-0 ino=156070 scontext=unconfined_u:system_r:dcc_client_t:s0 tcontext=unconfined_u:object_r:amavis_spool_t:s0 tclass=file

	type=SYSCALL msg=audit(1244453674.406:579): arch=40000003 syscall=5 success=no exit=-13 a0=80bdbc4 a1=8042 a2=1b6 a3=8042 items=0 ppid=5076 pid=5089 auid=143 uid=493 gid=492 euid=0 suid=0 fsuid=0 egid=492 sgid=492 fsgid=492 tty=(none) ses=1 comm="dccproc" exe="/usr/local/bin/dccproc" subj=unconfined_u:system_r:dcc_client_t:s0 key=(null)

	type=AVC msg=audit(1244453674.406:579): avc:  denied  { create } for  pid=5089 comm="dccproc" name="whitelist.dccx" scontext=unconfined_u:system_r:dcc_client_t:s0 tcontext=unconfined_u:object_r:dcc_var_t:s0 tclass=file

	type=SYSCALL msg=audit(1244453925.860:590): arch=40000003 syscall=5 success=no exit=-13 a0=80bdbc4 a1=8042 a2=1b6 a3=8042 items=0 ppid=5158 pid=5161 auid=143 uid=493 gid=492 euid=0 suid=0 fsuid=0 egid=492 sgid=492 fsgid=492 tty=(none) ses=1 comm="dccproc" exe="/usr/local/bin/dccproc" subj=unconfined_u:system_r:dcc_client_t:s0 key=(null)

	type=AVC msg=audit(1244453925.860:590): avc:  denied  { write } for  pid=5161 comm="dccproc" name="whitelist.dccx" dev=dm-0 ino=139782 scontext=unconfined_u:system_r:dcc_client_t:s0 tcontext=unconfined_u:object_r

	type=SYSCALL msg=audit(1244454011.843:628): arch=40000003 syscall=5 success=no exit=-13 a0=80bd524 a1=8002 a2=0 a3=8002 items=0 ppid=5162 pid=5280 auid=143 uid=493 gid=492 euid=0 suid=0 fsuid=0 egid=492 sgid=492 fsgid=492 tty=(none) ses=1 comm="dccproc" exe="/usr/local/bin/dccproc" subj=unconfined_u:system_r:dcc_client_t:s0 key=(null)

	type=AVC msg=audit(1244454011.843:628): avc:  denied  { write } for  pid=5280 comm="dccproc" name="whitelist.dccw" dev=dm-0 ino=139352 scontext=unconfined_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:dcc_var_t:s0 tclass=file


However I'm still seeing these:


        time->Mon Jun  8 09:42:41 2009
        type=AVC msg=audit(1244454161.196:646): avc:  denied  { getattr } for  pid=5333 comm="pyzor" name="/" dev=dm-0 ino=2 scontext=unconfined_u:system_r:spamc_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem
        ----
        time->Mon Jun  8 09:42:41 2009
        type=AVC msg=audit(1244454161.612:656): avc:  denied  { getattr } for  pid=5334 comm="dccproc" name="/" dev=dm-0 ino=2 scontext=unconfined_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem
        ----
        time->Mon Jun  8 09:50:05 2009
        type=AVC msg=audit(1244454605.600:665): avc:  denied  { getattr } for  pid=5424 comm="file" name="/" dev=dm-0 ino=2 scontext=unconfined_u:system_r:amavis_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem
        ----
        time->Mon Jun  8 09:50:11 2009
        type=AVC msg=audit(1244454611.915:666): avc:  denied  { getattr } for  pid=5426 comm="pyzor" name="/" dev=dm-0 ino=2 scontext=unconfined_u:system_r:spamc_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem
        ----
        time->Mon Jun  8 09:51:37 2009
        type=AVC msg=audit(1244454697.635:667): avc:  denied  { getattr } for  pid=5446 comm="file" name="/" dev=dm-0 ino=2 scontext=unconfined_u:system_r:amavis_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem
        ----
        time->Mon Jun  8 09:51:42 2009
        type=AVC msg=audit(1244454702.250:669): avc:  denied  { getattr } for  pid=5449 comm="dccproc" name="/" dev=dm-0 ino=2 scontext=unconfined_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem
        ----
        time->Mon Jun  8 09:51:41 2009
        type=AVC msg=audit(1244454701.895:668): avc:  denied  { getattr } for  pid=5448 comm="pyzor" name="/" dev=dm-0 ino=2 scontext=unconfined_u:system_r:spamc_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem
        
(which is what you were after)

Comment 3 Ian Donaldson 2009-06-08 11:12:47 UTC
correction; I had these in there but have since reverted.. to using dcc_var_t

semanage fcontext -a -t amavis_spool_t /var/dcc
semanage fcontext -a -t amavis_spool_t '/var/dcc(/.*)?'

Comment 4 Ian Donaldson 2009-06-09 04:32:04 UTC
Ok, I've tracked down some of this (I think)... running spamassassin -t -e on
a message that triggers the above when run thru amavisd reveals:

18992 execve("/usr/bin/spamassassin", ["spamassassin", "-t", "-e"], [/* 49 vars */]) = 0
18992 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f5a6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
18992 read(3, "#!/usr/bin/perl -T -w\n\neval 'exec"..., 4096) = 4096
18992 read(7, " build a new perl executable whic"..., 4096) = 4096
18993 execve("/usr/bin/pyzor", ["/usr/bin/pyzor", "check"], [/* 47 vars */]) = 0
18993 set_thread_area({entry_number:-1 -> 6, base_addr:0xb807e6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
18994 execve("/usr/local/bin/dccproc", ["/usr/local/bin/dccproc", "-H", "-x", "0", "-a", "68.142.199.252", "-R", "-w", "whitelist"], [/* 47 vars */]) = 0
18994 set_thread_area({entry_number:-1 -> 6, base_addr:0xb80cb6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0

so I'm assuming that selinux is preventing the getattr on "/" from
the above exec paths.

However this doesn't appear to be preventing pyzor and dcc from working;
I have lots of evidence that they are ok as they show up in /var/log/maillog
and in quarantined messages.

amavisd also likes to exec /usr/bin/file and (from inspection of source)
/usr/bin/altermime to determine attachment types, which is probably
related to the selinux "file" mention.

Comment 5 Daniel Walsh 2009-06-09 11:20:33 UTC
Ok what is the bottom line.

Looks like we need to add

optional_policy(`
	amavis_read_spool_files(dcc_client_t)
')

fs_getattr_xattr_fs(spamc_t)
fs_getattr_xattr_fs(amavis_t)
fs_getattr_xattr_fs(dcc_client_t)
manage_files_pattern(dcc_client_t, dcc_var_t, dcc_var_t)

Comment 6 Miroslav Grepl 2009-06-11 11:15:38 UTC
Fixed in selinux-policy-3.5.13-64.fc10

Comment 7 Bug Zapper 2009-11-18 12:53:12 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 Daniel Walsh 2009-11-18 13:00:49 UTC
Closing as current release