Bug 452248 - RFE: make the milter more postfix-friendly
Summary: RFE: make the milter more postfix-friendly
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: spamass-milter
Version: 9
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Paul Howarth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 483849
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-20 14:35 UTC by Gabriele Turchi
Modified: 2009-04-24 19:54 UTC (History)
3 users (show)

Fixed In Version: 0.3.1-13.fc9
Clone Of:
Environment:
Last Closed: 2009-04-23 10:14:42 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Patch to add a "-g" option (1.92 KB, patch)
2008-06-20 14:35 UTC, Gabriele Turchi
no flags Details | Diff
SELinux module for spamass-milter and postfix (1.04 KB, application/octet-stream)
2008-06-27 09:50 UTC, Gabriele Turchi
no flags Details

Description Gabriele Turchi 2008-06-20 14:35:54 UTC
Description of problem:
The milter is installed owned by sa-milt user and group. This behaviour is
less-than-optimal with a postfix installation.

Version-Release number of selected component (if applicable):


How reproducible:
Every time

Steps to Reproduce:
1. Start spamass-milter
2. Configure postfix to access the milter via unix socket
3.
  
Actual results:
Postfix (user postfix) can't access the socket

Expected results:
Filtered mail

Additional info: I've created a litte patch to add a "-g" option: the sockek
will be created group-owned by the indicated group, and its permission is
changed to 660. The sa-milt user should be added to the selected group by hand.

Comment 1 Gabriele Turchi 2008-06-20 14:35:54 UTC
Created attachment 309925 [details]
Patch to add a "-g" option

Comment 2 Paul Howarth 2008-06-20 14:57:24 UTC
Hmm, making the socket and/or its directory group-writeable will cause sendmail
configurations to break as it considers them "unsafe".

I don't see the need to add the sa-milt user to the group since the milter runs
as sa-milt and hence can write to the socket via the "user" permissions rather
than the "group" permissions.

I'm not familiar with postfix at all; I take it that the postfix process that
talks to the milter runs as user postfix? I think it might be a better option to
provide a separate socket directory with postfix-friendly permissions (probably
in a subpackage as it would need a dependency on postfix for the postfix
user/group) that could be used when running with postfix. Another possibility
might be to use an inet socket on localhost instead of a unix socket for use
with postfix?

Do you run with SELinux enabled? I'm in the process of writing an SELinux policy
for spamass-milter (and also milter-regex) and it would be useful to be able to
test it with postfix as well as my sendmail setup.


Comment 3 Gabriele Turchi 2008-06-20 15:38:58 UTC
I have not changed at all directory permissions (yet)... Mine is only a patch to
add an option, obviously not mandatory: if not needed nothing changed.

I think this patch is needed to make a clean postfix packaging, and other
changes should go to the spec/rpm.

In my installation the /var/run/spamass-milter is created with default
permissions (750 if I remember correctly). In my package I've changed to 751,
but I don't think could be a problem. I have also removed the sendmail
dependency: at least in theory the milter can run listening network connections
from other machines.

Right, postfix runs as postfix user and as postfix user connect to milter. 

If possible, I think inet sockets should be avoided - for performances and
security reasons.

Yes, I run with selinux enabled, but currently under a CentOS 5.1 or fedora 8,
fedora 9 not yet. Under CentOS I've backported the fedora 9 package.

Anyway, postfix access to socket should be granted, something like

allow postfix_smtpd_t spamd_var_run_t:dir search;
allow postfix_smtpd_t spamd_var_run_t:sock_file write;

If I could help more, please ask. :-)

GT


Comment 4 Paul Howarth 2008-06-20 16:11:55 UTC
I can't change the directory permissions for the existing directory without
breaking operation with sendmail, which is why I think a separate directory to
put the socket in for use with postfix makes more sense. The socket location
would be specified in /etc/sysconfig/spamass-milter. For the postfix location,
we could use the group that postfix runs as as GID, and make the directory
group-writeable. I'd need to include your patch to make it possible for the
socket to have the right permissions too of course.

Another possibility would be to run the milter as user postfix, but then you
would lose some of the security of the process separation.

I'll change the sendmail dependency to /usr/sbin/sendmail, which can be provided
by postfix (this is needed for use of the -b/-B/-x options).

