7:32 a.m.
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