Created attachment 467620 [details]
the sealert messages that showed up during the transitive closure

Created attachment 467621 [details]
the greylist file that drove this

note how the callout to /usr/bin/logger requires some extra policy machinery

The callout to /usr/bin/logger is suggested by the greylist authors in their example.

Of interest also is the tcp port communication with the peer MX once you've got something in the greylist.  You have to get the system to a point where you get something in the greylist and the need to peer communicate.

Created attachment 467622 [details]
the sendmail.mc that configures milter-greylist

This is included for completeness, to show that the behavior of milter-greylist as reported here was not dependent upon some odd configuration of sendmail.  Any configuration of sendmail that sets up milter-greylist should do fine for the purposes here.

I should also point out that to drive the transitive closure procedure shown above (the while loop) you need a constant rain of spam falling down about your site.  But of course, everyone has an overflowing supply that :-)

I do not think that it is possible to write a one-size-fits-all SELinux policy.  The shipped -targeted policy is a good framework, but every non trivial setup will require local adaptations.  Especially stuff like mail-filters is falling into this category because there are too many things possible which are needed for one environment but might be a security risk for other ones.

E.g. my local milter-greylist policy has

corenet_tcp_connect_spamd_port(greylist_milter_t);
corenet_tcp_connect_http_port(greylist_milter_t);

and defines a 'greylist_milter_shell_t' type for the logging script.  First two points can be perhaps solved cleanly by SELinux booleans, but the logging is environment specific and related rules can not be generalized.


I will reassign bug to selinux-policy...

Enrico, 
how does your greylist_milter_shell policy look? Could you attach this policy?

Wendell,
could you attach raw avc messages related to greylist_milter_t?

# grep greylist_milter_t /var/log/audit/audit.log > /tmp/greylist.log

Created attachment 468938 [details]
local milter greylist policy

