Partitions Mounted by fstab

[Arthur Dent]

Hello Chaps,

I'm running SELinux in permissive mode on F8. I was thinking of switching to
enforcing mode and took a peek inside /var/log/messages to see what denials
SELinux is currently reporting. I was *horrified* - there must be thousands
there! Doing "cat /var/log/audit/audit.log" is even worse - it takes about a
minute to
scroll through!

They mainly relate to procmail, clamd and samba but I get many reports of
incorrectly labelled files (file_t).

I want to tackle these one step at a time and I think the first place to start
is with the incorrectly labelled files.

I have tried the "touch ./autorelabel; reboot" trick (several times!) but I
still get the same errors.

As a mater of interest, I have a procmail recipe which writes a copy of every
mail I receive to a backup area on my /dev/sda8 partition, mounted as
/mnt/backup/ by fstab. (It is an ext3 partition).

I have tried doing:
"restorecon -v -R /mnt/backup"
and even:
"fixfiles relabel"

on this partition, but I gather this will not work. I think that I must
somehow define a policy for this (and probably other) partition(s), but I am
unclear as to how to go about this.

I am reasonably familiar with Linux generally, but am a complete SELinux
virgin (and frankly scared silly of it). I normally turn off SELinux as my
first action after installing a distro, but I think it's about time I got to
grips with its security benefits.

I would be very grateful therefore if someone could hold my hand through this
learning process!

I have to run this particular box headless and access via ssh so I have to do
everything with command-line tools.


Thanks in advance...

Mark

[Stephen Smalley]

On Wed, 2008-03-05 at 15:16 +0000, Arthur Dent wrote:
>  Hello Chaps,
>  
>  I'm running SELinux in permissive mode on F8. I was thinking of switching to
>  enforcing mode and took a peek inside /var/log/messages to see what denials
>  SELinux is currently reporting. I was *horrified* - there must be thousands
>  there! Doing "cat /var/log/audit/audit.log" is even worse - it takes about a
> minute to
>  scroll through!
>  
>  They mainly relate to procmail, clamd and samba but I get many reports of
>  incorrectly labelled files (file_t).
>  
>  I want to tackle these one step at a time and I think the first place to start
>  is with the incorrectly labelled files.
>  
>  I have tried the "touch ./autorelabel; reboot" trick (several times!) but I
>  still get the same errors.
>  
>  As a mater of interest, I have a procmail recipe which writes a copy of every
>  mail I receive to a backup area on my /dev/sda8 partition, mounted as
>  /mnt/backup/ by fstab. (It is an ext3 partition).
>  
>  I have tried doing:
>  "restorecon -v -R /mnt/backup"
>  and even:
>  "fixfiles relabel"
>  
>  on this partition, but I gather this will not work. I think that I must
>  somehow define a policy for this (and probably other) partition(s), but I am
>  unclear as to how to go about this. 
You might try something like this, assuming that you only store mail
files under /mnt/backup and only procmail requires access:

semanage fcontext -a -t mail_spool_t "/mnt/backup(/.*)?"
restorecon -v -R /mnt/backup

If you need other things to be able to access it, then we'll have to
know more to decide how to label it, or you could possibly move it to a
subdir of /mnt/backup like /mnt/backup/spool that can be devoted to
procmail's use.

>  I am reasonably familiar with Linux generally, but am a complete
> SELinux
>  virgin (and frankly scared silly of it). I normally turn off SELinux as my
>  first action after installing a distro, but I think it's about time I got to
>  grips with its security benefits.
>  
>  I would be very grateful therefore if someone could hold my hand through this
>  learning process!
>  
>  I have to run this particular box headless and access via ssh so I have to do
>  everything with command-line tools.
>  
>  
>  Thanks in advance...
>  
>  Mark
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
-- 
Stephen Smalley
National Security Agency

[Arthur Dent]

On Wed, Mar 05, 2008 at 10:47:15AM -0500, Stephen Smalley wrote:

Hi Stephen,

>  > 
>  > As a mater of interest, I have a procmail recipe which writes a copy of every
>  > mail I receive to a backup area on my /dev/sda8 partition, mounted as
>  > /mnt/backup/ by fstab. (It is an ext3 partition).
>  > 
>  > I have tried doing:
>  > "restorecon -v -R /mnt/backup"
>  > and even:
>  > "fixfiles relabel"
>  > 
>  > on this partition, but I gather this will not work. I think that I must
>  > somehow define a policy for this (and probably other) partition(s), but I am
>  > unclear as to how to go about this.
>  
>  You might try something like this, assuming that you only store mail
>  files under /mnt/backup and only procmail requires access:
>  
>  semanage fcontext -a -t mail_spool_t "/mnt/backup(/.*)?"
>  restorecon -v -R /mnt/backup
>   
Thanks! This is really helpful. 