In Fedora 9 there are bigger issues with SELinux and spamass-milter - see Bug
#447247. I'll update my current policy module with the postfix details you
posted and attach it here later on so you can give it a try. I'm in the process
of trying to get it merged into upstream reference policy so the more testing it
gets, the better, particularly from a postfix user as that's not something I can
try myself. I'm not sure if the spamc interface "spamassassin_domtrans_spamc"
that I've been using exists on F8/CentOS5; I'll need to check that. Do you have
access to any F9 boxes to try this?


Comment 5 Gabriele Turchi 2008-06-21 06:49:53 UTC
Currently I'm testing the f9 rpm under CentOS 5 with only minor modifications
(directory permissions and senmail requirement removed), and apparentrly no
problem surfaced. I'll do more tests. I think during next week I can do some
test under a (clean) fedora 9. Can you send me/make available an already
modified rpm as discussed before?

I currently use only -m and -r options, I should try even other options.

Comment 6 Paul Howarth 2008-06-21 08:58:49 UTC
You'll need Fedora 9 to test the policy as it uses an interface that's not
present in Fedora 8. That's no big deal really as the Fedora 8 standard policy
works OK, which is not the case in Fedora 9.

I'll try to find some time to update the package over the weekend.

Comment 7 Paul Howarth 2008-06-21 22:49:27 UTC
Just noticed that postfix's documentation for running milters
(http://www.postfix.org/MILTER_README.html) suggests using a TCP socket on
localhost:

   To run a Milter application, see the documentation of the filter for
   options. A typical command looks like this:

   # /some/where/dkim-filter -u userid -p inet:portnumber@localhost ...other
options...

   Please specify a userid value that isn't used for other applications
   (not "postfix", not "www", etc.).

Is it really worth going to the trouble of a patch+subpackage to provide unix
domain socket support?

Can you confirm that postfix's SMTP daemon runs as GID "postfix"?


Comment 8 Gabriele Turchi 2008-06-25 11:14:08 UTC
Mhh, i think using tcp socket is not a suggestion but only a possible way (for
the specific milter). I haven't found any other explicit preference for tcp over
unix sockets.

Yes, as I said before, I think is a cleaner (and possibly safer) way.

I'll do some tests creating a /var/run/postfix directory, owned by postfix user
(and group). I think is possible creating two sub-packages (-sendmail and
-postfix) containing a correct sysconfig file with different socket default and,
for the postfix sub-package, the script to add sa-milt to postfix group.

I hope to test a f9 configuration during this week.

Comment 9 Gabriele Turchi 2008-06-27 09:50:22 UTC
Created attachment 310418 [details]
SELinux module for spamass-milter and postfix

Comment 10 Gabriele Turchi 2008-06-27 09:51:24 UTC
Ok, first round done. My test was:

semanage fcontext -a -t postfix_var_run_t  '/var/run/postfix(/.*)?'
mkdir /var/run/postfix
chown postfix.postfix /var/run/postfix
chmod 770 /var/run/postfix
usermod -a -G postfix sa-milt
echo "SOCKET=/var/run/postfix/spamass-milter.sock" >> /etc/sysconfig/spamass-milter

Attached my selinux module. 

Comment 11 Paul Howarth 2008-07-03 14:56:24 UTC
Updated packages for testing:

http://www.city-fan.org/~paul/spamass-milter/

I've also included my new SELinux policy for spamass-milter and milter-regex.
After building and installing this module (it'll only work on F9 at the moment),
you'll get warnings like this when various apps call SELinux library functions:

/etc/selinux/targeted/contexts/files/file_contexts: Multiple different
specifications for /usr/sbin/spamass-milter 
(system_u:object_r:milter_spamass_exec_t:s0 and system_u:object_r:spamd_exec_t:s0).

This is harmless. You should, however, fix up the contexts of the files/directories:

# fixfiles -R spamass-milter restore

It's better to have the policy loaded before installing the packages.

Comment 12 Paul Howarth 2008-07-04 08:10:00 UTC
I've now added CentOS 5.2 packages, and an extra SELinux policy module (my-sa)
that adds the interfaces needed to run the milters policy on CentOS 5.2. I've
run the packages with this policy in permissive mode on my work mail server
overnight without any AVCs being generated (and no apparent mail problems :-) )
and have now turned back on enforcing. Seems OK.

Comment 13 Daniel Walsh 2008-08-14 20:45:39 UTC
Any word on getting this upstreamed?

I will suck it into Rawhide if no movement.

Comment 14 Paul Howarth 2008-08-14 22:40:28 UTC
Chris reviewed my first pass at a policy, after which I posted my current version, which is pretty much what's attached here. I guess it's somewhere in the middle of the review queue now, and there's a lot in the queue.

Comment 15 Paul Howarth 2008-09-18 12:37:26 UTC
(In reply to comment #13)
> Any word on getting this upstreamed?
> 
> I will suck it into Rawhide if no movement.

It's had another round of review/re-submission and must be close to being merge-able now. However, it uses the spamassassin_domtrans_spamc interface, which isn't upstream yet so any help in getting that upstreamed would be very useful.

Comment 16 Paul Howarth 2008-11-25 09:08:47 UTC
(In reply to comment #13)
> Any word on getting this upstreamed?
> 
> I will suck it into Rawhide if no movement.

milter policy was merged upstream yesterday.

Comment 17 Paul Howarth 2009-02-02 15:12:02 UTC
Right, I'm going to push the updated packages to Rawhide and build testing updates for F-9 and F-10. Gabriele, please try the updated packages and let me know how you get on.

My next task is to get the milter SELinux policy backported from upstream into Fedora, particularly for F-10 where I can't get a local policy module to override the default context type for the milter binaries.

Comment 18 Paul Howarth 2009-02-03 22:10:08 UTC
(In reply to comment #17)
> My next task is to get the milter SELinux policy backported from upstream into
> Fedora, particularly for F-10 where I can't get a local policy module to
> override the default context type for the milter binaries.

This is happening in Bug #483849

I have updated the EL-5 policy and provided updated spamass-milter packages you may like to try here:
http://www.city-fan.org/~paul/spamass-milter/

There are now three separate policy modules to use on EL-5:

 * milter - this is the almost unchanged milter policy backported from upstream
 * spamassassin-client - this provides the spamassassin_domtrans_client interface required by the milter module
 * milter-extras - this is additional rules required for MTAs to interact with milters using the new policy

Comment 19 Fedora Update System 2009-02-05 02:15:56 UTC
spamass-milter-0.3.1-9.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update spamass-milter'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-1296

Comment 20 Paul Howarth 2009-02-27 15:13:47 UTC
This update will stay in -testing until I get some feedback from a Postfix user as there is no other reason to release it to stable.

Comment 21 Gabriele Turchi 2009-03-06 14:28:21 UTC
I have no more F9 systems "in production": may I ask to move the packages to F10?

Comment 22 Paul Howarth 2009-03-06 14:35:25 UTC
There's an update in F10's -testing repository too; please try that.

Comment 23 Andrew Colin Kissa 2009-03-08 10:48:34 UTC
I would like to confirm that you can run this milter on postfix using tcp

SOCKET="inet:20208@localhost"

Am using it with no problems

Comment 24 Paul Howarth 2009-03-08 17:22:57 UTC
(In reply to comment #23)
> I would like to confirm that you can run this milter on postfix using tcp
> 
> SOCKET="inet:20208@localhost"
> 
> Am using it with no problems  

Thanks; running over TCP should be possible without the new postfix subpackage, which is geared towards use with unix domain sockets. It's possible that SELinux will be a problem though, as my efforts to get TCP support in the SELinux milter policy didn't succeed.

Comment 25 Daniel Walsh 2009-03-09 14:11:52 UTC
Paul was this rejected by upstream?

Comment 26 Paul Howarth 2009-03-09 14:29:39 UTC
The sticking point seemed to be the desire (on my part) to create a milter_port_t but not allocate a default port number to use it as there isn't a default one - a sysadmin just uses a port that's available on their system for milter<->MTA communication.

http://oss.tresys.com/pipermail/refpolicy/2008-November/000430.html

Comment 27 Fedora Update System 2009-04-03 15:43:39 UTC
spamass-milter-0.3.1-13.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/spamass-milter-0.3.1-13.fc10

Comment 28 Fedora Update System 2009-04-03 15:47:17 UTC
spamass-milter-0.3.1-13.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/spamass-milter-0.3.1-13.fc9

Comment 29 Fedora Update System 2009-04-22 20:28:12 UTC
spamass-milter-0.3.1-13.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 30 Fedora Update System 2009-04-24 19:54:55 UTC
spamass-milter-0.3.1-13.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.


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