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?
I think the normal relabel procedure is to configure SELinux for
permissive mode, then:
# touch /.autorelabel
and then reboot.
These all appear to be dccproc doing read/write/lock operations on
/var/dcc/map. This is happening in the spamd_t domain, which seems wrong
to me since spamd_t should transition to dcc_client_t. Check what the
context of /usr/local/bin/dccproc is; I think it should be
dcc_client_exec_t (and it would be if it was in /usr/bin).
user_u:object_r:bin_t /usr/local/bin/dccproc
So:
sudo chcon -u system_u -t dcc_client_exec_t /usr/local/bin/dccproc
?
Yes, though a shorthand format for this would be:
# chcon system_u:object_r:dcc_client_exec_t /usr/local/bin/dccproc
However, you'll find it won't work. Although there is a policy module
for dcc in the upstream reference policy, it doesn't appear to be
included in Fedora's targeted policy, so none of these types are
defined. The only dcc-related policy items are:
/usr/libexec/dcc/stop-.* -- system_u:object_r:initrc_exec_t:s0
/usr/libexec/dcc/start-.* -- system_u:object_r:initrc_exec_t:s0
So perhaps dcc is supposed to run unconfined on FC5? Maybe Dan can
answer that one. Anyway, try this:
# chcon system_u:object_r:initrc_exec_t /var/dcc/libexec/start-*
# chcon system_u:object_r:initrc_exec_t /var/dcc/libexec/stop-*
You might check out the file contexts from the dcc policy module (listed
below) and check that everything else is labelled correctly in the
places you have installed them:
/etc/dcc(/.*)?
gen_context(system_u:object_r:dcc_var_t,s0)
/etc/dcc/dccifd -s
gen_context(system_u:object_r:dccifd_var_run_t,s0)
/etc/dcc/map --
gen_context(system_u:object_r:dcc_client_map_t,s0)
There is no /etc/dcc tree.
There's a comment in the dcc policy file about this being the wrong
place for the files anyway, so perhaps it's there for backwards
compatibility with older versions.
I am getting the feeling that the default policy tree structure does not
fully agree with the default dcc installation tree structure using the
tarball from Rhyolite.
That does seem to be the case.
Is some of this due to my using postfix and not sendmail?
I don't think so. In fact, I don't think we've come across any postfix
issues yet.
For grep "razor":
type=AVC msg=audit(1149102177.498:8243): avc: denied { append } for
pid=20136 comm="spamd" name="razor-agent.log" dev=hdc7 ino=98923
scontext=system_u:system_r:spamd_t:s0
tcontext=system_u:object_r:default_t:s0 tclass=file
default_t file should have been relabelled by now.
Curiously, there are three razor-agent.log files:
system_u:object_r:default_t /razor-agent.log
user_u:object_r:default_t /.razor/razor-agent.log
user_u:object_r:user_home_t /home/marcs/.razor/razor-agent.log
The first one above is dated yesterday, the second one from today and
the third one from today. My local user copy being dated this evening.
You've configured this setup, so you should really know which, if any,
of these should be being used. None of them should be default_t though.
Again, check out the default contexts for razor and make sure that the
files in the locations you have installed it to have the right contexts:
ifdef(`strict_policy',`
HOME_DIR/\.razor(/.*)?
gen_context(system_u:object_r:ROLE_razor_home_t,s0)
')
If I read this correctly, my local user tree files in:
/home/marcs/.razor
are all:
user_u:object_r:user_home_t
I think that would be user_razor_home_t, but only in strict policy. As
with dcc, the upstream razor policy does not seem to be included in
targeted policy, so this is all moot. Sorry about that, we'll have to
come back to these issues later.
Finally, here are some updated entries in audit.log since the updated
policy last night:
For grep "procmail":
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?
I wonder if it's worth trying changing /usr/local/bin/clamassassin to
clamscan_exec_t?
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?
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?!?!?
For grep 'pyzor':
type=AVC_PATH msg=audit(1149211924.334:836): path="/home/marcs/.pyzor"
type=PATH msg=audit(1149211924.334:836): item=0 name="/home/marcs/.pyzor" flags=1 inode=427255 dev=fd:00 mode=040755 ouid=500 ogid=500 rdev=00:00
type=AVC msg=audit(1149211924.334:837): avc: denied { getattr } for pid=21149 comm="pyzor" name="servers" dev=dm-0 ino=427256 scontext=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file
type=SYSCALL msg=audit(1149211924.334:837): arch=40000003 syscall=195 success=yes exit=0 a0=973ffb0 a1=bf93ab48 a2=4891eff4 a3=970c1b0 items=1 pid=21149 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(1149211924.334:837): path="/home/marcs/.pyzor/servers"
type=PATH msg=audit(1149211924.334:837): item=0 name="/home/marcs/.pyzor/servers" flags=1 inode=427256 dev=fd:00 mode=0100664 ouid=500 ogid=500 rdev=00:00
type=AVC msg=audit(1149211924.334:838): avc: denied { read } for pid=21149 comm="pyzor" name="servers" dev=dm-0 ino=427256 scontext=system_u:system_r:pyzor_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file
type=SYSCALL msg=audit(1149211924.334:838): arch=40000003 syscall=5 success=yes exit=3 a0=97a53d0 a1=8000 a2=1b6 a3=975eb90 items=1 pid=21149 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=PATH msg=audit(1149211924.334:838): item=0 name="/home/marcs/.pyzor/servers" flags=101 inode=427256 dev=fd:00 mode=0100664 ouid=500 ogid=500 rdev=00:00
These appear to be pyzor reading config info. I've have thought this was
allowed but it doesn't appear to be. Maybe it needs a boolean like the
one for spamassassin.
type=AVC msg=audit(1149211924.334:839): avc: denied { search } for pid=21149 comm="pyzor" name="/" dev=hdc6 ino=2 scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=AVC msg=audit(1149211924.334:839): avc: denied { write } for pid=21149 comm="pyzor" name="/" dev=hdc6 ino=2 scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=AVC msg=audit(1149211924.334:839): avc: denied { add_name } for pid=21149 comm="pyzor" name="zZU--3" scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=SYSCALL msg=audit(1149211924.334:839): arch=40000003 syscall=5 success=yes exit=4 a0=97a53d0 a1=280c2 a2=180 a3=280c2 items=1 pid=21149 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 msg=audit(1149211924.334:840): avc: denied { remove_name } for pid=21149 comm="pyzor" name="zZU--3" dev=hdc6 ino=19 scontext=system_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
Looks like pyzor not being allowed to create and use temp files. There's
already policy for allowing pyzor to read temp files created by spamd
but this looks like something different. Probably warrants investigation.
For grep 'clam':
type=SYSCALL msg=audit(1149216362.498:1153): arch=40000003 syscall=3 success=yes exit=16384 a0=5 a1=8a84c28 a2=4000 a3=0 items=0 pid=29037 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(1149216362.498:1153): path="/tmp/clamav-0f02c0e698dc29b6"
type=AVC msg=audit(1149216362.950:1154): avc: denied { remove_name } for pid=29037 comm="clamscan" name="clamav-0f02c0e698dc29b6" dev=hdc6 ino=20 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=AVC msg=audit(1149216362.950:1154): avc: denied { unlink } for pid=29037 comm="clamscan" name="clamav-0f02c0e698dc29b6" dev=hdc6 ino=20 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file
type=SYSCALL msg=audit(1149216362.950:1154): arch=40000003 syscall=10 success=yes exit=0 a0=8a83280 a1=1 a2=4807c938 a3=8a84c28 items=1 pid=29037 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=PATH msg=audit(1149216362.950:1154): item=0 name="/tmp/clamav-0f02c0e698dc29b6" flags=10 inode=2 dev=16:06 mode=041777 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1149216362.954:1155): avc: denied { read } for pid=29037 comm="clamscan" name="clamav-fe19cc5f77908e70" dev=hdc6 ino=29251 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=SYSCALL msg=audit(1149216362.954:1155): arch=40000003 syscall=5 success=yes exit=5 a0=8a83228 a1=18800 a2=4890ac0c a3=8a84c28 items=1 pid=29037 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=PATH msg=audit(1149216362.954:1155): item=0 name="/tmp/clamav-fe19cc5f77908e70" flags=103 inode=29251 dev=16:06 mode=040700 ouid=500 ogid=500 rdev=00:00
type=AVC msg=audit(1149216362.954:1156): avc: denied { getattr } for pid=29037 comm="clamscan" name="clamav-fe19cc5f77908e70" dev=hdc6 ino=29251 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=SYSCALL msg=audit(1149216362.954:1156): arch=40000003 syscall=197 success=yes exit=0 a0=5 a1=bfdcfd4c a2=4891eff4 a3=5 items=0 pid=29037 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(1149216362.954:1156): path="/tmp/clamav-fe19cc5f77908e70"
type=AVC msg=audit(1149216363.850:1157): avc: denied { setattr } for pid=29037 comm="clamscan" name="clamav-fe19cc5f77908e70" dev=hdc6 ino=29251 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
type=SYSCALL msg=audit(1149216363.850:1157): arch=40000003 syscall=15 success=yes exit=0 a0=8a83228 a1=1c0 a2=4807c938 a3=8a84c28 items=1 pid=29037 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=PATH msg=audit(1149216363.850:1157): item=0 name="/tmp/clamav-fe19cc5f77908e70" flags=1 inode=29251 dev=16:06 mode=040700 ouid=500 ogid=500 rdev=00:00
type=AVC msg=audit(1149216363.850:1158): avc: denied { rmdir } for pid=29037 comm="clamscan" name="clamav-fe19cc5f77908e70" dev=hdc6 ino=29251 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
These all relate to clamscan handling temporary files. Can't see
anything allowing this in the policy yet.
Hope that provide sufficient additional information. If you need more,
let me know.
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:
#!/bin/sh
# avclist: pull AVC audit messages from audit.log since last setenforce
awk ' {
# Record all lines read from input
line[++lines] = $0
auditref[lines] = $2
}
/^type=AVC / {
# Mark this audit message as being of interest
avc[$2] = 1
}
/^type=AVC msg=audit[(][0-9.:]*[)]: avc: *granted *{
(load_policy|setenforce) }/ {
# Discard all lines read before a
# setenforce or policy reload
lines = 0
avc[$2] = 0
}
END {
# Output all recorded lines of interest
for (i = 1; i <= lines; i++) {
if (avc[auditref[i]]) {
print line[i]
}
}
}' /var/log/audit/audit.log
(the long line starting "/^type=AVC msg=audit" should have a single
space either side of "(load_policy|setenforce)")
For now, try changing the context of /usr/local/bin/clamassassin as
described above, and try these policy modules for pyzor and clamav:
####### mypyzor.te ############
policy_module(mypyzor, 0.1.0)
require {
type pyzor_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)
######### myclam.te ###############
policy_module(myclam, 0.1.0)
require {
type clamscan_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 })
Build and install these in the same way as the procmail module from earlier.
Paul.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
