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)
If you were in enforcing mode this process would not be allowed to get to this file. What is in .fetchmailrc?
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.
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)
Fixed in selinux-policy-2.4.6-318.el5
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