On Thu, 2008-03-06 at 10:07 +0000, Arthur Dent wrote:
> 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.
Then I would recommend using a different type on /mnt/backup/data(/.*)?
vs. /mnt/backup/mail(/.*)?. Then you can differentiate in policy what
can access each of them, so that your procmail job can't write to your
data/ subdirectory.
So you might do:
# delete the entry we added earlier for all of /mnt/backup
semanage fcontext -d "/mnt/backup(/.*)?"
# only apply mail_spool_t to the mail subdir
semanage fcontext -a -t mail_spool_t "/mnt/backup/mail(/.*)?"
# put some other type on the data subdir - depends on your goal
semanage fcontext -a -t <sometype> "/mnt/backup/data(/.*)?"
# apply the new labeling scheme to disk
restorecon -R -v /mnt/backup
> 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?
There is a clamd policy, but apparently it isn't sufficient for your
usage. But I see you've discovered audit2allow in a later message.
--
Stephen Smalley
National Security Agency
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
