Marc Schwartz wrote:
On Fri, 2006-06-02 at 17:03 +0100, Paul Howarth wrote:
Marc Schwartz wrote:
On Thu, 2006-06-01 at 13:00 +0100, Paul Howarth wrote:
Marc Schwartz wrote:
<snip>
Now for grep "dcc":
<snip of audit.log entries for 'dcc'>
As an FYI, I ran:
sudo /sbin/fixfiles check
and it came back with no errors.
That is curious because you still seem to have some incorrectly-labelled
files (e.g. a razor-agent.log that's default_t). You definitely haven't
disabled SELinux (as opposed to just putting it in permissive mode) at
any time since ralabelling, have you?
No, I had not made any changes to SELinux after last going to Permissive
mode.
I think the normal relabel procedure is to configure SELinux for
permissive mode, then:
# touch /.autorelabel
and then reboot.
This had occurred after changing SELinux from Disabled to Permissive.
However, I have some partitions protected by dm-crypt/LUKS which would
not be accessible immediately after boot. Thus I ran the system-wide
fixfiles relabel
and then re-booted, so that all partitions could be done.
OK, let's be on the lookout for incorrectly labelled files though.
type=AVC msg=audit(1149210123.848:615): avc: denied { getattr } for pid=14642 comm="clamscan" name="clamassassinmsg.UFZVw14635" dev=hdc6 ino=18 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:procmail_tmp_t:s0 tclass=file
type=AVC msg=audit(1149211441.847:718): avc: denied { read } for pid=16548 comm="clamscan" name="clamassassinmsg.InjWm16541" dev=hdc6 ino=18 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:procmail_tmp_t:s0 tclass=file
type=AVC msg=audit(1149211441.847:718): avc: denied { write } for pid=16548 comm="clamscan" name="clamassassinlog.ieiqW16542" dev=hdc6 ino=19 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:procmail_tmp_t:s0 tclass=file
This is a repeating loop of entries all for 'clamscan' it seems.
This appears to be due to messages being written to temporary files
whilst still in the procmail_t domain and then being scanned after the
transition to clamscan_t. Is /usr/local/bin/clamassassin a script that
writes its input to a temp file and then calls clamscan to do the scan?
My reading of the script suggests that your assumptions are correct.
If you would like to review more information, the web site is here:
http://jameslick.com/clamassassin/
It essentially enables the piping to ClamAV within procmail in a fashion
similar to SA.
I wonder if it's worth trying changing /usr/local/bin/clamassassin to
clamscan_exec_t?
Done:
chcon system_u:object_r:clamscan_exec_t /usr/local/bin/clamassassin
OK. Can you keep a note of the manual context changes you've made? That
will help to ensure that if I forget something when we pull everything
together, you can spot it ;-)
For grep 'postfix':
type=AVC msg=audit(1149200642.921:4794): avc: denied { use } for pid=19149 comm="clamscan" name="[425692]" dev=pipefs ino=425692 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0 tclass=fd
type=AVC msg=audit(1149200642.921:4794): avc: denied { write } for pid=19149 comm="clamscan" name="[425692]" dev=pipefs ino=425692 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0 tclass=fifo_file
Looks like postfix local delivery (which I know nothing about) piping
something into clamscan. Is your postfix configured to talk to clamav by
any means other than procmail?
Not to my knowledge.
Actually I read that the wrong way around. It's clamscan talking to
postfix local delivery, not the other way around. I still don't know
what's happening there.
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.
<Snip of pyzor and clam greps from log>
Here's a script I've just written called "avclist", which should output
all of the audit logs for SELinux issues since the last change of
enforcement mode or policy reload. It's probably better for looking at
recent AVC messages, as it includes some useful related information that
would be missed by just a simple grep:
(snip)
OK. Installed and ran this. See output below after changes made and
first e-mail came through.
For now, try changing the context of /usr/local/bin/clamassassin as
described above, and try these policy modules for pyzor and clamav:
(snip)
Build and install these in the same way as the procmail module from earlier.
Done.
See avclist output below.
Let me know what else you need here.
Thanks Paul!
Marc
$ sudo ./avclist
type=AVC msg=audit(1149352202.364:283): avc: denied { use } for pid=8283 comm="clamassassin" name="[24074]" dev=pipefs ino=24074 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0 tclass=fd
type=AVC msg=audit(1149352202.364:283): avc: denied { write } for pid=8283 comm="clamassassin" name="[24074]" dev=pipefs ino=24074 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:system_r:postfix_local_t:s0 tclass=fifo_file
type=SYSCALL msg=audit(1149352202.364:283): arch=40000003 syscall=11 success=yes exit=0 a0=84cbd60 a1=84cb008 a2=84ceb38 a3=0 items=3 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.364:283): path="pipe:[24074]"
type=AVC_PATH msg=audit(1149352202.364:283): path="pipe:[24074]"
type=CWD msg=audit(1149352202.364:283): cwd="/home/marcs"
type=PATH msg=audit(1149352202.364:283): item=0 name="/usr/local/bin/clamassassin" flags=101 inode=3115337 dev=16:07 mode=0100555 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1149352202.364:283): item=1 flags=101 inode=1966191 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1149352202.364:283): item=2 flags=101 inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
This is the clamscan->postfix-local issue from earlier.
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?
type=AVC msg=audit(1149352202.476:288): avc: denied { search } for pid=8283 comm="clamassassin" name="bin" dev=hdc7 ino=3112982 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=dir
type=SYSCALL msg=audit(1149352202.476:288): arch=40000003 syscall=5 success=yes exit=3 a0=9cef018 a1=8000 a2=0 a3=8000 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.476:288): cwd="/home/marcs"
type=PATH msg=audit(1149352202.476:288): item=0 name="/usr/local/bin/clamassassin" flags=101 inode=3115337 dev=16:07 mode=0100555 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1149352202.484:289): avc: denied { execute } for pid=8284 comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=AVC msg=audit(1149352202.484:289): avc: denied { execute_no_trans } for pid=8284 comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=AVC msg=audit(1149352202.484:289): avc: denied { read } for pid=8284 comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=SYSCALL msg=audit(1149352202.484:289): arch=40000003 syscall=11 success=yes exit=0 a0=9cef2c0 a1=9cef500 a2=9cf2dd0 a3=9cef228 items=2 pid=8284 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="mktemp" exe="/bin/mktemp"
type=AVC_PATH msg=audit(1149352202.484:289): path="/bin/mktemp"
type=AVC_PATH msg=audit(1149352202.484:289): path="/bin/mktemp"
type=CWD msg=audit(1149352202.484:289): cwd="/home/marcs"
type=PATH msg=audit(1149352202.484:289): item=0 name="/bin/mktemp" flags=101 inode=1966111 dev=16:07 mode=0100555 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1149352202.484:289): item=1 flags=101 inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
This is clamassassin running mktemp to create a temporary file.
I can add this to the local policy module but I'm not convinced it's a
great idea (it would allow clamscan to run pretty much anything). This
will be happening because of the domain transition to clamscan_t
happening earlier than before due to changing the context of
/usr/local/bin/clamassassin to clamscan_exec_t. So I now think that's
not a good idea and we should change it back again:
# chcon -t bin_t /usr/local/bin/clamassassin
Instead, we'll allow clamscan to read temp files created by procmail,
which is a finer grained fix.
type=AVC msg=audit(1149352202.484:290): avc: denied { read } for pid=8284 comm="mktemp" name="urandom" dev=tmpfs ino=1989 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1149352202.484:290): arch=40000003 syscall=5 success=yes exit=3 a0=80494d8 a1=0 a2=48920120 a3=9aa2008 items=1 pid=8284 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="mktemp" exe="/bin/mktemp"
type=CWD msg=audit(1149352202.484:290): cwd="/home/marcs"
type=PATH msg=audit(1149352202.484:290): item=0 name="/dev/urandom" flags=101 inode=1989 dev=00:0f mode=020444 ouid=0 ogid=0 rdev=01:09
mktemp reading /dev/urandom to make up a unique filename. This won't be
an error when mktemp starts being run from procmail again.
type=AVC msg=audit(1149352202.496:291): avc: denied { execute_no_trans } for pid=8287 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1149352202.496:291): arch=40000003 syscall=11 success=yes exit=0 a0=9cf2c00 a1=9cf2210 a2=9cf2dd0 a3=9cf2d90 items=2 pid=8287 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(1149352202.496:291): path="/usr/bin/clamscan"
type=CWD msg=audit(1149352202.496:291): cwd="/home/marcs"
type=PATH msg=audit(1149352202.496:291): 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(1149352202.496:291): item=1 flags=101 inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
Running /usr/bin/clamscan from clamassassin. This also won't be an error
when it starts being run from procmail again.
type=AVC msg=audit(1149352204.428:292): avc: denied { search } for pid=8293 comm="clamassassin" name="bin" dev=hdc7 ino=3112970 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=dir
type=SYSCALL msg=audit(1149352204.428:292): arch=40000003 syscall=11 success=yes exit=0 a0=9cf0e00 a1=9cf3fc8 a2=9cf2dd0 a3=9cf3320 items=2 pid=8293 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="formail" exe="/usr/bin/formail"
type=CWD msg=audit(1149352204.428:292): cwd="/home/marcs"
type=PATH msg=audit(1149352204.428:292): item=0 name="/usr/bin/formail" flags=101 inode=3133721 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1149352204.428:292): item=1 flags=101 inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
This'll be the tagging of the message by clamassassin. Might go away.
type=AVC msg=audit(1149352204.996:293): avc: denied { search } for pid=8297 comm="pyzor" scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir
type=AVC msg=audit(1149352204.996:293): avc: denied { read } for pid=8297 comm="pyzor" scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=file
type=SYSCALL msg=audit(1149352204.996:293): arch=40000003 syscall=149 success=yes exit=0 a0=bfed6bd0 a1=4891eff4 a2=48a95e00 a3=bfed6bc8 items=0 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"
I'm not sure what this but most domains seem to allow it so I'll add it
for now.
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?
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.
type=AVC msg=audit(1149352205.016:298): avc: denied { read } for pid=8297 comm="pyzor" name="urandom" dev=tmpfs ino=1989 scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1149352205.016:298): arch=40000003 syscall=5 success=yes exit=6 a0=9972f68 a1=8000 a2=0 a3=8000 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.016:298): cwd="/"
type=PATH msg=audit(1149352205.016:298): item=0 name="/dev/urandom" flags=101 inode=1989 dev=00:0f mode=020444 ouid=0 ogid=0 rdev=01:09
pyzor trying to generate random numbers for something (possibly temp
file creation). I'll add this to the module.
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.
type=AVC msg=audit(1149352205.060:300): avc: denied { send_msg } for pid=8297 comm="pyzor" saddr=192.168.1.2 src=32865 daddr=66.250.40.33 dest=24441 netif=eth0 scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:pyzor_port_t:s0 tclass=udp_socket
type=SYSCALL msg=audit(1149352205.060:300): arch=40000003 syscall=102 success=yes exit=165 a0=b a1=bfed58a0 a2=c79114 a3=bfed58d8 items=0 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=SOCKADDR msg=audit(1149352205.060:300): saddr=02005F7942FA28210000000000000000
type=SOCKETCALL msg=audit(1149352205.060:300): nargs=6 a0=3 a1=b7f553f4 a2=a5 a3=0 a4=b7f828c0 a5=10
pyzor sending a message to pyzor_port_t. Don't know why this isn't
currently allowed.
type=AVC msg=audit(1149352209.996:304): avc: denied { signal } for pid=2335 comm="spamd" scontext=system_u:system_r:spamd_t:s0
tcontext=system_u:system_r:pyzor_t:s0 tclass=process
type=SYSCALL msg=audit(1149352209.996:304): arch=40000003 syscall=37 success=yes exit=0 a0=2069 a1=f a2=481f45c8 a3=a2053ac items=0 pid=2335 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 comm="spamd" exe="/usr/bin/perl"
spamd signalling pyzor. Not sure why. KILL/HUP?
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
Updated modules:
############ myclam.te ################
policy_module(myclam, 0.1.1)
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;
############### mypyzor.te ##############
policy_module(mypyzor, 0.1.1)
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)
# 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.fc ###############
/var/dcc/libexec/start-.* --
gen_context(system_u:object_r:initrc_exec_t,s0)
/var/dcc/libexec/stop-.* --
gen_context(system_u:object_r:initrc_exec_t,s0)
# Cribbed from upstream policy
/var/dcc(/.*)?
gen_context(system_u:object_r:dcc_var_t,s0)
/var/dcc/map --
gen_context(system_u:object_r:dcc_client_map_t,s0)
############## mydcc.te ##############
policy_module(mydcc, 0.1.1)
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;
That should fix quite a few, but not all issues (particularly not the
ones I've queried).
Paul.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
