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.
Created attachment 309925 [details] Patch to add a "-g" option
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.
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
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?
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.
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.
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"?
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.
Created attachment 310418 [details] SELinux module for spamass-milter and postfix
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.
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.
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.
Any word on getting this upstreamed? I will suck it into Rawhide if no movement.
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.
(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.
(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.
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.
(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
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
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.
I have no more F9 systems "in production": may I ask to move the packages to F10?
There's an update in F10's -testing repository too; please try that.
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
(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.
Paul was this rejected by upstream?
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
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
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
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.
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.