Bug 728957 - User managed fetchmail forbidden after selinux upgrade
Summary: User managed fetchmail forbidden after selinux upgrade
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy
Version: 5.7
Hardware: All
OS: Linux
medium
low
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-08 13:35 UTC by Paolo Loggia
Modified: 2012-10-16 11:41 UTC (History)
2 users (show)

Fixed In Version: selinux-policy-2.4.6-318.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-21 05:47:49 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0158 0 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2012-02-20 14:53:50 UTC

Description Paolo Loggia 2011-08-08 13:35:05 UTC
Description of problem:
  Some users had fetchmail to get private external email.
  This problem show up after upgrading to 5.7, it worked before.
  Same alert show up for the file /home/user01/fetchmail.log.

Version-Release number of selected component (if applicable):
  selinux-policy-2.4.6-316.el5
  selinux-policy-devel-2.4.6-316.el5
  selinux-policy-targeted-2.4.6-316.el5

How reproducible:
  example of user's .fetchmailrc

  set daemon 5
  set logfile /home/user01/fetchmail.log
  poll mail.mydomain.in user user01

  
Actual results:
  I forced the system on permissive mode to restore functionality.

Expected results:
  Users should be able to use fetchmail to get their preferred email.

Additional info:

It seems that the alert is wrong: the files are on user's home directory, under user control, should be permitted to have an user managed service like this one. 
Complete sealert following:

Summary:

SELinux is preventing the fetchmail from using potentially mislabeled files
(/home/user01/.fetchmailrc).

Detailed Description:

[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]

SELinux has denied fetchmail access to potentially mislabeled file(s)
(/home/user01/.fetchmailrc). This means that SELinux will not allow fetchmail 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 fetchmail to access this files, you need to relabel them using
restorecon -v '/home/user01/.fetchmailrc'. You might want to relabel the entire
directory using restorecon -R -v '/home/user01'.

Additional Information:

Source Context                system_u:system_r:fetchmail_t
Target Context                user_u:object_r:user_home_t
Target Objects                /home/user01/.fetchmailrc [ file ]
Source                        fetchmail
Source Path                   /usr/bin/fetchmail
Port                          <Unknown>
Host                          prod01.mydomain.in
Source RPM Packages           fetchmail-6.3.6-1.1.el5_3.1
Target RPM Packages
Policy RPM                    selinux-policy-2.4.6-316.el5
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Permissive
Plugin Name                   home_tmp_bad_labels
Host Name                     prod01.mydomain.in
Platform                      Linux prod01.mydomain.in 2.6.18-274.el5 #1 SMP Fri
                              Jul 8 17:36:59 EDT 2011 x86_64 x86_64
Alert Count                   60
First Seen                    Mon Aug  8 08:03:43 2011
Last Seen                     Mon Aug  8 12:00:05 2011
Local ID                      377ea464-8f3a-40f8-b95c-064cd0f72680
Line Numbers

Raw Audit Messages

host=prod01.mydomain.in type=AVC msg=audit(1312797605.960:1171): avc:  denied  { getattr } for  pid=8244 comm="fetchmail" path="/home/user01/.fetchmailrc" dev=dm-0 ino=1967299 scontext=system_u:system_r:fetchmail_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file

host=prod01.mydomain.in type=SYSCALL msg=audit(1312797605.960:1171): arch=c000003e syscall=4 success=yes exit=0 a0=197f2c10 a1=7fffa3705ed0 a2=7fffa3705ed0 a3=5 items=0 ppid=1 pid=8244 auid=4294967295 uid=1101 gid=1101 euid=1101 suid=1101 fsuid=1101 egid=1101 sgid=1101 fsgid=1101 tty=(none) ses=4294967295 comm="fetchmail" exe="/usr/bin/fetchmail" subj=system_u:system_r:fetchmail_t:s0 key=(null)

Comment 1 Daniel Walsh 2011-08-08 15:32:40 UTC
If you were in enforcing mode this process would not be allowed to get to this file.  What is in .fetchmailrc?

Comment 2 Paolo Loggia 2011-08-08 16:17:16 UTC
Even if the file is in the home directory of the user?

most of the time just this few lines:

  set daemon 5
  set logfile /home/user01/fetchmail.log
  poll mail.mydomain.in user user01

most user connect to an internal imap server, some to an external server.

And i have to say that it worked fine before.

Comment 3 Miroslav Grepl 2011-10-18 06:35:07 UTC
I will treat it like in the procmail policy

HOME_DIR/\.procmailrc -- gen_context(system_u:object_r:procmail_home_t, s0)
/root/\.procmailrc -- gen_context(system_u:object_r:procmail_home_t, s0)

list_dirs_pattern(procmail_t, procmail_home_t, procmail_home_t)
read_files_pattern(procmail_t, procmail_home_t, procmail_home_t)
userdom_search_user_home_dirs(procmail_t)
userdom_search_admin_dir(procmail_t)

Comment 4 Miroslav Grepl 2011-10-20 14:36:07 UTC
Fixed in selinux-policy-2.4.6-318.el5

Comment 7 errata-xmlrpc 2012-02-21 05:47:49 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0158.html


Note You need to log in before you can comment on or make changes to this bug.