>  If you need other things to be able to access it, then we'll have
> to
>  know more to decide how to label it, or you could possibly move it to a
>  subdir of /mnt/backup like /mnt/backup/spool that can be devoted to
>  procmail's use.
>   
Well, before I try the above commands...

Generally it is only procmail that needs access, however, I have this file
"rotated" by logrotate (run as root) on a monthly basis. It is rotated with
the "date" extension and that file is archived by a cron job (root) to DVD.

Oh, and I have a daily backup routine that uses "tar" run from a cron job that
also includes this directory...

Will those things invalidate your suggested solution?

Thanks again for you help so far. Much Appreciated...


Mark

[Stephen Smalley]

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:
>  
>  Hi Stephen,
>  
>  > > 
>  > > As a mater of interest, I have a procmail recipe which writes a copy of every
>  > > mail I receive to a backup area on my /dev/sda8 partition, mounted as
>  > > /mnt/backup/ by fstab. (It is an ext3 partition).
>  > > 
>  > > I have tried doing:
>  > > "restorecon -v -R /mnt/backup"
>  > > and even:
>  > > "fixfiles relabel"
>  > > 
>  > > on this partition, but I gather this will not work. I think that I must
>  > > somehow define a policy for this (and probably other) partition(s), but I am
>  > > unclear as to how to go about this.
>  > 
>  > You might try something like this, assuming that you only store mail
>  > files under /mnt/backup and only procmail requires access:
>  > 
>  > semanage fcontext -a -t mail_spool_t "/mnt/backup(/.*)?"
>  > restorecon -v -R /mnt/backup
>  > 
>  Thanks! This is really helpful. 
>  
>  > If you need other things to be able to access it, then we'll have to
>  > know more to decide how to label it, or you could possibly move it to a
>  > subdir of /mnt/backup like /mnt/backup/spool that can be devoted to
>  > procmail's use.
>  > 
>  
>  Well, before I try the above commands...
>  
>  Generally it is only procmail that needs access, however, I have this file
>  "rotated" by logrotate (run as root) on a monthly basis. It is rotated with
>  the "date" extension and that file is archived by a cron job (root) to DVD.
>  
>  Oh, and I have a daily backup routine that uses "tar" run from a cron job that
>  also includes this directory...
>  
>  Will those things invalidate your suggested solution? 
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

-- 
Stephen Smalley
National Security Agency

[Stephen Smalley]

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:
>  > 
>  > Hi Stephen,
>  > 
>  > > > 
>  > > > As a mater of interest, I have a procmail recipe which writes a copy of
> every
>  > > > mail I receive to a backup area on my /dev/sda8 partition, mounted as
>  > > > /mnt/backup/ by fstab. (It is an ext3 partition).
>  > > > 
>  > > > I have tried doing:
>  > > > "restorecon -v -R /mnt/backup"
>  > > > and even:
>  > > > "fixfiles relabel"
>  > > > 
>  > > > on this partition, but I gather this will not work. I think that I must
>  > > > somehow define a policy for this (and probably other) partition(s), but I
> am
>  > > > unclear as to how to go about this.
>  > > 
>  > > You might try something like this, assuming that you only store mail
>  > > files under /mnt/backup and only procmail requires access:
>  > > 
>  > > semanage fcontext -a -t mail_spool_t "/mnt/backup(/.*)?"
>  > > restorecon -v -R /mnt/backup
>  > > 
>  > Thanks! This is really helpful. 
>  > 
>  > > If you need other things to be able to access it, then we'll have to
>  > > know more to decide how to label it, or you could possibly move it to a
>  > > subdir of /mnt/backup like /mnt/backup/spool that can be devoted to
>  > > procmail's use.
>  > > 
>  > 
>  > Well, before I try the above commands...
>  > 
>  > Generally it is only procmail that needs access, however, I have this file
>  > "rotated" by logrotate (run as root) on a monthly basis. It is rotated
> with
>  > the "date" extension and that file is archived by a cron job (root) to
> DVD.
>  > 
>  > Oh, and I have a daily backup routine that uses "tar" run from a cron job
> that
>  > also includes this directory...
>  > 
>  > Will those things invalidate your suggested solution?
>  
>  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 
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.

