Partitions Mounted by fstab

[Stephen Smalley]

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