Marc Schwartz wrote:
type=AVC msg=audit(1149203919.092:6): avc: denied { getattr } for pid=2051 comm="sh" name="mailq.postfix.1.gz" dev=hdc7 ino=3132510 scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:object_r:man_t:s0 tclass=file
type=AVC_PATH msg=audit(1149203919.092:6): path="/usr/share/man/man1/mailq.postfix.1.gz"
type=CWD msg=audit(1149203919.092:6): cwd="/var/spool/postfix"
type=PATH msg=audit(1149203919.092:6): item=0 name="/usr/share/man/man1/mailq.postfix.1.gz" flags=1 inode=3132510 dev=16:07 mode=0100644 ouid=0 ogid=0 rdev=00:00
What does the postfix master program do? It appears to be having trouble
here reading the attributes of a manpage?!?!?
I am truly confuzzled by this one. I have no idea why this occurred.
We'll not fix this one then, and wait to see if it happens again.
OK. Note that it is still happening and is below in the updated output.
OK, can you see if you can figure out when it's happening, e.g. once per
email, just at server startup, when the mail queue is pushed etc.?
type=AVC msg=audit(1149352202.368:284): avc: denied { read } for pid=8283 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(1149352202.368:284): arch=40000003 syscall=5 success=yes exit=3 a0=489093ef a1=0 a2=1b6 a3=9ced240 items=1 pid=8283 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(1149352202.368:284): cwd="/home/marcs"
type=PATH msg=audit(1149352202.368:284): 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(1149352202.476:287): avc: denied { getattr } for pid=8283 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(1149352202.476:287): arch=40000003 syscall=197 success=yes exit=0 a0=3 a1=bfc0bae8 a2=4891eff4 a3=3 items=0 pid=8283 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(1149352202.476:287): path="/proc/meminfo"
clamassassin trying to read /proc/meminfo
Any idea why?
Not at all. A search of the script does not show any calls to read
there, so perhaps it is clamscan, unless the audit trail would
differentiate it...
It might be generic startup code for the script interpreter, which may
or may not be necessary. I found this in the lpd policy:
# bash wants access to /proc/meminfo
kernel_read_system_state(lpd_t)
On the other hand, in the yam policy we have:
# Python works fine without reading /proc/meminfo
kernel_dontaudit_read_system_state(yam_t)
Given this precedent, I'm inclined to dontaudit it if it still turns up
after the context change for clamassassin, and change it to allow if it
breaks when you eventually switch to enforcing mode.
(snip)
type=AVC msg=audit(1149352204.996:294): avc: denied { search } for pid=8297 comm="pyzor" name="bin" dev=hdc7 ino=3112970 scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=dir
type=SYSCALL msg=audit(1149352204.996:294): arch=40000003 syscall=5 success=yes exit=3 a0=bfed8edb a1=8000 a2=1b6 a3=9970008 items=1 pid=8297 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=CWD msg=audit(1149352204.996:294): cwd="/"
type=PATH msg=audit(1149352204.996:294): item=0 name="/usr/bin/pyzor" flags=101 inode=3140757 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
Pyzor trying to find something to run?
Unsure. I don't know python and reviewing the code, there are calls
below the script level that may be doing things that I would be hesitant
to say that I fully comprehend. There may be a need to contact the
author or the FE package maintainer on this one, unless you know python.
No python here unfortunately.
type=AVC msg=audit(1149352205.000:295): avc: denied { search } for pid=8297 comm="pyzor" name="/" dev=proc ino=1 scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=dir
type=AVC msg=audit(1149352205.000:295): avc: denied { read } for pid=8297 comm="pyzor" name="meminfo" dev=proc ino=-268435454 scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
type=SYSCALL msg=audit(1149352205.000:295): arch=40000003 syscall=5 success=yes exit=4 a0=489093ef a1=0 a2=1b6 a3=9970250 items=1 pid=8297 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=CWD msg=audit(1149352205.000:295): cwd="/"
type=PATH msg=audit(1149352205.000:295): item=0 name="/proc/meminfo" flags=101 inode=4026531842 dev=00:03 mode=0100444 ouid=0 ogid=0 rdev=00:00
pyzor trying to read /proc/meminfo
Any idea why? I suspect it doesn't need to do this and am inclined to
dontaudit it. When we've got rid of the AVCs, we'll see if enforcing
mode works and possibly come back this if it doesn't work.
As with clamassassin, not sure why unless it has to allocate memory for
it's scanning functions and trying check on an a priori basis before
risking failure.
Possibly. We'll see.
(snip)
type=AVC msg=audit(1149352205.020:299): avc: denied { getattr } for pid=8297 comm="pyzor" name="time" dev=hdc7 ino=3132233 scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=SYSCALL msg=audit(1149352205.020:299): arch=40000003 syscall=195 success=yes exit=0 a0=bfed3bb7 a1=bfed3704 a2=4891eff4 a3=b7f439c0 items=1 pid=8297 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(1149352205.020:299): path="/usr/bin/time"
type=CWD msg=audit(1149352205.020:299): cwd="/"
type=PATH msg=audit(1149352205.020:299): item=0 name="/usr/bin/time" flags=1 inode=3132233 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
pyzor trying to run /usr/bin/time. Any idea why? Allowing it to run
arbitrary binaries would be quite a concession.
Not sure.
There is code in both:
$ grep -i time /usr/lib/python2.4/site-packages/pyzor/client.py
timeout = 5
signal.signal(signal.SIGALRM, handle_timeout)
return self.time_call(self.socket.recvfrom,
def time_call(self, call, varargs=(), kwargs=None):
signal.alarm(self.timeout)
except TimeoutError:
# their own timeout error
sys.stderr.write("timeout from server\n")
raise RuntimeError, "digest not calculated yet"
stringed = time.ctime(val)
def handle_timeout(signum, frame):
raise TimeoutError
and
$ grep -i time /usr/lib/python2.4/site-packages/pyzor/server.py
import time
# We duplicate the time field merely so that
ts = int(time.time())
time.ctime(ts),
self.wl_entered = int(time.time())
self.r_entered = int(time.time())
self.r_updated = int(time.time())
self.wl_updated = int(time.time())
breakpoint = time.time() - self.max_age
timeout = 3
time_diff_allowance = 180
except TimeoutError, e:
self.handle_error(503, "Gateway timeout: %s" % e)
So I am guessing timeout errors contacting the servers perhaps...
Another query for those in the know.
Not convinced anything there is responsible. We'll have to allow it for
now and follow up later.
(snip)
type=AVC msg=audit(1149352210.004:305): avc: denied { read write } for pid=8511 comm="dccproc" name="map" dev=hdc5 ino=87811 scontext=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file
type=SYSCALL msg=audit(1149352210.004:305): arch=40000003 syscall=5 success=yes exit=3 a0=80ba6e0 a1=2 a2=180 a3=11 items=1 pid=8511 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(1149352210.004:305): cwd="/var/dcc"
type=PATH msg=audit(1149352210.004:305): item=0 name="/var/dcc/map" flags=101 inode=87811 dev=16:05 mode=0100600 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1149352210.008:306): avc: denied { getattr } for pid=8511 comm="dccproc" name="map" dev=hdc5 ino=87811 scontext=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file
type=SYSCALL msg=audit(1149352210.008:306): arch=40000003 syscall=197 success=yes exit=0 a0=3 a1=bfeb0a78 a2=4891eff4 a3=3 items=0 pid=8511 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(1149352210.008:306): path="/var/dcc/map"
type=AVC msg=audit(1149352210.008:307): avc: denied { lock } for pid=8511 comm="dccproc" name="map" dev=hdc5 ino=87811 scontext=system_u:system_r:spamd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file
type=SYSCALL msg=audit(1149352210.008:307): arch=40000003 syscall=221 success=yes exit=0 a0=3 a1=7 a2=bfeb1bf4 a3=bfeb1bf4 items=0 pid=8511 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(1149352210.008:307): path="/var/dcc/map"
This is dcc manipulating /var/dcc/map whilst running in the spamd_t
domain, since there is no separate dcc policy. We probably need a new
type for this, and policy rules to allow this.
After installing the updated mydcc.pp, do:
# restorecon -rv /var/dcc
Done..
<snip of modules>
All updated modules installed.
I also cleaned out the audit.log file. Just to get rid of all of the old stuff. Then re-booted.
I re-ran avclist after the updates and the first e-mails came through. The output is below.
That should fix quite a few, but not all issues (particularly not the
ones I've queried).
Thanks Paul!
Regards,
Marc
type=AVC msg=audit(1149561389.767:5): avc: denied { getattr } for pid=2141 comm="sh" name="mailq.postfix.1.gz" dev=hdc7 ino=3132510 scontext=system_u:system_r:postfix_master_t:s0 tcontext=system_u:object_r:man_t:s0 tclass=file
type=SYSCALL msg=audit(1149561389.767:5): arch=40000003 syscall=195 success=yes exit=0 a0=913bd10 a1=bffc8438 a2=4891eff4 a3=913c3c8 items=1 pid=2141 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="sh" exe="/bin/bash"
type=AVC_PATH msg=audit(1149561389.767:5): path="/usr/share/man/man1/mailq.postfix.1.gz"
type=CWD msg=audit(1149561389.767:5): cwd="/var/spool/postfix"
type=PATH msg=audit(1149561389.767:5): item=0 name="/usr/share/man/man1/mailq.postfix.1.gz" flags=1 inode=3132510 dev=16:07 mode=0100644 ouid=0 ogid=0 rdev=00:00
Don't know what's going on here but it's fairly harmless so we'll allow
it for now, pending further investigation.
type=AVC msg=audit(1149561396.952:6): avc: denied { append } for pid=2196 comm="spamd" name="razor-agent.log" dev=hdc7 ino=829594 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=file
type=SYSCALL msg=audit(1149561396.952:6): arch=40000003 syscall=5 success=yes exit=6 a0=aa50688 a1=8441 a2=1b6 a3=8441 items=1 pid=2196 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl"
type=CWD msg=audit(1149561396.952:6): cwd="/"
type=PATH msg=audit(1149561396.952:6): item=0 name="/root/.razor/razor-agent.log" flags=310 inode=829589 dev=16:07 mode=040755 ouid=0 ogid=0 rdev=00:00
Spamd appending to the razor log file. Do you have the
spamd_enable_home_dirs boolean set?
# getsebool spamd_enable_home_dirs
If it's not set, please set it:
# setsebool -P spamd_enable_home_dirs 1
type=AVC msg=audit(1149561396.952:7): avc: denied { ioctl } for pid=2196 comm="spamd" name="razor-agent.log" dev=hdc7 ino=829594 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=file
type=SYSCALL msg=audit(1149561396.952:7): arch=40000003 syscall=54 success=no exit=-25 a0=6 a1=5401 a2=bfcc99b8 a3=bfcc99f8 items=0 pid=2196 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl"
type=AVC_PATH msg=audit(1149561396.952:7): path="/root/.razor/razor-agent.log"
type=AVC msg=audit(1149561396.952:8): avc: denied { getattr } for pid=2196 comm="spamd" name="razor-agent.log" dev=hdc7 ino=829594 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=file
type=SYSCALL msg=audit(1149561396.952:8): arch=40000003 syscall=197 success=yes exit=0 a0=6 a1=9381068 a2=4891eff4 a3=9397f64 items=0 pid=2196 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl"
type=AVC_PATH msg=audit(1149561396.952:8): path="/root/.razor/razor-agent.log"
type=AVC msg=audit(1149561396.960:9): avc: denied { read } for pid=2196 comm="spamd" name="servers.discovery.lst" dev=hdc7 ino=829591 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=file
type=SYSCALL msg=audit(1149561396.960:9): arch=40000003 syscall=5 success=yes exit=7 a0=aa589e8 a1=8000 a2=0 a3=8000 items=1 pid=2196 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl"
type=CWD msg=audit(1149561396.960:9): cwd="/"
type=PATH msg=audit(1149561396.960:9): item=0 name="/root/.razor/servers.discovery.lst" flags=101 inode=829591 dev=16:07 mode=0100644 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1149561396.968:10): avc: denied { read } for pid=2196 comm="spamd" name=".razor" dev=hdc7 ino=829589 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir
type=SYSCALL msg=audit(1149561396.968:10): arch=40000003 syscall=5 success=yes exit=7 a0=aa50028 a1=18800 a2=0 a3=a49d968 items=1 pid=2196 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl"
type=CWD msg=audit(1149561396.968:10): cwd="/"
type=PATH msg=audit(1149561396.968:10): item=0 name="/root/.razor" flags=103 inode=829589 dev=16:07 mode=040755 ouid=0 ogid=0 rdev=00:00
I think these may be more of the same.
type=AVC msg=audit(1149561397.424:11): avc: denied { getattr } for pid=2289 comm="pyzor" name="bin" dev=hdc7 ino=3112970 scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=dir
type=SYSCALL msg=audit(1149561397.424:11): arch=40000003 syscall=196 success=yes exit=0 a0=86c6128 a1=bf9d1598 a2=4891eff4 a3=bf9d2ee1 items=1 pid=2289 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="pyzor" exe="/usr/bin/python"
type=AVC_PATH msg=audit(1149561397.424:11): path="/usr/bin"
type=CWD msg=audit(1149561397.424:11): cwd="/"
type=PATH msg=audit(1149561397.424:11): item=0 name="/usr/bin" flags=0 inode=3112970 dev=16:07 mode=040755 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1149561397.884:12): avc: denied { getattr } for pid=2289 comm="pyzor" name="time" dev=hdc7 ino=3132233 scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=SYSCALL msg=audit(1149561397.884:12): arch=40000003 syscall=195 success=yes exit=0 a0=bf9ce3d7 a1=bf9cdf24 a2=4891eff4 a3=b7f3d9e0 items=1 pid=2289 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="pyzor" exe="/usr/bin/python"
type=AVC_PATH msg=audit(1149561397.884:12): path="/usr/bin/time"
type=CWD msg=audit(1149561397.884:12): cwd="/"
type=PATH msg=audit(1149561397.884:12): item=0 name="/usr/bin/time" flags=1 inode=3132233 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
More prodding at /usr/bin/time...
type=AVC msg=audit(1149561399.108:13): avc: denied { search } for pid=2295 comm="dccproc" name="dcc" dev=hdc5 ino=87778 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:dcc_var_t:s0 tclass=dir
type=SYSCALL msg=audit(1149561399.108:13): arch=40000003 syscall=12 success=yes exit=0 a0=bf9dad62 a1=0 a2=4891eff4 a3=11 items=1 pid=2295 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc"
type=CWD msg=audit(1149561399.108:13): cwd="/"
type=PATH msg=audit(1149561399.108:13): item=0 name="/var/dcc" flags=3 inode=87778 dev=16:05 mode=040755 ouid=0 ogid=0 rdev=00:00
spamd acting as a dcc client again.
type=AVC msg=audit(1149561408.789:14): avc: denied { read write } for pid=2419 comm="mingetty" name="utmp" dev=hdc5 ino=146250 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file
type=SYSCALL msg=audit(1149561408.789:14): arch=40000003 syscall=5 success=yes exit=3 a0=48909fd4 a1=2 a2=804a000 a3=48909fda items=1 pid=2419 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="mingetty" exe="/sbin/mingetty"
type=CWD msg=audit(1149561408.789:14): cwd="/"
type=PATH msg=audit(1149561408.789:14): item=0 name="/var/run/utmp" flags=101 inode=146250 dev=16:05 mode=0100664 ouid=0 ogid=22 rdev=00:00
type=AVC msg=audit(1149561408.789:15): avc: denied { lock } for pid=2419 comm="mingetty" name="utmp" dev=hdc5 ino=146250 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file
type=SYSCALL msg=audit(1149561408.789:15): arch=40000003 syscall=221 success=yes exit=0 a0=3 a1=7 a2=bfc8fe3c a3=bfc8fdb0 items=0 pid=2419 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="mingetty" exe="/sbin/mingetty"
type=AVC_PATH msg=audit(1149561408.789:15): path="/var/run/utmp"
No idea what these are, though if you're on the current policy
(selinux-policy-2.2.40-1.fc5) it would seem that your /var/run/utmp is
labelled incorrectly (init_var_run_t instead of initrc_var_run_t).
Try:
# restorecon -v /var/run/utmp
type=AVC msg=audit(1149561602.879:55): avc: denied { use } for pid=5247 comm="clamscan" name="[14742]" dev=pipefs ino=14742 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0 tclass=fd
type=AVC msg=audit(1149561602.879:55): avc: denied { write } for pid=5247 comm="clamscan" name="[14742]" dev=pipefs ino=14742 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0 tclass=fifo_file
type=SYSCALL msg=audit(1149561602.879:55): arch=40000003 syscall=11 success=yes exit=0 a0=8889c00 a1=8889210 a2=8889dd0 a3=8889d90 items=2 pid=5247 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(1149561602.879:55): path="pipe:[14742]"
type=AVC_PATH msg=audit(1149561602.879:55): path="pipe:[14742]"
type=CWD msg=audit(1149561602.879:55): cwd="/home/marcs"
type=PATH msg=audit(1149561602.879:55): 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(1149561602.879:55): item=1 flags=101 inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
I wonder if output from postfix's local delivery process (sub-contracted
to procmail) is piped back into postfix-local? Added to module for now.
(snip)
The remaining ones all looked like duplicates of what had gone before.
Policy updates:
####### mypostfix.te (new module) #######
policy_module(mypostfix, 0.1.0)
require {
type man_t;
type postfix_master_t;
};
# Postfix master process reading its mailq manpage because... ?!?!
allow postfix_master_t man_t:file getattr;
####### mypyzor.te ######
policy_module(mypyzor, 0.1.2)
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 pyzor messages!
allow pyzor_t pyzor_port_t:udp_socket send_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)
####### mydcc.te #######
policy_module(mydcc, 0.1.2)
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;
####### myclam.te #######
policy_module(myclam, 0.1.2)
require {
type clamscan_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;
Paul.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
