Partitions Mounted by fstab

[Stephen Smalley]

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