-- 
Stephen Smalley
National Security Agency

[Arthur Dent]

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

[Arthur Dent]

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)
##########################################


Mark

[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

[Stephen Smalley]

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

[Arthur Dent]

On Thu, Mar 06, 2008 at 08:43:26AM -0500, Stephen Smalley wrote:
>  
>  > 
>  > 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. 
Hi Stephen,

Yes, I know it's a bit off-topic for this list (well totally OT really)
but why does clamd bind to a different port each time? Is that normal
behaviour for clamd or have I got something borked in my setup?

Anyway it works (I think)!

Thanks very much for all the help and support so far. Now that I have
discovered audit2allow there's no stopping me!...

I have no idea what most of the things are for, but if I'm careful about
watching where the denials take place, is it usually safe to trust
audit2allow to create policies for me?

After much watching and tail -f ing of logs, here is what I have ended
up with...


##########################################
# cat myclamd.te
policy_module(myclamd, 1.2)
require {
        type clamscan_t;
        type clamd_t;
        class tcp_socket { write create connect };
        type var_run_t;
        type user_home_t;
        class sock_file write;
        class file append;

}

#============= clamd_t ==============
corenet_tcp_bind_generic_port(clamd_t)

#============= clamscan_t ==============
allow clamscan_t self:tcp_socket { write create connect };
allow clamscan_t user_home_t:file append;
allow clamscan_t var_run_t:sock_file write;
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)
##########################################


It's still Greek to me. I hope I haven't compromised my system in any way...

I have just typed "setenforce 1" - Yay! (Expect to hear back from me
with tales of woe when it won't work anymore!...

Thanks again


Mark

[Stephen Smalley]

On Thu, 2008-03-06 at 14:45 +0000, Arthur Dent wrote:
>  Hi Stephen,
>  
>  Yes, I know it's a bit off-topic for this list (well totally OT really)
>  but why does clamd bind to a different port each time? Is that normal
>  behaviour for clamd or have I got something borked in my setup? 
Some daemons scan for any available port within a given range, and take
the first one available, for transient ports used for data transfer (vs.
well-known ports).

>  Anyway it works (I think)!
>  
>  Thanks very much for all the help and support so far. Now that I have
>  discovered audit2allow there's no stopping me!...
>  
>  I have no idea what most of the things are for, but if I'm careful about
>  watching where the denials take place, is it usually safe to trust
>  audit2allow to create policies for me? 
audit2allow just turns every denial into an allow rule.  So it can't for
example tell you that the real reason you had a denial was because you
had a mislabeled file.  Your /mnt/backup situation is an example where
audit2allow would have given you the wrong solution - allowing access to
the default type of /mnt rather than properly configuring your policy to
label /mnt/backup with a suitable type.

setroubleshoot tries to give you more help via a heuristics-based set of
plugins, but it doesn't really have a semantic understanding of the
policy, so it too is limited in what it can achieve.  But setroubleshoot
can sometimes tell you that a file is mislabeled or that you just need
to enable some policy boolean.

There is ongoing work in policy tools to bridge the semantic gap.

>  After much watching and tail -f ing of logs, here is what I have
> ended
>  up with...
>  
>  
>  ##########################################
>  # cat myclamd.te
>  policy_module(myclamd, 1.2)
>  require {
>          type clamscan_t;
>          type clamd_t;
>          class tcp_socket { write create connect };
>          type var_run_t;
>          type user_home_t;
>          class sock_file write;
>          class file append;
>  
>  }
>  
>  #============= clamd_t ==============
>  corenet_tcp_bind_generic_port(clamd_t)
>  
>  #============= clamscan_t ==============
>  allow clamscan_t self:tcp_socket { write create connect };
>  allow clamscan_t user_home_t:file append; 
What file in your home directory is clamscan appending to?
Maybe we can put it into a distinct type and protect the rest of your
files?

>  allow clamscan_t var_run_t:sock_file write; 
This suggests that something is creating a socket under /var/run without
properly putting it into a distinct type.

>  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)
>  ##########################################
>  
>  
>  It's still Greek to me. I hope I haven't compromised my system in any way...
You can't make your system weaker than it was without SELinux in this
manner, since all you are doing is loosening the SELinux restrictions -
the usual DAC restrictions still apply.  So all you are doing is
altering the extent to which SELinux is protecting you.