sample policy; heavily tied to a logging script (http://www.cvg.de/people/ensc/grstat) which fills an rrd table

Created attachment 468948 [details]
sudo find /var/log/audit -type f -exec grep -e greylist_milter_t '{}' ';' > /tmp/greylist_milter_t.log

Wendell,
I have just done a scratch build available on

http://koji.fedoraproject.org/koji/taskinfo?taskID=2669855

Could you try to test selinux-policy and selinux-policy-targeted policy packages?

We're close ... a few more loose ends to tie up.

Success: milter-greylist functions to the extent that sendmail operates with it.
However: there are still permission issues with respect to
/var/milter-greylist/greylist.log

Mea culpa.  I did not report these before; apparenlty the previous policy proposal that I submitted wasn't complete.  The suggested remediation for that is another sealert pertaining to /sbin/setfiles 






(this is the "old" package set that I had on my system; see how the "new" package set is different)
[as wbaker:wbaker.baker.org]
$ rpm -q -a | grep selinux
libselinux-python-2.0.96-6.fc14.1.i686
libselinux-2.0.96-6.fc14.1.i686
libselinux-utils-2.0.96-6.fc14.1.i686
selinux-policy-targeted-3.9.7-16.fc14.noarch
selinux-policy-3.9.7-16.fc14.noarch


[as wbaker:wbaker.baker.org]
$ ls -lt ./incoming | head
total 4269200
-rw-rw-r--.  1 wbaker source   2490232 Dec 16 21:56 selinux-policy-targeted-3.9.7-18.fc14.noarch.rpm
-rw-------.  1 wbaker source    762288 Dec 16 19:33 selinux-policy-3.9.7-18.fc14.noarch.rpm
-rw-------.  1 wbaker source   1001473 Dec 16 19:33 selinux-policy-3.9.7-18.fc14.src.rpm
-rw-------.  1 wbaker source    501772 Dec 16 19:33 selinux-policy-doc-3.9.7-18.fc14.noarch.rpm
-rw-------.  1 wbaker source   2488552 Dec 16 19:33 selinux-policy-minimum-3.9.7-18.fc14.noarch.rpm
-rw-------.  1 wbaker source   2318540 Dec 16 19:33 selinux-policy-mls-3.9.7-18.fc14.noarch.rpm


[as wbaker:wbaker.baker.org]
$ declare -a files=(selinux-policy-targeted-3.9.7-18.fc14.noarch.rpm selinux-policy-3.9.7-18.fc14.noarch.rpm)
$ rpm --verbose --upgrade ${files[@]}
Preparing packages for installation...
selinux-policy-3.9.7-18.fc14
selinux-policy-targeted-3.9.7-18.fc14
Can't stat exclude path "/var/lib/BackupPC", No such file or directory - ignoring. <------------------ maybe this needs to be fixed

$ ls -ldZ /var/lib/BackupPC
ls: cannot access /var/lib/BackupPC: No such file or directory

(this reflects the potential for "BackupPC" to exist on my system; it does not)
$ rpm -q BackupPC
package BackupPC is not installed

(this reflects the potential for "BackupPC" to exist on my system; it does not)
$ rpm -q -a | grep -ie backup
<nothing>

(this reflects the potential for "BackupPC" to exist on my system; it does not)
$ rpm -q -a | grep -ie back
sane-backends-libs-gphoto2-1.0.21-5.fc14.i686
laughlin-backgrounds-single-14.1.0-1.fc14.noarch
desktop-backgrounds-basic-9.0.0-15.fc14.noarch
sane-backends-1.0.21-5.fc14.i686
gnome-backgrounds-2.32.0-1.fc14.noarch
laughlin-backgrounds-gnome-14.1.0-1.fc14.noarch
sane-backends-libs-1.0.21-5.fc14.i686


(this reflects the "new" package set that was just proposed)
$ rpm -q -a | grep selinux
selinux-policy-3.9.7-18.fc14.noarch
libselinux-python-2.0.96-6.fc14.1.i686
libselinux-2.0.96-6.fc14.1.i686
libselinux-utils-2.0.96-6.fc14.1.i686
selinux-policy-targeted-3.9.7-18.fc14.noarch


---> /var/log/messages shows

Dec 18 11:01:57 nineteen dhclient[1052]: DHCPACK from 192.168.0.47
Dec 18 11:01:59 nineteen dhclient[1052]: bound to 192.168.0.23 -- renewal in 258 seconds.
Dec 18 11:05:28 nineteen dbus: avc:  received policyload notice (seqno=3)
Dec 18 11:05:28 nineteen dbus: avc:  received policyload notice (seqno=3)
Dec 18 11:05:37 nineteen dbus: [system] Reloaded configuration


---> from /var/log/messages

(restart #1)
Dec 18 11:13:42 nineteen setroubleshoot: SELinux is preventing /usr/sbin/milter-greylist from append access on the file greylist.log. For complete SELinux messages. run sealert -l 670df6af-fa4c-433d-b8a4-10396db419ce
(restart #2)
Dec 18 11:20:29 nineteen setroubleshoot: SELinux is preventing /usr/sbin/milter-greylist from append access on the file greylist.log. For complete SELinux messages. run sealert -l 670df6af-fa4c-433d-b8a4-10396db419ce








$ sudo sealert -l 670df6af-fa4c-433d-b8a4-10396db419ce
[sudo] password for wbaker: 

SELinux is preventing /usr/sbin/milter-greylist from append access on the file greylist.log.

*****  Plugin catchall_labels (83.8 confidence) suggests  ********************

If you want to allow milter-greylist to have append access on the greylist.log file
Then you need to change the label on greylist.log
Do
# semanage fcontext -a -t FILE_TYPE 'greylist.log'
where FILE_TYPE is one of the following: user_home_t, greylist_milter_t, user_cron_spool_t, sosreport_tmp_t, logfile, rpm_tmp_t, greylist_milter_data_t, user_tmp_t, root_t. 
Then execute: 
restorecon -v 'greylist.log'


*****  Plugin catchall (17.1 confidence) suggests  ***************************

If you believe that milter-greylist should be allowed append access on the greylist.log file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do allow this access for now by executing:
# grep /usr/sbin/milter-greylist /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp







[as wbaker:wbaker.baker.org]

$ sudo semanage fcontext -a -t greylist_milter_t '/var/milter-greylist/greylist.log'

$ ls -lZ /var/milter-greylist/greylist.log 
-rw-r--r--. root root unconfined_u:object_r:var_t:s0   /var/milter-greylist/greylist.log

$ sudo restorecon -v /var/milter-greylist/greylist.log 
restorecon reset /var/milter-greylist/greylist.log context unconfined_u:object_r:var_t:s0->system_u:object_r:greylist_milter_t:s0
restorecon set context /var/milter-greylist/greylist.log->system_u:object_r:greylist_milter_t:s0 failed:'Permission denied'

$ ls -lZ /var/milter-greylist/greylist.log 
-rw-r--r--. root root unconfined_u:object_r:var_t:s0   /var/milter-greylist/greylist.log

---> from /var/log/messages

Dec 18 15:03:47 nineteen dbus: avc:  received policyload notice (seqno=3)
Dec 18 15:03:47 nineteen dbus: avc:  received policyload notice (seqno=3)
Dec 18 15:03:50 nineteen dbus: [system] Reloaded configuration
Dec 18 15:04:39 nineteen setroubleshoot: SELinux is preventing /sbin/setfiles from relabelto access on the file greylist.log. For complete SELinux messages. run sealert -l 89bda53f-91f7-49a8-be89-50f5e5f8d2d5




$ sudo sealert -l 89bda53f-91f7-49a8-be89-50f5e5f8d2d5
[sudo] password for wbaker: 
SELinux is preventing /sbin/setfiles from relabelto access on the file greylist.log.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that setfiles should be allowed relabelto access on the greylist.log file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep /sbin/setfiles /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp





And for completeness ... my greylist.conf file is "stock" with respect too the issues encountered here

$ head /etc/mail/greylist.conf
#
# Simple greylisting config file using the new features
# See greylist2.conf for a more detailed list of available options
#
# Originally: Id: greylist.conf,v 1.43 2008/02/27 05:00:54 manu Exp
#

#pidfile "/var/run/milter-greylist.pid"
socket "/var/run/milter-greylist/milter-greylist.sock"
dumpfile "/var/lib/milter-greylist/db/greylist.db" 755
dumpfreq 1
user "grmilter"

# greylist tuples live for 30 days
timeout 30d

# default greylist is 12 hours
greylist 12h

# match on subdomain boundaries instead of the default (pure) suffix matching
# NO  milter-greylist-4.1.1-2.fc10.i386    (pale)
# YES milter-greylist-4.2.3-1300.fc13.i686 (suffragette)
# domainexact

# Log milter-greylist activity to a file
stat ">>/var/milter-greylist/greylist.log" \
      "%T{%Y/%m/%d %T} %d [%i] %r -> %f %S (ACL %A) %Xc %Xe %Xm %Xh\n"
# Same, sent to syslog (use a full path for logger)
stat "|/usr/bin/logger -p local7.info" \
      "%T{%Y/%m/%d %T} %d [%i] %r -> %f %S (ACL %A) %Xc %Xe %Xm %Xh"

# Be verbose (or use -v flag)
#verbose

# Do not tell spammer how long they have to wait
quiet
<end>

The problem is you were trying to setup domain label for the milter log file. 

Just run

# semanage fcontext -d -t greylist_milter_t '/var/milter-greylist/greylist.log'
# chcon -R -t greylist_milter_data_t /var/milter-greylist