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
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