>  I have just typed "setenforce 1" - Yay! (Expect to hear
> back from me
>  with tales of woe when it won't work anymore!... 
-- 
Stephen Smalley
National Security Agency

[Arthur Dent]

On Thu, Mar 06, 2008 at 10:23:53AM -0500, Stephen Smalley wrote:
>  
>  > # cat myclamd.te
>  > policy_module(myclamd, 1.2)
>  > require {
>  >         type clamscan_t;
>  >         type clamd_t;
>  >         class tcp_socket { write create connect };
>  >         type var_run_t;
>  >         type user_home_t;
>  >         class sock_file write;
>  >         class file append;
>  > 
>  > }
>  > 
>  > #============= clamd_t ==============
>  > corenet_tcp_bind_generic_port(clamd_t)
>  > 
>  > #============= clamscan_t ==============
>  > allow clamscan_t self:tcp_socket { write create connect };
>  > allow clamscan_t user_home_t:file append;
>  
>  What file in your home directory is clamscan appending to?
>  Maybe we can put it into a distinct type and protect the rest of your
>  files?
>   
Not sure... clamd is used by clamassassin which is called by procmail.

Procmail has local configurations set in various "rc" files in
~/Procmail/ in my home directory. But only procmail would require (read)
access to those. Then procmail writes to its log which is
~/Procmail/pmlog (also rotated by logrotate).

I'll try commenting out that line and see what happens...

Thanks

Mark

[Arthur Dent]

On Thu, Mar 06, 2008 at 03:46:28PM +0000, Arthur Dent wrote:
>  > 
>  > What file in your home directory is clamscan appending to?
>  > Maybe we can put it into a distinct type and protect the rest of your
>  > files?
>  > 
>  Not sure... clamd is used by clamassassin which is called by procmail.
>  
>  Procmail has local configurations set in various "rc" files in
>  ~/Procmail/ in my home directory. But only procmail would require (read)
>  access to those. Then procmail writes to its log which is
>  ~/Procmail/pmlog (also rotated by logrotate).
>  
>  I'll try commenting out that line and see what happens...
>   
And here's what happens...

Summary:

SELinux is preventing the clamdscan from using potentially mislabeled
files
(/home/mark/Procmail/pmlog).

Detailed Description:

SELinux has denied clamdscan access to potentially mislabeled file(s)
(/home/mark/Procmail/pmlog). This means that SELinux will not allow
clamdscan to
use these files. It is common for users to edit files in their home
directory or
tmp directories and then move (mv) them to system directories. The
problem is
that the files end up with the wrong file context which confined
applications
are not allowed to access.

Allowing Access:

If you want clamdscan to access this files, you need to relabel them
using
restorecon -v '/home/mark/Procmail/pmlog'. You might want to relabel the
entire
directory using restorecon -R -v '/home/mark/Procmail'.

Additional Information:

Source Context                system_u:system_r:clamscan_t:s0
Target Context                system_u:object_r:user_home_t:s0
Target Objects                /home/mark/Procmail/pmlog [ file ]
Source                        clamdscan
Source Path                   /usr/bin/clamdscan
Port                          <Unknown>
Host                          mydomain.org.uk
Source RPM Packages           clamav-0.92.1-1.fc8
Target RPM Packages           
Policy RPM                    selinux-policy-3.0.8-87.fc8
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   home_tmp_bad_labels
Host Name                     mydomain.org.uk
Platform                      Linux mydomain.org.uk 2.6.23.15-137.fc8 #1
SMP Sun
                              Feb 10 17:48:34 EST 2008 i686 i686
Alert Count                   1
First Seen                    Thu Mar  6 15:48:08 2008
Last Seen                     Thu Mar  6 15:48:08 2008
Local ID                      1a0e8006-5ae4-41dc-90e3-419c7c32c2b0
Line Numbers                  

Raw Audit Messages            

host=mydomain.org.uk type=AVC msg=audit(1204818488.711:155): avc:
denied  { append } for  pid=3820 comm="clamdscan"
path="/home/mark/Procmail/pmlog" dev=sda12 ino=1426472
scontext=system_u:system_r:clamscan_t:s0
tcontext=system_u:object_r:user_home_t:s0 tclass=file

host=mydomain.org.uk type=SYSCALL msg=audit(1204818488.711:155):
arch=40000003 syscall=11 success=yes exit=0 a0=933c210 a1=933aa28
a2=93381b0 a3=40 items=0 ppid=3816 pid=3820 auid=4294967295 uid=0 gid=12
euid=0 suid=0 fsuid=0 egid=12 sgid=12 fsgid=12 tty=(none)
comm="clamdscan" exe="/usr/bin/clamdscan"
subj=system_u:system_r:clamscan_t:s0 key=(null)

[Stephen Smalley]

On Thu, 2008-03-06 at 15:53 +0000, Arthur Dent wrote:
>  On Thu, Mar 06, 2008 at 03:46:28PM +0000, Arthur Dent wrote:
>  > > 
>  > > What file in your home directory is clamscan appending to?
>  > > Maybe we can put it into a distinct type and protect the rest of your
>  > > files?
>  > > 
>  > Not sure... clamd is used by clamassassin which is called by procmail.
>  > 
>  > Procmail has local configurations set in various "rc" files in
>  > ~/Procmail/ in my home directory. But only procmail would require (read)
>  > access to those. Then procmail writes to its log which is
>  > ~/Procmail/pmlog (also rotated by logrotate).
>  > 
>  > I'll try commenting out that line and see what happens...
>  > 
>  And here's what happens...
>  
>  Summary:
>  
>  SELinux is preventing the clamdscan from using potentially mislabeled
>  files
>  (/home/mark/Procmail/pmlog).
>  
>  Detailed Description:
>  
>  SELinux has denied clamdscan access to potentially mislabeled file(s)
>  (/home/mark/Procmail/pmlog). This means that SELinux will not allow
>  clamdscan to
>  use these files. It is common for users to edit files in their home
>  directory or
>  tmp directories and then move (mv) them to system directories. The
>  problem is
>  that the files end up with the wrong file context which confined
>  applications
>  are not allowed to access.
>  
>  Allowing Access:
>  
>  If you want clamdscan to access this files, you need to relabel them
>  using
>  restorecon -v '/home/mark/Procmail/pmlog'. You might want to relabel the
>  entire
>  directory using restorecon -R -v '/home/mark/Procmail'.
>  
>  Additional Information:
>  
>  Source Context                system_u:system_r:clamscan_t:s0
>  Target Context                system_u:object_r:user_home_t:s0
>  Target Objects                /home/mark/Procmail/pmlog [ file ]
>  Source                        clamdscan
>  Source Path                   /usr/bin/clamdscan
>  Port                          <Unknown>
>  Host                          mydomain.org.uk
>  Source RPM Packages           clamav-0.92.1-1.fc8
>  Target RPM Packages           
>  Policy RPM                    selinux-policy-3.0.8-87.fc8
>  Selinux Enabled               True
>  Policy Type                   targeted
>  MLS Enabled                   True
>  Enforcing Mode                Enforcing
>  Plugin Name                   home_tmp_bad_labels
>  Host Name                     mydomain.org.uk
>  Platform                      Linux mydomain.org.uk 2.6.23.15-137.fc8 #1
>  SMP Sun
>                                Feb 10 17:48:34 EST 2008 i686 i686
>  Alert Count                   1
>  First Seen                    Thu Mar  6 15:48:08 2008
>  Last Seen                     Thu Mar  6 15:48:08 2008
>  Local ID                      1a0e8006-5ae4-41dc-90e3-419c7c32c2b0
>  Line Numbers                  
>  
>  Raw Audit Messages            
>  
>  host=mydomain.org.uk type=AVC msg=audit(1204818488.711:155): avc:
>  denied  { append } for  pid=3820 comm="clamdscan"
>  path="/home/mark/Procmail/pmlog" dev=sda12 ino=1426472
>  scontext=system_u:system_r:clamscan_t:s0
>  tcontext=system_u:object_r:user_home_t:s0 tclass=file
>  
>  host=mydomain.org.uk type=SYSCALL msg=audit(1204818488.711:155):
>  arch=40000003 syscall=11 success=yes exit=0 a0=933c210 a1=933aa28
>  a2=93381b0 a3=40 items=0 ppid=3816 pid=3820 auid=4294967295 uid=0 gid=12
>  euid=0 suid=0 fsuid=0 egid=12 sgid=12 fsgid=12 tty=(none)
>  comm="clamdscan" exe="/usr/bin/clamdscan"
>  subj=system_u:system_r:clamscan_t:s0 key=(null) 
Ok, so it is just appending to a log file there, possibly via an
inherited descriptor from the caller.

You could possibly put a different type on ~/Procmail and only give
permissions to that type, but offhand I don't see an existing type that
would fit for that purpose, so you'd have to define a new one.  Likely
more work than you want to deal with right now.

The good news is that it only requires append access, so it cannot
overwrite an existing file's contents even if you allow the above.

-- 
Stephen Smalley
National Security Agency