On Thu, 2008-03-06 at 14:45 +0000, Arthur Dent wrote:
Hi Stephen,
Yes, I know it's a bit off-topic for this list (well totally OT really)
but why does clamd bind to a different port each time? Is that normal
behaviour for clamd or have I got something borked in my setup?
Some daemons scan for any available port within a given range, and take
the first one available, for transient ports used for data transfer (vs.
well-known ports).
Anyway it works (I think)!
Thanks very much for all the help and support so far. Now that I have
discovered audit2allow there's no stopping me!...
I have no idea what most of the things are for, but if I'm careful about
watching where the denials take place, is it usually safe to trust
audit2allow to create policies for me?
audit2allow just turns every denial into an allow rule. So it can't for
example tell you that the real reason you had a denial was because you
had a mislabeled file. Your /mnt/backup situation is an example where
audit2allow would have given you the wrong solution - allowing access to
the default type of /mnt rather than properly configuring your policy to
label /mnt/backup with a suitable type.
setroubleshoot tries to give you more help via a heuristics-based set of
plugins, but it doesn't really have a semantic understanding of the
policy, so it too is limited in what it can achieve. But setroubleshoot
can sometimes tell you that a file is mislabeled or that you just need
to enable some policy boolean.
There is ongoing work in policy tools to bridge the semantic gap.
After much watching and tail -f ing of logs, here is what I have
ended
up with...
##########################################
# cat myclamd.te
policy_module(myclamd, 1.2)
require {
type clamscan_t;
type clamd_t;
class tcp_socket { write create connect };
type var_run_t;
type user_home_t;
class sock_file write;
class file append;
}
#============= clamd_t ==============
corenet_tcp_bind_generic_port(clamd_t)
#============= clamscan_t ==============
allow clamscan_t self:tcp_socket { write create connect };
allow clamscan_t user_home_t:file append;
What file in your home directory is clamscan appending to?
Maybe we can put it into a distinct type and protect the rest of your
files?
allow clamscan_t var_run_t:sock_file write;
This suggests that something is creating a socket under /var/run without
properly putting it into a distinct type.
corenet_tcp_connect_generic_port(clamscan_t)
mta_read_queue(clamscan_t)
procmail_rw_tmp_files(clamscan_t)
userdom_read_generic_user_home_content_files(clamscan_t)
##########################################
It's still Greek to me. I hope I haven't compromised my system in any way...
You can't make your system weaker than it was without SELinux in this
manner, since all you are doing is loosening the SELinux restrictions -
the usual DAC restrictions still apply. So all you are doing is
altering the extent to which SELinux is protecting you.
I have just typed "setenforce 1" - Yay! (Expect to hear
back from me
with tales of woe when it won't work anymore!...
--
Stephen Smalley
National Security Agency