On Wed, Mar 05, 2008 at 12:02:40PM -0500, Stephen Smalley wrote:
>
> On Wed, 2008-03-05 at 11:59 -0500, Stephen Smalley wrote:
> > On Wed, 2008-03-05 at 16:12 +0000, Arthur Dent wrote:
> > > On Wed, Mar 05, 2008 at 10:47:15AM -0500, Stephen Smalley wrote:
> > >
> >
> > You'll likely need a local policy module then to permit such access
> > in addition to the commands above.
> > Maybe something like this:
> >
> > # cat mymailbackup.te
> > policy_module(mybackup, 1.0)
> > require {
> > # Symbols defined outside of this module.
> > type system_crond_t;
> > type user_crond_t;
> > type mail_spool_t;
> > }
> >
> > # Mark mail_spool_t as a log file that can be managed by logrotate.
> > logging_log_file(mail_spool_t)
> > # Let system and user cron jobs read it.
> > read_files_pattern(system_crond_t, mail_spool_t, mail_spool_t)
> > read_files_pattern(user_crond_t, mail_spool_t, mail_spool_t)
> >
> > # make -f /usr/share/selinux/devel/Makefile mybackup.pp
> > # semodule -i mybackup.pp
This is fantastically helpful. Thank you so much!
> Actually, did you need write access to /mnt/backup from the cron job, or
> only read access? The above only gives read access.
>
> Also, on second thought, I suppose that if you are running these as user
> cron jobs, they'll run unconfined_t under the default targeted policy
> and thus not require any additional rules at all. So you may only need
> the logging_log_file() part.
Well actually the /mnt/backup directory contains 2 subdirs /data and
/mail.
The /mail dir contains the one backup file that procmail writes
to and the archives of that file created by logrotate (until they have
been copied onto a DVD by the cron job - which I guess is just a "read"
access.
The /data dir contains the daily incremental, and weekly full backups
created by tar running under cron (one version run as my user and one
version - for system files - run by root). Here I guess write access is
required, but as you say - running as a cron job.
I am so swamped with avc denial that I can't say for certain, but I
don't *think* I've seen any related to these jobs.
I have therefore implemented your policy with the "read_files" lines
commented out. Unfortunately I have only been able to do it this morning
and the cron job(s) run overnight - so I will wait to see what the
morning brings...
Thanks again.
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?
Thanks again. Your help is greatly appreciated.
Mark
> Stephen Smalley
> National Security Agency
Attachment:
pgpkf988R4zX9.pgp
Description: PGP signature
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
