On Thu, 2008-03-06 at 12:40 +0000, Arthur Dent wrote:
> On Thu, Mar 06, 2008 at 10:07:38AM +0000, Arthur Dent wrote:
> >
> > Now, by far and away the biggest cause of clutter in the logs is errors
> > caused by the next hop in the procmail processing chain - calling clamav
> > (using clamd).
> >
> > Here is a sample (edited to remove the sealert reference):
> > Mar 6 09:24:06 mydomain setroubleshoot: SELinux is preventing procmail (procmail_t) "search" to ./mnt (mnt_t).
> > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files (/home/mark/Procmail/pmlog).
> > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files (./Msgs).
> > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files (/tmp/clamassassinmsg.gEsPbc3633).
> > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "write" to clamd.sock (var_run_t).
> > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing the clamd (clamd_t) from binding to port 1839.
> > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "create" to <Unknown> (clamscan_t).
> > Mar 6 09:24:07 mydomain setroubleshoot: SELinux is preventing clamdscan( clamscan_t) "connect" to <Unknown> (clamscan_t).
> > Mar 6 09:24:08 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "write" to socket (clamscan_t).
> > Mar 6 09:24:08 mydomain setroubleshoot: SELinux is preventing the clamdscan from using potentially mislabeled files(/tmp/clamassassinlog.PDbPHf3634).
> > Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "read" to /var/spool/mqueue/dfm269U2u1003678 (mqueue_spool_t).
> > Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing theclamdscan from using potentially mislabeled files (./Msgs).
> > Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing clamdscan (clamscan_t) "write" to clamd.sock (var_run_t).
> > Mar 6 09:30:06 mydomain setroubleshoot: SELinux is preventing the clamd (clamd_t) from binding to port 1508.
> >
> > Fetchmail checks for mail every 3 minutes so you can imagine there are
> > quite a few of those entries in the logs!
> >
> > Based on what you showed me for procmail I have tried to create a policy
> > for clamd. However I am not even going to *think* about running it until
> > you have checked it over!
> >
> > ##########################################
> > # cat myclamd.te
> > policy_module(myclamd, 1.0)
> > require {
> > # Symbols defined outside of this module.
> > type clamd_t;
> > type clamscan_t;
> > }
> >
> > # Don't really know what to put here...
> > allow clamd_t bin_t
> > ###########################################
> >
> > Or am I re-inventing the wheel? Surely there must be a ready-made clamd
> > policy?
>
> Been thinking (always dangerous!) about this...
>
> Here's my latest effort. This time I've tried using audit2allow. The
> output is Greek to me.
> Is this safe to use?
> Will it address all the issues?
>
> Thanks for any advice...
>
> ##########################################
> # cat myclamd.te
> policy_module(myclamd, 1.1)
> require {
> type clamscan_t;
> type clamd_t;
> class tcp_socket { write create connect };
> }
>
> #============= clamd_t ==============
> corenet_tcp_bind_generic_port(clamd_t)
>
> #============= clamscan_t ==============
> allow clamscan_t self:tcp_socket { write create connect };
> 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)
> ##########################################
This seems consistent with the denials you reported.
Ideally we'd identify specific types for the ports to which it is
binding and connecting and only give access to those ports rather than
opening up generic port access. That would be done via semanage port,
similar to the semanage fcontext commands you ran earlier. But if you
primarily just want your system to work right now, you can use the above
module, and wait on the upstream policy to catch up. Reporting the avc
denials from audit.log to this list or to the upstream selinux list will
generally ensure that they get addressed in the future.
--
Stephen Smalley
National Security Agency
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
