Bug 168027

Summary: smtp to sendmail from network prevented when setenforce=1
Product: [Fedora] Fedora Reporter: Steve Kramer <bugzilla>
Component: selinux-policy-targetedAssignee: Daniel Walsh <dwalsh>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-24 16:42:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Steve Kramer 2005-09-11 01:46:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

Description of problem:
This is running as a SELinux targeted policy.
When setenforce is 0, I can sendmail from an Outlook 2K client on the network using SSL on port 25.  When setenforce is set to 1, it is prevented.  The Outlook client keeps on presenting the User Name/Password dialog box, and the maillog shows:
[w.x.y.z]: did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Resetting SELinux to permissive, the smtp succeeds.

The audit.log show no record for the failure.

I'm using sendmail-8.13.4-2 (actually, everything is up-to-date via yum today).

Version-Release number of selected component (if applicable):
selinux-policy-targeted-1.25.4-10.1

How reproducible:
Always

Steps to Reproduce:
1.Set up sendmail to accept SSL smtp on port 25 from an Outlook 2K client.
2.setenforce 1
3.Send mail to FC4 server via Outlook 2K
  

Actual Results:  The mail session fails - outlook keeps on asking for user/password, and sendmail (in maillog) says MAIL/EXPN/VRFY/ETRN was not issued.

Expected Results:  The mail should have gone through as it does with setenforce=0.

Additional info:

Workaround:
# setenforce Permissive

Comment 1 Daniel Walsh 2005-09-21 18:39:30 UTC
What avc messages are you seeing in /var/log/messages or /var/log/audit/audit.log?

Dan

Comment 2 Steve Kramer 2005-09-21 19:30:19 UTC
There are no entries in either /var/log/messages or /var/log/audit/audit.log .
--steve

Comment 3 Daniel Walsh 2005-09-22 14:07:32 UTC
Can you ps -eZ | grep sendmail


Do you have policy sources installed?

If yes could you do a 

cd /etc/selinux/targeted/src/policy
make enabledaudit; make load

Then see if there are any avc messages?

Comment 4 Steve Kramer 2005-09-24 16:42:59 UTC
Here's the data, but after the elapsed time, and yum updates, the sendmail
problem went away.  You can close this bug.

#
# ps -eZ|grep sendmail
system_u:system_r:kernel_t       3352 ?        00:00:00 sendmail-milter
system_u:system_r:kernel_t       3367 ?        00:00:00 sendmail
system_u:system_r:kernel_t       3373 ?        00:00:00 sendmail
#
# make enableaudit; make load
grep -v dontaudit policy.conf > policy.audit
mv policy.audit policy.conf
Compiling policy ...
/usr/bin/checkpolicy  -o /etc/selinux/targeted/policy/policy.19 policy.conf
/usr/bin/checkpolicy:  loading policy configuration from policy.conf
security:  3 users, 6 roles, 872 types, 101 bools
security:  55 classes, 203038 rules
/usr/bin/checkpolicy:  policy configuration loaded
/usr/bin/checkpolicy:  writing binary representation (version 19) to
/etc/selinux/targeted/policy/policy.19
Loading Policy ...
/usr/sbin/load_policy /etc/selinux/targeted/policy/policy.19
touch tmp/load
install -m 644 tmp/system.users /etc/selinux/targeted/users/system.users
install -m 644 tmp/customizable_types
/etc/selinux/targeted/contexts/customizable_types 
install -m 644 tmp/port_types /etc/selinux/targeted/contexts/port_types 
Installing file contexts files...
install -m 644 file_contexts/homedir_template
/etc/selinux/targeted/contexts/files/homedir_template
install -m 644 file_contexts/file_contexts
/etc/selinux/targeted/contexts/files/file_contexts
#

Here are avc messages from /var/log/messages:
Sep 24 12:26:44 bastion kernel: security:  9 users, 6 roles, 872 types, 101 bools
Sep 24 12:26:44 bastion kernel: security:  55 classes, 203038 rules
Sep 24 12:26:44 bastion dbus: avc:  received policyload notice (seqno=8)
Sep 24 12:26:44 bastion dbus: avc:  0 AV entries and 0/512 buckets used, longest
chain length 0
Sep 24 12:26:44 bastion dbus: avc:  received policyload notice (seqno=8)
Sep 24 12:26:44 bastion dbus: avc:  1 AV entries and 1/512 buckets used, longest
chain length 1
Sep 24 12:26:44 bastion dbus: avc:  received policyload notice (seqno=8)
Sep 24 12:26:44 bastion dbus: avc:  0 AV entries and 0/512 buckets used, longest
chain length 0
Sep 24 12:26:44 bastion dbus: avc:  received policyload notice (seqno=8)
Sep 24 12:26:44 bastion dbus: avc:  0 AV entries and 0/512 buckets used, longest
chain length 0
Sep 24 12:26:44 bastion dbus: avc:  received policyload notice (seqno=8)
Sep 24 12:26:44 bastion dbus: avc:  0 AV entries and 0/512 buckets used, longest
chain length 0

From /var/log/audit/audit.log:
type=SYSCALL msg=audit(1127579204.347:13258799): arch=40000003 syscall=4
success=yes exit=5801251 a0=4 a1=b7286008 a2=588523 a3=bfae0fbc items=0
pid=30546 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="load_policy" exe="/usr/sbin/load_policy"